eduPersonUniqueID

This is a globally unique identifier that looks a bit like an email address but certainly does not have to be one. (Most existing email addresses will not be suitable canditates for this attribute, due to its requirements for non-reassignment as well as opqaueness.)

eduPersonUniqueID Alternatives

For application integrators the potential alternatives to relying on eduPersonUniqueID in the Higher Education and Research sector basically are:

• SAML 2.0 persistent NameIDs: Unless you have several SAML Service Providers all needing to recieve the same identifier for a subject (e.g. as part of a multi-party multi-site project) persistent NameIDs are preferable. Also, as per early 2017 c.e. many more SAML Identity Providers support persistent NameIDs, and hardly any support eduPersonUniqueID yet.
• eduPersonPrincipalName: Similar only in syntax. eduPersonPrincipalName is usually derived from the local login name (+ scope) or actually is a copy of the subject's email address. Both login names and email addresses eventually will be reassigned (i.e., given from one subject to another) at many organisations, which will also affect eduPersonPrincipalName values (Reassignment of eduPersonPrincipalName values is not prohibited by the eduPerson specification). In contrast, eduPersonUniqueID does not allow reassignment, ever. That in turn strongly suggests use of opaque (read: long, ugly) attribute values for eduPersonUniqueID, in order to avoid namespace depletion. The main advantage of eduPersonPrincipalName seems to be its wide existing deployment, though that comes at a price: You can't rely on much, especially not that a given eduPersonPrincipalName value will identify the same subject after some time (e.g. several years later).
• Persistent NameIDs plus eduPersonPrincipalName: An application needing stronger assurances that a given identifier represents the same subject over time than those eduPersonPrincipalName alone provides can store both the persistent NameID and eduPersonPrincipalName values. The application can then continue using eduPersonPrincipalName as usual, but with the addition that during login the concatenation of persistent NameID and eduPersonPrincipalName is compared to previously stored values. Since a persistent NameID itself is prohibited from being reassigned, a changed combination of persistent NameID and eduPersonPrincipalName values can be seen as a strong indicator that the eduPersonPrincipalName value has been reassigned. The application could then decide to treat the new combination of values as a difference subject.
• Email address: When used as an identifier email addresses suffer from the same reassignment issues as eduPersonPrincipalName (described above) – plus additional ones, e.g. the possibility of sending email to that "identifier". Also, releasing an email address to a service when only an(y) identifier is needed will fails most "data minimisation" tests, and may therefore not be sufficient under the upcoming GDPR/DSGVO.

So eduPersonUniqueID is clearly the preferred choice if:

• your SAML Service Provider is part of a larger project that also involves other SAML SPs (and all those SPs need to reference a given subject by the same identifier, and those SPs are not localed behind a shared SAML proxy), and
• your application has strong requirements for non-reassignment of identifiers, i.e., if you need to be certain a given identifier represents the same subject even after many years of not having seen a login from that identifier, and
• you cannot or don't want to rely on using the combination of persistent NameID and eduPersonPrincipalName (as described above), which would give you some degree of "human palatability" (when showing eduPersonPrincipalName values in the application's interface) and equally strong arrurance of non-reassignment as eduPersonUniqueID provides (due to persistent NameIDs existing requirements).

But eduPersonUniqueID is also an acceptable alternative in basically all other cases where you already accept any of the following as primary identifier for a subject:

• eduPersonPrincipalName (maybe less so if you need to show the value to the logged-in subject and/or subjects will need to recognise others based on that identifier)
• persistent NameIDs
• email addresses (same caveat as for eduPersonPrincipalName above; plus sending email to eduPersonUniqueID usually won't work).

So following Postel's law it's recommended for SAML Service Providers to (also) accept eduPersonUniqueID, whenever a stable, unique identifier is needed.

Creating the attribute with Shibboleth IDP v3

If you are already supporting persistent NameIDs you could re-use parts of that configuration to easily create eduPersonUniqueID attributes. The example below works by taking the attribute configured in /opt/shibboleth-idp/conf/saml-nameid.properties (idp.persistentId.sourceAttribute) as source data, applying the same salt as configured in /opt/shibboleth-idp/conf/saml-nameid.properties (idp.persistentId.salt), and generating an MD5 hash from the combined string:

<AttributeDefinition id="eduPersonUniqueId" xsi:type="ScriptedAttribute">
    <Dependency ref="myLDAP" />
    <Script><![CDATA[
        var scopedValue = Java.type("net.shibboleth.idp.attribute.ScopedStringAttributeValue");
        var digestUtils = Java.type("org.apache.commons.codec.digest.DigestUtils");
        var idSaltHash  = digestUtils.md5Hex(
            %{idp.persistentId.sourceAttribute}.getValues().get(0) + "%{idp.persistentId.salt}");
        eduPersonUniqueId.addValue(new scopedValue(idSaltHash,"%{idp.scope}"));
    ]]></Script>
    <AttributeEncoder xsi:type="SAML1ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.13" encodeType="false" />
    <AttributeEncoder xsi:type="SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.13" friendlyName="eduPersonUniqueId" encodeType="false" />
</AttributeDefinition>