Scoped User Identifiers
Recently a serious flaw was found in Office 365:
You should of course review the report and make your own determination but here’s a spoiler: The Office 365 application neglected to scope-check a user identifier, which allowed an arbitrary identity provider to assert any user identifier whatsoever and thereby gain unauthorized access to the application.
Here are a few lessons learned from the Office 365 vulnerability.
Lesson Learned #1
The Office 365 incident revolved around the following SAML attribute:
From a SAML perspective, there are a number of problems with the
IDPEmail attribute shown above but the point that matters most is: The
IDPEmail attribute is not an email address at all. Its value may look like an email address, but in fact, the
IDPEmail attribute corresponds to the User Principal Name (
userPrincipalName) of the existing account of the user in Azure AD.
That’s an important observation: The
IDPEmail attribute is an identifier, and moreover, it is actually used by the Office 365 application for access control. That leads directly to our next observation.
Lesson Learned #2
Some identifiers are explicitly scoped. In other cases, an identifier is implicitly scoped to the issuer. In all cases, a user identifier must be scope-checked by the relying party.
Some user identifiers are explicitly scoped. For example, the so-called scoped attributes
eduPersonUniqueId encode a “scope” directly in the attribute value:
In the above examples, the “scope” is “osu.edu” and “internet2.edu,” respectively. Only one identity provider (IdP) is authorized to assert the scope in each case, namely, the Ohio State University IdP and the Internet2 IdP, respectively. A relying party must check the asserted scope just-in-time and be prepared to reject an identifier if it does not pass the scope check.
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> element is associated with the 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:
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:
By definition, the "sub" claim is implicitly scoped to the issuer. In practice, a relying party would store the pair (iss, sub) and subsequently 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.
At this point we’ve looked at the following identifiers:
SAML2 Persistent NameID
OpenID Connect "sub" claim
These aren’t the only identifiers that need to be scope-checked, however. See the NameIdentifiers topic in the Shibboleth wiki for a more complete list.
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 AFAIK.
Lesson Learned #3
Note well: The application developer must 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 major security holes like the one reported in Office 365.
Of course this assumes the application relies on scoped identifiers to begin 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 email@example.com may be legitimately asserted by any IdP. Conclusion: an email address makes a lousy user identifier
Explicitly scoped identifiers (such as
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
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 thus not added to the user’s session.
Other relying party software might do scope-checking, I don’t know. If your software (SAML or otherwise) does this, please log into Confluence and add a comment to the end of this article.