...
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.
Other Identifiers
At this point we’ve looked at the following identifiers:
...
All of the above identifiers have well-defined scope semantics. The IDPEmail attribute, OTOH, is ill-suited for cross-domain access control. While its name and value suggest an email address, the underlying identifier (userPrincipalName) has no documented scope semantics AFAICT.
| Tip | ||
|---|---|---|
| ||
| If your federating software doesn’t scope-check user identifiers, then that responsibility must be taken up by the application software (i.e., the application developer). |
You should take away at least this: The application developer should scope-check all identifiers asserted by untrusted 3rd parties. This is especially true if the identifier is used for access control. Failure to do so may lead to gaping security holes like the one reported in Office 365.
Of course this assumes the application relies on scoped identifiers to being with. In particular, an application should never rely on an email address to identify a user. An email address is not scoped. For instance, the email address trscavo@gmail.com may be legitimately asserted by any IdP. An email address makes a lousy user identifier
Explicitly scoped identifiers (such as eduPersonPrincipalName, eduPersonUniqueId, and SAML2 Persistent NameID) are preferred since smart middleware can do the work for you. For instance, the Shibboleth SP software scope-checks the above identifiers by default. In the case of the scoped attributes eduPersonPrincipalName and eduPersonUniqueId, Shibboleth checks the actual scope against the authorized scope(s) in metadata. In the case of the SAML2 Persistent NameID and eduPersonTargetedID (which are equivalent), the software checks the NameQualifier XML attribute against the actual issuer. In any case, if the software detects a mismatch, the user identifier is not accepted and therefore not added to the user’s session.
Other SP software might do scope-checking, I don’t know. If your software (SAML or otherwise) does this, please add a comment to the end of this article.