Page History

...

First, remove the following rule for the internal "targeted-id" attribute from your attribute-policy.xml as  (if it even exists) as we're about to change its content further below:

<afp:AttributeRule attributeID="targeted-id">
    <afp:PermitValueRuleReference ref="ScopingRules"/>
</afp:AttributeRule>

Then also completely remove the correspondent (if it even exists) the corresponding rule for the old internal SAML1 "targeted-id" attribute from your attribute-map.xml (you should never receive something like that anyway):

<!-- First, the deprecated/incorrect version, decoded as a scoped string: --> 
<Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID" id="targeted-id">
    <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
    <!-- <AttributeDecoder xsi:type="NameIDFromScopedAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/> --> 
</Attribute>

...

<!-- Third, the new version (note the OID-style name): --> 
<Attribute name<Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="persistent-id">
    <AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/>
</Attribute>

...

<!-- Third, the new version (note the OID-style name): --> 
<Attribute name=<Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="targeted-id">
    <AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/>
</Attribute>

Finally, restart the Shibboleth SP software (e.g. service shibd restart) to activate the changed configuration. With this in place the following now happens:

• (Proper) Persistent NameIDs sent in the Subject element of the SAML Assertion will be mapped to the internal "persistent-id" attribute
• Persistent NameIDs sent as eduPersonTargetedID SAML Attribute values will be mapped to the internal "targeted-id" attribute
• By default both are tried in order to populate the REMOTE_USER special CGI variable, cf. REMOTE_USER="eppn persistent-id targeted-id" in your shibboleth2.xml main configuration file.

To further isolate your application from all those different identifier attributes and NameIDs that are currently common use the Shibboleth SP's REMOTE_USER precedence list. Any (internal, after mapping) attribute names listed there are then tried in order to populate the REMOTE_USER special CGI variable from the first attribute that is not empty (i.e., that has a value). So all that's needed to support any kind of legacy (eduPersonTargetedID), past/present (persistent NameID) or present/future (pairwise-id, subject-id) identifiers is to make sure they're all listed in the Shibboleth SP's REMOTE_USER precedence list, e.g. by adding targeted-id (as re-defined above) to the end of the list:

<ApplicationDefaults entityID="..."
    REMOTE_USER="eppn subject-id pairwise-id persistent-id targeted-id"

With that in place an application can simply So now an application can (or should) just check for REMOTE_USER and will get either version that has a value the value of the first non-empty attribute listed there (in the order given), but will never receive more than one value!.