Context Navigation

Configuration Settings for JNDI Context Provider

The JNDI context provider is an IdAS context provider that can theoretically connect to any JNDI back end identity store. However, it is most commonly used to connect to an LDAP directory. 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.

The settings for the JNDI context provider are described in the following sections.

Connection Setting

The Type for this setting is "htf:map" (java.util.Map). The settings in this Map describe connection information for a specific JNDI backend. The following example shows how it would be used to connect to an LDAP directory.

   <Setting Name="Connection" Type="htf:map">
      <Setting Name="ConnectionType" Type="xsd:string">LDAP</Setting>
      <Setting Name="AddressList" Type="htf:list">
         <Setting Name="Address" Type="xsd:string">ldap://localhost:389</Setting>
      </Setting>
      <Setting Name="jndiProvider" Type="xsd:string">com.sun.jndi.ldap.LdapCtxFactory</Setting>
      <Setting Name="searchBase" Type="xsd:string">ou=people,o=bandit</Setting>
   </Setting>

The Connection setting contains the following settings:

ConnectionType. The Type for this setting is "xsd:string" (Java String). It contains the type of JNDI connection to be established. Currently, the only valid value is "LDAP".
AddressList. The Type for this setting is "htf:list" (java.util.List). This setting contains a list of alternative addresses to connect to. Each address setting must be of Type "xsd:string". The JNDI context provider will try to connect to each address until it succeeds in finding one that works.
jndiProvider. This is a factory class that will be used to instantiate a JNDI service provider object. Note: If this setting is missing, it defaults to com.sun.jndi.ldap.LdapCtxFactory.
searchBase. This is the directory sub-tree that will be searched whenever entity search operations are performed on the context. Only entities in this sub-tree will be returned. If this setting is missing, the entire directory tree will be searched.

env Setting

The Type for this setting is "htf:map" (java.util.Map). The settings in this Map will be inserted as properties into the environment for the JNDI service provider object that is instantiated. The following example shows some possible settings:

   <Setting Name="env" Type="htf:map">
      <Setting Name="java.naming.security.authentication" Type="xsd:string">simple</Setting>
      <Setting Name="java.naming.security.principal" Type="xsd:string">cn=admin,o=bandit</Setting>
      <Setting Name="java.naming.security.credentials" Type="xsd:string">admin</Setting>
   </Setting>

Many environment properties for JNDI service providers are defined here. Unless overridden by the JNDI context provider, these will be passed down to the JNDI service provider object that is instantiated.

Below is a list of properties that are used when the authentication material passed into the IdAS context provider is "least privileged user" (org.eclipse.higgins.idas.common.AuthNLeastPrivilegedUserMaterials). Note that these properties are overridden when other types of authentication material are used.

java.naming.security.authentication. This environment property specifies the security level to use. Its value is one of the following strings: "none", "simple", "strong". If this property is unspecified, the behavior is determined by the service provider.
java.naming.security.principal. This environment property holds the name of the "least privileged identity" to authenticate with.
java.naming.security.credentials. This environment property holds the credentials of the "least privileged identity" being authenticated. This is normally a password.

The following two properties are used when the authentication material passed into the IdAS context provider is a SAML 1.x assertion (org.eclipse.higgins.util.saml.SAML1Assertion). Combined, they specify a class that is the SASL client provider (instance of java.security.Provider).

org.eclipse.higgins.idas.cp.jndi.saslClientPackage.
org.eclipse.higgins.idas.cp.jndi.saslClientProvider.

The following properties may be set to control usage of TLS and SSL for transport security:

org.eclipse.higgins.idas.cp.jndi.startTLS. This property holds a value of "true" or "false". A value of "true" indicates that TLS is to be used for message transport security.
org.eclipse.higgins.idas.cp.jndi.trustStore. This property holds the name of a trust store for TLS, if TLS is enabled.
org.eclipse.higgins.idas.cp.jndi.trustStorePassword. This property holds the the password for the TLS trust store, if TLS is enabled.
java.naming.security.protocol. If a trust store is specified (see above), and the value of this property is "ssl", then SSL will be used for the transport.

AuditRecordClass Setting

The Type of this setting is "xsd:string" (Java String). It is optional. If present, it contains the name of the class that implements the org.eclipse.higgins.audit.api.AuditRecord interface. Objects of this class are used to log audit events. If this setting is missing, audit events will not be logged. The OTIS SDK provides a class that implements this interface - org.bandit.otis.impl.OtisAuditRecord. This particular implementation formats audit records according to the XDAS record format. Specifying this class as the audit record class is illustrated below:

   <Setting Name="AuditRecordClass" Type="xsd:string">org.bandit.otis.impl.OtisAuditRecord</Setting>

Note that audit event records are logged to a logger named higgins.audit.events. If you are using log4j to do logging, OTIS also provides a log4j appender that will log the audit records to the XDAS Daemon. The appender class is org.bandit.otis.impl.OtisAuditAppender. This appender can be included in your log4j.properties file to cause audit events to be sent to the XDAS Daemon. The log4j settings to do this are illustrated below:

# Specify an appender for audit events.  All audit events are sent to the higgins.audit.events logger.
# We therefore create an appender for that logger.  We also set the additivity property of the
# logger to false, so that audit events will ONLY go to that appender.

log4j.logger.higgins.audit.events=trace, auditappender
log4j.additivity.higgins.audit.events=false
log4j.appender.auditappender=org.bandit.otis.impl.OtisAuditAppender

JSPolicyAction Setting

The Type of this setting is "htf:map" (java.util.Map). It is entirely optional. If present, it contains several sub-settings that hold javascript. Each of the sub-settings are also optional. There are 11 possible sub-settings, as illustrated below:

   <Setting Name="JSPolicyAction" Type="htf:map>
      <Setting Name="JSSharedScope" Type="htf:jscriptscope">
         <!-- Javascript goes here -->
      </Setting>
      <Setting Name="consumerEntityIDToProvider" Type="htf:jscriptexec">
         <!-- Javascript goes here -->
      </Setting>
      <Setting Name="providerEntityIDToConsumer" Type="htf:jscriptexec">
         <!-- Javascript goes here -->
      </Setting>
      <Setting Name="consumerEntityTypeToProvider" Type="htf:jscriptexec">
         <!-- Javascript goes here -->
      </Setting>
      <Setting Name="providerEntityTypeToConsumer" Type="htf:jscriptexec">
         <!-- Javascript goes here -->
      </Setting>
      <Setting Name="consumerAIDToProvider" Type="htf:jscriptexec">
         <!-- Javascript goes here -->

      </Setting>
      <Setting Name="providerAIDToConsumer" Type="htf:jscriptexec">
         <!-- Javascript goes here -->
      </Setting>
      <Setting Name="consumerATypeToProvider" Type="htf:jscriptexec">
         <!-- Javascript goes here -->
      </Setting>
      <Setting Name="providerATypeToConsumer" Type="htf:jscriptexec">
         <!-- Javascript goes here -->
      </Setting>
      <Setting Name="consumerAValueToProvider" Type="htf:jscriptexec">
         <!-- Javascript goes here -->
      </Setting>
      <Setting Name="providerAValueToConsumer" Type="htf:jscriptexec">
         <!-- Javascript goes here -->
      </Setting>
   </Setting>

The javascript in each of the sub-settings is executed at various decision points in the JNDI context provider to map entity IDs, entity Types, attribute IDs, attribute value types, and attribute values. Each is explained and illustrated in more detail below.

JSSharedScope Setting

The Type of this setting is "htf:jscriptscope". This setting is a little different than the other javascript settings, in that it is intended to define javascript that is shared with all of the other settings. This javascript is essentially combined with the javascript of each of the other settings. Thus, any of the javascript variables, calculations, etc. in this setting are automatically available in the other settings. One of the common uses of this setting is to set up an attribute ID mapping table that will map some of the standard attribute IDs to LDAP attribute names and vice versa. For example, the following javascript sets up a name mapping table that takes the common Information Card claim attribute IDs and standard Higgins attribute IDs to LDAP attribute names:

   <Setting Name="JSSharedScope" Type="htf:jscriptscope">
      <![CDATA[
      var multimap = {
                      consumer: [],
                      provider: []
                     };

      /* Map standard information card claim names */

      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"] =
         ["givenName"];
      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"] =
         ["sn"];
      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"] =
         ["mail"];
      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress"] =
         ["street"];
      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality"] =
         ["localityName"];
      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince"] =
         ["st"];
      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode"] =
         ["postalcode"];
      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country"] =
         ["countryname"];
      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone"] =
         ["homephone"];
      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone"] =
         ["otherphone"];
      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone"] =
         ["mobilephone"];
      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth"] =
         ["dateofbirth"];
      multimap.consumer["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender"] =
         ["gender"];

      /* Map some standard Higgins entity types and attribute names to LDAP names */

      multimap.consumer["http://www.eclipse.org/higgins/ontologies/2006/higgins#Person"] =
         ["inetOrgPerson"];
      multimap.consumer["http://www.eclipse.org/higgins/ontologies/2006/higgins#password"] =
         ["userPassword"];
      multimap.consumer["http://www.eclipse.org/higgins/ontologies/2006/higgins#cardKeyHash"] =
         ["cardKeyHash"];
      multimap.consumer["http://www.eclipse.org/higgins/ontologies/2006/higgins#cardKeyHashInfo"] =
         ["cardKeyHashInfo"];

      /* Produce the reverse mapping: LDAP name -> standard information card or Higgins name */

      for (elem in multimap.consumer)
      {
         for (provider in multimap.consumer[elem])
            multimap.provider[multimap.consumer[elem][provider]] = elem;
      }
      ]]>
   </Setting>

consumerEntityIDToProvider Setting

The Type of this setting is "htf:jscriptexec". It contains javascript that maps an entity ID from the application to a distinguished name in the LDAP directory. A variable called consumerID is passed into the script. It contains the entity ID name as it came from the application. This javascript is used to map an entity ID to a particular DN in the LDAP directory. It will generally map all entity IDs into a particular container in the LDAP directory. However, it is not limited to that. In fact, the following example script shows that only maps entity IDs that do not already look like DNs. This allows an application to pass in a DN for any object in the directory and not have it be mapped. The mapped value is returned by setting a variable called RESULT.

   <Setting Name="consumerEntityIDToProvider" Type="htf:jscriptexec">
      <![CDATA[
      if ((consumerID.length >= 3 && consumerID.slice( 0, 3) == "cn=") ||
          (consumerID.length >= 3 && consumerID.slice( 0, 3) == "CN=") ||
          (consumerID.length >= 3 && consumerID.slice( 0, 3) == "dc=") ||
          (consumerID.length >= 3 && consumerID.slice( 0, 3) == "DC=") ||
          (consumerID.length >= 3 && consumerID.slice( 0, 3) == "ou=") ||
          (consumerID.length >= 3 && consumerID.slice( 0, 3) == "OU=") ||
          (consumerID.length >= 4 && consumerID.slice( 0, 4) == "uid=") ||
          (consumerID.length >= 4 && consumerID.slice( 0, 4) == "UID="))
      {
         /* Application passed in a DN probably - don't change it */
         map = consumerID;
      }
      else
      {
         /* Tack on the right stuff to make a DN in the ou=people,o=bandit container */
         map = "cn=" + consumerID + ",ou=people,o=bandit";
      }
      RESULT = map;
      ]]>
   </Setting>

providerEntityIDToConsumer Setting

The Type of this setting is "htf:jscriptexec". It contains javascript that maps a DN from the LDAP directory back to an entity ID name the application will understand. A variable called providerID is passed into the script. It contains the LDAP DN. This javascript is generally used to map DNs from a particular container, but is certainly not limited to that. In fact, the following example maps DNs from a particular container (ou=people,o=bandit), but leaves all other DNs unchanged, which means that DNs from other containers will return to the application unmapped. The mapped value is returned by setting a variable called RESULT.

   <Setting Name="providerEntityIDToConsumer" Type="htf:jscriptexec">
      <![CDATA[
      var re = new RegExp("^cn=(.*),ou=people,o=bandit$", "i");
      RESULT = String(providerID.toString()).replace(re, "$1");
      ]]>
   </Setting>

consumerEntityTypeToProvider Setting

The Type of this setting is "htf:jscriptexec". It contains javascript that maps an entity type from the application to an object class name in the LDAP schema. A variable called consumerType is passed into the script. The variable is a URI object. It contains the entity type name as it came from the application. Note the use of the multimap variable that was defined in the JSharedScope setting (see above). The script first looks up the name in the multimap variable. If it is not found there, it applies a matching rule with a regular expression. If the matching rule fails, the name will not be mapped. The mapped value is returned by setting a variable called RESULT.

   <Setting Name="consumerEntityTypeToProvider" Type="htf:jscriptexec">
      <![CDATA[
      map = multimap.consumer[String(consumerType.toString())];
      if (!map)
      {
         var re = new RegExp("^http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#class_", "i");
         map = String(consumerType.toString()).replace(re, "");
      }
      RESULT = map;
      ]]>
   </Setting>

providerEntityTypeToConsumer Setting

The Type of this setting is "htf:jscriptexec". It contains javascript that maps an LDAP object class name to an entity type the application will understand. A variable called providerType is passed into the script. The variable contains the name of the LDAP object class that is to be mapped. Note the use of the multimap variable that was defined in the JSharedScope setting (see above). The script first looks up the object class name in the multimap variable. If it is not found there, it simply turns object class name into a standard Higgins class name by prefixing the LDAP object class name with "http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#class_". The mapped value is returned by setting a variable called RESULT.

   <Setting Name="providerEntityTypeToConsumer" Type="htf:jscriptexec">
      <![CDATA[
      map = multimap.provider[String(providerType.toString())];
      if (!map)
         map = "http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#class_" + String(providerType.toString());
      RESULT = map;
      ]]>
   </Setting>

consumerAIDToProvider Setting

The Type of this setting is "htf:jscriptexec". It contains javascript that maps an attribute ID from the application to an attribute name in the LDAP schema. A variable called consumerID is passed into the script. The variable is a URI object. It contains the attribute ID as it came from the application. Note the use of the multimap variable that was defined in the JSharedScope setting (see above). The script first looks up the attribute ID in the multimap variable. If it is not found there, it applies a matching rule with a regular expression. If the matching rule fails, the name will not be mapped. The mapped value is returned by setting a variable called RESULT.

   <Setting Name="consumerAIDToProvider" Type="htf:jscriptexec">
      <![CDATA[
      map = multimap.consumer[String(consumerID.toString())];
      if (!map)
      {
         var re = new RegExp("^http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_", "i");
         map = String(consumerID.toString()).replace(re, "");
      }
      RESULT = map;
      ]]>
   </Setting>

providerAIDToConsumer Setting

The Type of this setting is "htf:jscriptexec". It contains javascript that maps an LDAP attribute class name to an attribute ID the application will understand. A variable called providerID is passed into the script. The variable contains the name of the LDAP attribute that is to be mapped. Note the use of the multimap variable that was defined in the JSharedScope setting (see above). The script first looks up the LDAP attribute name in the multimap variable. If it is not found there, it simply turns the LDAP attribute name into a standard Higgins attribute ID by prefixing the LDAP attribute name with "http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_". The mapped value is returned by setting a variable called RESULT.

   <Setting Name="providerAIDToConsumer" Type="htf:jscriptexec">
      <![CDATA[
      map = multimap.provider[String(providerID.toString())];
      if (!map)
         map = "http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_" + providerID.toString();
      RESULT = map;
      ]]>
   </Setting>

consumerATypeToProvider Setting

The Type of this setting is "htf:jscriptexec". It contains javascript that maps a value type the application to a syntax type in the LDAP schema. Two variables are passed into the script:

consumerID. This contains the name of the attribute that came in from the application. This is a URI.
consumerType. This contains the type of the data, as it is known to the application. This is a URI.

The mapped value is returned by setting a variable called RESULT. Below is an example where an application value type of "http://www.w3.org/2001/XMLSchema#string" is mapped to an LDAP syntax of "1.3.6.1.4.1.1466.115.121.1.15". No other value types are mapped.

   <Setting Name="consumerATypeToProvider" Type="htf:jscriptexec">
   <![CDATA[
      if (consumerType == "http://www.w3.org/2001/XMLSchema#string")
         RESULT = "1.3.6.1.4.1.1466.115.121.1.15";
      else
         RESULT = consumerType;
      ]]>
   </Setting>

providerATypeToConsumer Setting

The Type of this setting is "htf:jscriptexec". It contains javascript that maps an LDAP syntax to a value type the application can understand. Two variables are passed into the script:

providerID. This contains the LDAP attribute name.
providerType. This contains the LDAP syntax for the attribute.

The mapped value is returned by setting a variable called RESULT. Below is an example where an LDAP syntax of "1.3.6.1.4.1.1466.115.121.1.15" is mapped to an application value type of "http://www.w3.org/2001/XMLSchema#string". No other syntaxes are mapped.

   <Setting Name="providerATypeToConsumer" Type="htf:jscriptexec">
   <![CDATA[
      if (providerType == "1.3.6.1.4.1.1466.115.121.1.15")
         RESULT = "http://www.w3.org/2001/XMLSchema#string";
      else
         RESULT = providerType;
      ]]>
   </Setting>

consumerAValueToProvider Setting

The Type of this setting is "htf:jscriptexec". It contains javascript that maps an attribute value from the application to an attribute value in the LDAP directory. Five variables are passed into the script:

consumerID. This contains the name of the attribute that came in from the application. This is a URI.
consumerType. This contains the type of the data, as it is known to the application. This is a URI.
providerID. This contains the name of the LDAP attribute from the LDAP schema.
providerType. This contains the syntax type of the data from the LDAP schema.
PARAM. This contains the value that came in from the application.

The mapped value is returned by setting a variable called RESULT. Below is an example where values for the LDAP "role" attribute are mapped to a DN in the ou=people,o=bandit container. No other values are mapped.

   <Setting Name="consumerAValueToProvider" Type="htf:jscriptexec">
   <![CDATA[
      importPackage(Packages.org.eclipse.higgins.idas);
      importPackage(Packages.org.eclipse.higgins.idas.spi);

      if (providerID == "role")
      {
         RESULT = new Packages.org.eclipse.higgins.idas.spi.BasicValueString(
                       "cn=" + PARAM.getLexical() + ",ou=people,o=bandit", null);
      }
      else
      {
         RESULT = PARAM;
      }
      ]]>
   </Setting>

providerAValueToConsumer Setting

The Type of this setting is "htf:jscriptexec". It contains javascript that maps an attribute value from the LDAP directory to a value the application can understand. Five variables are passed into the script:

consumerID. This contains the name of the attribute that came in from the application. This is a URI.
consumerType. This contains the type of the data, as it is known to the application. This is a URI.
providerID. This contains the name of the LDAP attribute from the LDAP schema.
providerType. This contains the syntax type of the data from the LDAP schema.
PARAM. This contains the value that came in from the LDAP directory.

The mapped value is returned by setting a variable called RESULT. Below is an example where values for the LDAP "role" attribute are mapped from a DN in the ou=people,o=bandit container. The DN-ishness of the role is stripped off. No other values are mapped.

   <Setting Name="providerAValueToConsumer" Type="htf:jscriptexec">
      <![CDATA[
      importPackage(Packages.org.eclipse.higgins.idas);
      importPackage(Packages.org.eclipse.higgins.idas.spi);

      if (providerID == "role")
      {
         //TODO how do we detect java types for the correct casts?
         var re = new RegExp("^cn=(.*),ou=people,o=bandit$", "i");
         RESULT = new Packages.org.eclipse.higgins.idas.spi.BasicValueString(
                          String(PARAM.getData()).replace(re, "$1"), null);
      }
      else
      {
         RESULT = PARAM;
      }
      ]]>
   </Setting>

Download in other formats:

Plain Text