Identifier Properties

This section investigates identifier properties (non-reassigned, opaque, persistent and unique per service/RP) as describe in the specifications of eduPerson SAML and OIDC Sub claims.

Some of the identifier properties are implementation dependent, if s these are marked with (question).

Identifier Properties  Properties   
  Non-reassigned

 Opaque

Persistent Unique per Service 
eduPerson SAML Identifiers     
eduPersonPrincipalName (error)(error) (question)(tick)(error)
eduPersonUniqueId (tick)(tick)(tick)(error)
eduPersonTargetedID (tick)(tick)(tick)(tick)
SAML2 Persistent NameID (tick)(tick)(tick)(tick)
SAML2 transient NameID NA(tick)(error)(error)
      
OIDC Sub claims     
Public (tick)(question)(tick)(error)
Pairwise (tick)(tick)(tick)(tick)

Note: Technically eduPersonPrincipleName may be used in an opaque way, however, this is not common and but this may be unfriendly to enduser as ePPNs may be displayed to endusers

Note: A Pairwise sub may also provide the same sub for "a group of Web sites under single administrative control"

Compatible implementations

Based on the identifier properties, a mapping can be made on what would be compatible implementations, going between OIDC and SAML eduPERSON

SAML to OIDC

Mapping eduPerson SAML => OIDC public sub claim

SAML identifiers compatibility for creating an OIDC public claim

The table blow marks compatible (GREEN) and Incompatible (RED) mappings. In some cases compatibility can arise from making a specific implementation (YELLOW).

Identifier Properties  Properties    
  Non-reassigned

 Opaque

Persistent Unique per Service Remarks
eduPerson SAML Identifiers      
eduPersonPrincipalName (error)(error)(tick)(error)OIDC sub may not be reassigned
eduPersonUniqueId (tick)(tick)(tick)(error) 
eduPersonTargetedID (tick)(tick)(tick)(tick)Public sub must not change per RP
SAML2 Persistent NameID (tick)(tick)(tick)(tick)Public sub must not change per RP
SAML2 transient Name ID NA(tick)(error)(error)OIDC sub may not be reassigned
       
OIDC Sub claims      
Public (tick)(question)(tick)(error) 

Mapping eduPerson SAML => OIDC pairwise sub claim

SAML identifiers compatibility for creating an OIDC pairwise claim

The table blow marks compatible (GREEN) and Incompatible (RED) mappings. In some cases compatibility can arise from making a specific implementation (ORANGE).

Identifier Properties  Properties    
  Non-reassigned

 Opaque

Persistent Unique per Service Remarks
eduPerson SAML Identifiers      
eduPersonPrincipalName (error)(error)(tick)(error)OIDC sub may not be reassigned
eduPersonUniqueId (tick)(tick)(tick)(error)OIDC Per service identifier mandatory
eduPersonTargetedID (tick)(tick)(tick)(tick)Public sub must not change per RP
SAML2 Persistent NameID (tick)(tick)(tick)(tick)Public sub must not change per RP
SAML2 transient Name ID NA(tick)(error)(error) OIDC sub may not be reassigned
       
OIDC Sub claims      
Pairwise (tick)(tick)(tick)(tick) 

Note:For simplicity it is assumed there is only 1 Web sites under single administrative control

OIDC to SAML

Mapping OIDC public sub claim => SAML

SAML identifiers that can be created from an OIDC public claim

The table blow marks compatible (GREEN) and Incompatible (RED) mappings. In some cases compatibility can arise from making a specific implementation (ORANGE).

Identifier Properties  Properties    
  Non-reassigned

 Opaque

Persistent Unique per Service Remarks
eduPerson SAML Identifiers      
eduPersonPrincipalName (error)(error)(tick)(error) 
eduPersonUniqueId (tick)(tick)(tick)(error) 
eduPersonTargetedID (tick)(tick)(tick)(tick)public sub claim is not issues per SP
SAML2 Persistent NameID (tick)(tick)(tick)(tick)public sub claim is not issues per SP
SAML2 transient Name ID NA(tick)(error)(error)transient properties may be implemented by proxy
       
OIDC Sub claims      
Public (tick)(question)(tick)(error) 

Mapping OIDC pairwise sub claim => SAML

SAML identifiers that can be created from an OIDC pairwise claim

The table below marks compatible (GREEN) and incompatible (RED) mappings. In some cases compatibility can arise from making a specific implementation (ORANGE).

Identifier Properties  Properties    
  Non-reassigned

 Opaque

Persistent Unique per Service Remarks
eduPerson SAML Identifiers      
eduPersonPrincipalName (error)(error)(tick)(error)

Technically Opaque pairwise claim can be used,

but this may be very unfriendly to enduser as ePPNs may be displayed to endusers

eduPersonUniqueId (tick)(tick)(tick)(error)Pairwise sub is unique per RP
eduPersonTargetedID (tick)(tick)(tick)(tick) 
SAML2 Persistent NameID (tick)(tick)(tick)(tick) 
SAML2 transient NameID NA(tick)(error)(error)Transient NameID is Unique per service by definition
       
OIDC Sub claims      
Pairwise (tick)(tick)(tick)(tick) 

An OIDC pairwise sub claim can be mapped to a SAML2 Persistent NameID. For example, consider the following ID token:

A sample ID token
{
 "iss": "https://server.example.com",
 "sub": "24400320",
 "aud": "s6BhdRkqt3",
 "nonce": "n-0S6_WzA2Mj",
 "exp": 1311281970,
 "iat": 1311280970,
 "auth_time": 1311280969,
 "acr": "urn:mace:incommon:iap:silver"
}

Suppose the sub claim in the above ID token is a pairwise sub claim. Then that claim can be mapped to the following SAML2 Persistent NameID:

A SAML2 Persistent NameID
<saml2:NameID
   Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
   NameQualifier="https://server.example.com"
   >24400320</saml2:NameID>

 Note that the saml2:NameID/@SPNameQualifier XML attribute has been omitted.

  • No labels

5 Comments

  1. In the "OIDC pairwise sub claim => SAML" table, eduPersonPrincipalName, eduPersonUniqueId, eduPersonTargetedID and SAML2 Persistent NameID should be RED, RED, GREEN and GREEN, respectively.

  2. All of the tables can be simplified by removing the "eduPersonTargetedID" and "SAML2 Transient NameID" rows. On the wire, the "eduPersonTargetedID" attribute contains a SAML2 Persistent NameID element, so adding "eduPersonTargetedID" to this list is redundant. Moreover, the "SAML2 Transient NameID" adds nothing to this analysis since it is not persistent.

  3. In the "OIDC public sub claim => SAML" table, eduPersonPrincipalNameeduPersonUniqueIdeduPersonTargetedID and SAML2 Persistent NameID should be RED, GREEN, RED and RED, respectively. In particular, the eduPersonPrincipalName attribute is not compatible with the public sub claim since only the latter is defined to be non-reassigned.

  4. Once the best attributes to map to are identified, the mapping of the values provides further challenges. Has anyone already spent some thoughts for it?

    The mapping from 'OIDC public sub claim => SAML' is marked as green for eduPersonPrincipalName and eduPersonUniqueId.

    Taking the values from the OIDC example above, that would result in a SAML value of 24400320@server.example.com

    If the iss value would includes a port number and/or a path, it might happen that sub values from multiple servers with an iss just varying by port number or path get mapped into a single SAML value.
    The sub value may include any ASCII character, up to 255 of them, where eduPersonUniqueId may only include up to 64 alphanumeric characters.

    iss and sub are defined in OIDC core 1.0 like this:

    iss REQUIRED. Issuer Identifier for the Issuer of the response. The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.

    sub REQUIRED. Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It MUST NOT exceed 255 ASCII characters in length. The sub value is a case sensitive string.

    1. The mapping from 'OIDC public sub claim => SAML' is marked as green for eduPersonPrincipalName and eduPersonUniqueId.

      Only eduPersonUniqueId is compatible with the OIDC public sub claim.

      Taking the values from the OIDC example above, that would result in a SAML value of 24400320@server.example.com

      If the iss value would includes a port number and/or a path, it might happen that sub values from multiple servers with an iss just varying by port number or path get mapped into a single SAML value.
      The sub value may include any ASCII character, up to 255 of them, where eduPersonUniqueId may only include up to 64 alphanumeric characters.

      I agree with you...I don't think it's feasible to map the OIDC public sub claim directly to eduPersonUniqueId. You could, however, compute a value for eduPersonUniqueId using the following input:

      https://server.example.com#24400320

      that is, by concatenating the "iss" and "sub" values.