Page History

...

Some identifiers are explicitly scoped. In other cases, the identifier is implicitly scoped to the issuer. In all cases, a user identifier must be scope-checked by the relying party. 

Scoped Attributes

Some user identifiers are explicitly scoped. For example, the so-called scoped attributes eduPersonPrincipalName and eduPersonUniqueId encode a “scope” directly in the attribute value:

<saml2:Attribute FriendlyName="eduPersonPrincipalName"
      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
      Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6">
   <saml2:AttributeValue
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:type="xsd:string">cantor.2@osu.edu</saml2:AttributeValue>
</saml2:Attribute>

<saml2:Attribute FriendlyName="eduPersonUniqueId"
      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
      Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.13">
   <saml2:AttributeValue
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:type="xsd:string">83909230284@internet2.edu</saml2:AttributeValue>
</saml2:Attribute>

...

So how does the relying party know what “scope” an IdP is authorized to assert? Trusted metadata, of course! If you search the InCommon metadata aggregate you will find the following <shibmd:Scope> elements: 

<shibmd:Scope regexp="false">osu.edu</shibmd:Scope>
<shibmd:Scope regexp="false">internet2.edu</shibmd:Scope>

...

Each is associated with the one (and only one) IdP authorized to assert that scope, namely, the Ohio State University IdP and the Internet2 IdP, respectively.

Other Scoped Identifiers

The SAML2 Persistent NameID is explicitly scoped but in a completely different manner. Here is an example:

<saml2:NameID
       Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
       NameQualifier="https://idp.example.org/shibboleth"
       SPNameQualifier="https://sp.example.org/shibboleth"
       >1234567890</saml2:NameID>

The SAML2 Persistent NameID is asserted by the IdP as a child element of the <saml2:Subject> element or the eduPersonTargetedID attribute. In either case, the NameQualifier XML attribute must be scope-checked, that is, it must match the actual issuer of the assertion. Otherwise the identifier should be discarded by default.

All of the examples thus far have been SAML attributes and identifiers but scope-checking is not a SAML issue per se. For instance, the OpenID Connect "sub" claim is a locally unique, non-reassigned identifier for the user (sub = subject). Here is an example of an ID token asserted by an OpenID provider:

{
  "iss": "https://server.example.com",
  "sub": "24400320",
  "aud": "s6BhdRkqt3",
  "exp": 1311281970,
  "iat": 1311280970
 }

By definition, the "sub" claim is implicitly scoped to the issuer. In practice, a relying party would store the pair (iss, sub) and thereafter scope-check an ID token by matching both the "iss" value and the "sub" value. This prevents an arbitrary OpenID provider from asserting an unauthorized "sub" value, intentionally or otherwise.