About eduPersonTargetedID
Customers often have questions about the attribute eduPersonTargetedID (ePTID), which is sometimes used in SAML SSO assertions. Here are answers to common questions.
What is eduPersonTargetedID?
ePTID is a persistent, non-reassigned, opaque, unique identifier for a user.
"eduPersonTargetedID is designed to prevent two relying parties receiving user information from an Identity Provider from correlating user information, thus revealing the user identity when it is not intended."
From https://spaces.at.internet2.edu/display/federation/user-attr-eptid
For more information, see: Internet2's wiki about eduPersonTargetedID
Why is eduPersonTargetedID deprecated?
1. ePTID is case-sensitive, which makes accurate mapping as a targeted ID problematic. It may not be clear if IDENTITY@institution.edu is the same as identity@institution.edu. Matching is difficult and ambiguous.
2. ePTID is generated on demand, not stored in LDAP, nor defined in a SAML profile. There needs to be more consistency in its creation and use. Industries need to standardize on an identifier with a SAML profile and foster its adoption and use across industries.
From https://spaces.at.internet2.edu/display/federation/why-is-eptid-deprecated
What is InCommon’s recommendation for eduPersonTargetedID?
- If you are not currently using eduPersonTargetedID, don’t start using it
- If you are currently using eduPersonTargetedID, start planning a transition away from it. The InCommon Technical Advisory Committee is working on guidance, https://spaces.at.internet2.edu/display/federation/user-attr-pairwise-id#userattrpairwiseid-UseintheInCommonFederation
- Use the SAML V2.0 Pairwise Subject Identifier (pairwise-id) instead of eduPersonTargetedID.
"[Pairwise-id] is a long-lived, non-reassignable, unidirectional identifier suitable for use as a unique external key specific to a particular relying party. Its value for a given subject depends upon the relying party to whom it is given, thus preventing unrelated systems from using it as a basis for correlation."
From: https://spaces.at.internet2.edu/display/federation/user-attr-pairwise-id#userattrpairwiseid
Cirrus Identity recommends following InCommon’s guidance about eduPersonTargetedID. However, Cirrus Identity still supports eduPersonTargetedID using the same algorithm that Shibboleth implemented and will help you configure it to work with the Cirrus Bridge if needed.
If your organization has implemented eduPersonTargetedID using another method, please contact Cirrus Customer Success for additional guidance.
How to Add an Attribute to Assert eduPersonTargetedID
Cirrus has created some rules to help configure eduPersonTargetedID. The same rules can be applied when configuring the attribute in either Azure AD or Okta tenants. In both cases, Cirrus Engineering will first need to configure the Bridge to support ePTID based on what is currently configured for your IdP. This configuration is usually based on the configuration and salt contained in the IdP configuration. Cirrus Customer Success will ask for the current IdP configuration during the initial setup of the Bridge.
The examples below show screenshots from our Azure AD test environment.
First - add a claim "cirrus.rule.targetedId" as follows. If you use the default Shib algorithm, the value should be “alg=shib” as shown below.
Second - add a claim "cirrus.attr.targetedIdSrc" with an attribute value that matches what you used for Shib. See below.
This will generate a properly formatted ePTID attribute in the assertion.