This is a summary of the origins, issues, and SP best practices associated with the eduPersonTargetedID attribute.
| Table of Contents |
|---|
Background
Liberty
While extending SAML, the Liberty Alliance developed a concept they called "federated" identifiers. In their terms, federating a user is accomplished by creating an opaque identifier for the user that is specific to both an IdP and an SP, and is shared only between them. This was termed a "federation handle" and was designed to preserve privacy and prevent correlation of user activity across unrelated services.
...
This is the usually recommended approach to passing an eduPersonTargetedID to SAML 2.0 SPs, including Shibboleth 2.x. Instead of using a SAML attribute, the information is passed in the subject of the assertion:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<saml2:Subject>
<saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
NameQualifier="https://idp.example.org/idp/shibboleth"
SPNameQualifier="https://sp.example.org/shibboleth">
84e411ea-7daa-4a57-bbf6-b5cc52981b73
</saml2:NameID>
</saml2:Subject>
|
...
As an alternative, it's possible to embed the same syntax above inside a SAML attribute with the formal name "urn:oid:1.3.6.1.4.1.5923.1.1.1.10". The main reason for doing this would be to preserve the ability to pass a different kind of identifier in the assertion subject. One use case for this is to support the use of computed/non-reversible values for the "targeted" ID, but use transient, reversible values in the subject to support attribute queries or logout.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<saml2:Attribute xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
FriendlyName="eduPersonTargetedID">
<saml2:AttributeValue>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
NameQualifier="https://idp.example.org/idp/shibboleth"
SPNameQualifier="https://sp.example.org/shibboleth">
84e411ea-7daa-4a57-bbf6-b5cc52981b73
</saml2:NameID>
</saml2:AttributeValue>
</saml2:Attribute>
|
| Tip | ||
|---|---|---|
| ||
See the IdPAddAttribute topic for information on producing this result. The main requirement is to attach an "AttributeEncoder" of type |
SAML 1.1 Attribute
This is the recommended approach to passing an eduPersonTargetedID to SAML 1.1 SPs, including Shibboleth 1.3.x. It is very similar to the attribute-based syntax above and uses the same formal name.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"
AttributeName="urn:oid:1.3.6.1.4.1.5923.1.1.1.10">
<saml:AttributeValue>
<saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
NameQualifier="https://idp.example.org/idp/shibboleth"
SPNameQualifier="https://sp.example.org/shibboleth">
84e411ea-7daa-4a57-bbf6-b5cc52981b73
</saml2:NameID>
</saml:AttributeValue>
</saml:Attribute>
|
...
Finally, the original "botched" syntax is below. Unfortunately, this is probably by far the most common approach one will see today. It is however incorrect.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"
AttributeName="urn:mace:dir:attribute-def:eduPersonTargetedID">
<saml:AttributeValue Scope="https://idp.example.org/idp/shibboleth">84e411ea-7daa-4a57-bbf6-b5cc52981b73</saml:AttributeValue>
</saml:Attribute>
|
...
The three proper forms that rely on a SAML 2.0 NameID element are by default (in the attribute-map) interchangeably handled and reflected to applications as an SP attribute called "persistent-id". By default, the attribute is expressed by concatenating the three pieces of data together with a bang (!) symbol as follows (using the example data above).
| Code Block |
|---|
https://idp.example.org/idp/shibboleth!https://sp.example.org/shibboleth!84e411ea-7daa-4a57-bbf6-b5cc52981b73
|
...
The broken form by default is mapped to an SP attribute called "targeted-id" (to help delineate it from the proper form) and is expressed as a "scoped" string with the following @-delimited form:
| Code Block |
|---|
84e411ea-7daa-4a57-bbf6-b5cc52981b73@example.org
|
...
The proper form was handled by concatenating the three pieces of data together with a bang (!) symbol as follows (using the example data above). This was a hard-coded approach that can't easily be altered without plugging in additional code or altering the source code while building it.
| Code Block |
|---|
https://idp.example.org/idp/shibboleth!https://sp.example.org/shibboleth!84e411ea-7daa-4a57-bbf6-b5cc52981b73
|
The broken form was handled by treating the attribute as "scoped", resulting in the following @-delimited form:
| Code Block |
|---|
84e411ea-7daa-4a57-bbf6-b5cc52981b73@example.org
|
...