Identity Provider Configuration:
      Potential eduPersonTargetedID Problem

It has been noted that some existing implementations of the standard Shibboleth 1.3 IdP software have included a definition of eduPersonTargetedID in the resolver.xml configuration file which has caused problems.

(If you are reading this prior to or during installation of a new Shibboleth 1.3 IdP, ensure that your resolver.xml file does not include an eduPersonTargetedID definition of the form shown below. If it does contain such a definition, you should acquire the latest installation files, as described in Register1p3IdP, and use them instead.)

In such cases the eduPersonTargetedID attribute is defined in resolver.xml along the following lines: 

  <PersistentIDAttributeDefinition
    id="urn:mace:dir:attribute-def:eduPersonTargetedID" scope="xxx.ac.uk" 
    sourceName="eduPersonPrincipalName">
    <DataConnectorDependency requires="echo"/>
    <Salt>saltstring.......</Salt>
  </PersistentIDAttributeDefinition>

The definition of "echo" is given elsewhere in the resolver.xml file: 

  <CustomDataConnector id="echo" 
   class="edu.internet2.middleware.shibboleth.aa.attrresolv.provider.SampleConnector"/>

This definition picks up what the user actually typed in as his or her user-id when authenticating. Thus, for example, if the user typed in a user-id in all lower case one day, and with a leading capital the next day, in case-insensitive single sign-on systems both logins might well succeed, but two different eduPersonTargetedID values would be generated. This clearly has consequences when using services which employ the user's eduPersonTargetedID value to personalise their use of the service (such as in order to save searches or store results).

Fixing the problem

The source for eduPersonTargetedID should be an appropriate field in the directory, eg. the LDAP or Microsoft Active Directory. It must be unique and not have the scope explicitly appended. The LDAP attribute against which the %PRINCIPAL% is matched suits this purpose. If possible, a field should be chosen that is unique over time as well as space, ie. no value of the field can ever be reused. If no such field exists then care must be taken (particularly for organisations asserting user accountability) to ensure that no value of the field chosen is reallocated to another user for at least two years after being cancelled.

Assuming then that the %PRINCIPAL% is matched against a directory field called uid and this is to be used to seed eduPersonTargetedID, the above PersistentIDAttributeDefinition should be replaced with the following: 

  <PersistentIDAttributeDefinition
    id="urn:mace:dir:attribute-def:eduPersonTargetedID" scope="xxx.ac.uk" 
    sourceName="uid">
    <DataConnectorDependency requires="directory"/>
    <Salt>saltstring.......</Salt>
  </PersistentIDAttributeDefinition>

Note the change to the DataConnectorDependency and the sourceName. The echo CustomDataConnector can be removed.

For an organisation using Microsoft Active Directory that has an existing Shibboleth IdP exhibiting this problem, it is probably best to use the method described above; this will allow at least some of the organisation's users to preserve their eduPersonTargetedID values and thus their registrations and personalisations.

For an organisation using Microsoft Active Directory that is installing a new Shibboleth IdP, it may be better to use the objectSid, which is for this purpose unique over space and time, and so the possibility of reuse of eduPersonTargetedID values is avoided. However, the code required is different, because this is a binary field, and because there is an issue involved in its conversion to a string which must be worked around (this is what the SIDAsBase64 code below is for). In this case the following property should be added to the JNDIDirectoryDataConnector: 

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

and the PersistentIDAttributeDefinition replaced with the following: 

  <ScriptletAttributeDefinition id="SIDAsBase64">
     <DataConnectorDependency requires="directory"/>
     <Scriptlet><![CDATA[
	 import org.bouncycastle.util.encoders.Base64;
         Attributes resolvedAttributes = dependencies.getConnectorResolution("directory");
         Attribute id =  resolvedAttributes.get("objectSid");
         String b64id = new String(Base64.encode(id.get(0)));

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

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

Finally

After making any change in the definition of eduPersonTargetedID, note that those end users who consistently type any upper case letters when logging in would henceforth be assigned different eduPersonTargetedID values, which means that they would lose access to any records held for them by services and keyed using the eduPersonTargetedID value.

If it proves necessary to make such a change, you are recommended to tell your end-users and point out the consequences.