ActiveDirectoryInstallerObjectSID

There is an issue when using binary attributes from an LDAP and Shibboleth 1.3; The reasons for this are documented elsewhere, but the result an IdP may issue the same eduPersonTargettedId for two users (with different SIDS).

The current version of the installer handles this issue correctly, but if you installed a from a version prior to the one dated 5th December 2008 you need to change your installation.

As a result of this change the eduPersonTargettedId issued by your IdP for a specific user will now be different, and each user will need to reapply and personalization required

All changes will be made to one file, the resolver.xml file. This will usually be

C:\Program files\Internet2\idp\resolver.xml

You need to make three changes:

1. Declare a new internal attribute to contain the SID encoded as base64

Find these lines in resolver .xml

        <!--  eduPersonEntitlement

            This is purely example code on how to look in the
            membership of a user for a specific group (in this case
            "Student" and use that to export a specific
            entitlement ("https://foo.com").  -->

Immediately above, paste in this code:

     <!-- SIDAsBase64 
          The ObjectSid comes over as binary.  The LDAP Connector 
          can drop the last few octets from time 
          to time when converting to a string.  Hence before we can drop
          this into ePTID below we have to Base64-ize it.
      -->

     <ScriptletAttributeDefinition id="SIDAsBase64">
       <DataConnectorDependency requires="directory"/>

         <Scriptlet><![CDATA[
	    import org.bouncycastle.util.encoders.Base64;

            resolvedAttributes = dependencies.getConnectorResolution("directory");
           
            Attribute id =  resolvedAttributes.get("objectSid");
            String b64id = new String(Base64.encode(id.get(0)));

           resolverAttribute.addValue(b64id);
         ]]></Scriptlet>
     </ScriptletAttributeDefinition>

This code declares a new Attribute called SIDAsBase64, which is the SID, extracted as a binary stream (we'll do this below) and encoded using a library already used elsewhere in the IdP.

2. Change the ePTID declaration to use the new attribute

Find the declaration of eduPersonTargetedID. It will look like this:

	<PersistentIDAttributeDefinition 
		          id="urn:mace:dir:attribute-def:eduPersonTargetedID"
		          scope="foo.ac.uk"
		          sourceName = "objectSid"> 
		           <DataConnectorDependency requires="directory"/>
		            <Salt>{GUID}</Salt>
	</PersistentIDAttributeDefinition>

Change this block so that it looks like this (replacing the scope and the salt with the original values:

	<PersistentIDAttributeDefinition 
             		id="urn:mace:dir:attribute-def:eduPersonTargetedID"
             		scope="foo.ac.uk"> 
    		<AttributeDependency requires="SIDAsBase64"/>
    		<Salt>GUID</Salt>
	</PersistentIDAttributeDefinition>

3. Declare objectSid as binary.

Find the definition of JNDIDirectoryDataConnector. Add this line towards the end, below the password and above the </JNDIDirectoryDataConnector> line:

	
        <Property name="java.naming.ldap.attributes.binary"
		 value="objectSid objectGUID"/>

The last few lines of the definition will look like this:

  	<Property name="java.naming.security.principal" 
           		value="ldap@foo.ac.uk" />
 	<Property name="java.naming.security.credentials" 
           		value="T0PSeCret" />
 	<Property name="java.naming.ldap.attributes.binary" 
           		value="objectSid objectGUID"/>

	</JNDIDirectoryDataConnector>

4. And finally

Restart Tomcat and test.