Configuration Settings for JSPolicy Context Provider

The JSPolicy context provider is an IdAS context provider that can theoretically connect to any available IdAS context provider. By wrapping around another context provider JSPolicy can filter and map and transform entity and attribute Ids, types, and values. The JSPolicy CP is rarely used to connect to the JNDI Context Provider because the JNDI provider uses the JSPolicy code to do some of the same mappings. Settings for the context provider may be embedded in the IdAS Registry settings. For more information on how context provider settings are embedded in the IdAS Registry settings, see the ContextIdsList Setting subsection.

Because the JNDI CP uses JSpolicy code there is also some documentation and samples of the configuration documented in the JNDI Context Provider. All of the settings for the JSPolicy context provider are documented in the JSPolicy javadoc.

When dealing with the naming of the JSPolicy provider please keep in mind that the consumer refers to the person or code calling the JSPolicy, and the provider is the CP that JSPolicy is using to gather it's data. A name like consumerEntityIDToProvider would indicate the mapping being provided on a EntityID as to transform it from the form presented by the caller of the JSPolicy CP to something recognizable to the code that the JSPolicy is calling.

Configuration

References to the settings for the JSPolicy context provider are described below.

Most of the policy will be held in a section titled JSPolicyAction. Within that section there will be an area for shared javascript named JSSharedScope as well as areas and decision points for the following general operations:

Opening the context

When opening the JSPolicy context using open(java.lang.Object) the JSPolicy CP must first determine what is the CP which should really be opened. JSPolicy does this by taking the consumer passed context ID and evaluating the javascript policy described in the consumerOpenContextRefToProvider element. Input to the policy is a single URI in the javascript variable PARAM, and the expected result is a URI. In this sample the input URI is ignored and a hardcoded URI is returned:

        <Setting Name="consumerOpenContextRefToProvider" Type="htf:jscriptexec">
                new java.net.URI("higginsctx://config" + "?id=Corporate-LDAP-Server");
        </Setting>

After mapping the consumer context URI to a provider URI and ensuring it is a valid context which is configured in the local IdAS Registry the identity object passed to open is examined. If the passed object is an IAuthNAttributesMaterials then for each property we will attempt to map the name and value using the policy stored in consumerOpenAIDToProvider and consumerOpenValueToProvider.

             <JSPolicyAction id="consumerOpenValueToProvider" evalType="javascript">
                        importPackage(Packages.org.eclipse.higgins.idas);
                        importPackage(Packages.org.eclipse.higgins.idas.impl);
 
                        var re = new RegExp("ˆvc", "g");
                        if (consumerType == "EntityIDSyntax") {
                                RESULT = new Packages.org.eclipse.higgins.idas.impl.BasicValueString(
                                String(PARAM.getData()).replace(re, "js"));
                        }
                </JSPolicyAction>

Entities

Mapping Entity IDs

Entity IDs are returned from calls to the IdAS API getEntityID(). In order to be successful we must define forward and reverse mappings, contained in providerEntityIDToConsumerSetting and consumerEntityIDToProviderSetting.

Mapping Entity Types

Entity Types are returned from calls to the IdAS API getEntityType(). In order to be successful we must define forward and reverse mappings, contained in providerEntityTypeToConsumerSetting and consumerEntityTypeToProviderSetting.

Attributes

Mapping Attribute Names

Attribute Names are returned from calls to the IdAS API getAttrID(), and other places. In order to be successful we must define forward and reverse mappings, contained in providerAIDToConsumerSetting and consumerAIDToProviderSetting

Mapping Attribute Types

Attribute Types are returned from calls to the IdAS API getDataType(), and must be provide in calls such as addValue(). In order to be successful we must define forward and reverse mappings, contained in providerATypeToConsumer and consumerATypeToProvider

Mapping Values

All of the consumer to provider and back again dance described above is valuable and required but may not result in a perfectly mapped deployment. Some Attribute values may contain Entity IDs, Entity Types, Attribute Types, Attribute Names. In in cases where values contain embedded elements requiring translation it is necessary to define Mappings including providerAValueToConsumer.