...
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.
...
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 or UPN) of the existing account of the user in Azure AD.
...
Some identifiers are explicitly scoped. In other cases, the an identifier is implicitly scoped to the issuer. In all cases, a user identifier must be scope-checked by the relying party.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<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> |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<shibmd:Scope regexp="false">osu.edu</shibmd:Scope> <shibmd:Scope regexp="false">internet2.edu</shibmd:Scope> |
Each <shibmd:Scope> element 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.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<saml2:NameID Format Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier NameQualifier="https://idp.example.org/shibboleth" SPNameQualifier SPNameQualifier="https://sp.example.org/shibboleth" >1234567890< >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.
...
By definition, the "sub" claim is implicitly scoped to the issuer. In practice, a relying party would store the pair (iss, sub) and thereafter 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.
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.AFAIK.
| 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). |
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 trscavo@gmail.com may be legitimately asserted by any IdP. Conclusion: 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 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.
...