Supporting Microsoft OIDC

The issue

What version of UAA are you running?

4.30.0

How are you deploying the UAA?

I am deploying the UAA

• using cf-deployment

What did you do?

We configured an OIDC identity provider for Microsoft using this discovery document, in order to allow logins from any Microsoft product (i.e. not just a specific Azure AD)

What did you expect to see? What goal are you trying to achieve with the UAA?

We’re in the process of enabling Microsoft single sign-on for tenants, whose accounts may be in any directory. We expected that, given the global discovery document, the login flow would just work.

What did you see instead?

We found that Microsoft issues tokens whose iss claim is different from the issuer given in the discovery document. This caused UAA to believe the token was invalid.

After some investigation, we found that the iss claim includes the GUID of the organisation to which the user belongs in Microsoft land (as is evident from the discovery doc: https://login.microsoftonline.com/{tenantid}/v2.0). For some users (like Outlook or Hotmail users), the organisation GUID is well known. However, for corporate users, it will be their Azure/Office 365 tenant id.

For us, it is impossible to set an issuer URL that UAA would accept for all users.

The suggestion

@46bit and I have put together a small change in our paas-uaa fork which introduces a new configuration flag for OIDC providers: issuerValidationMode. The flag has three possible values: strict (the default), domain_only, and none.

The aim our of change is to provide a less strict form of issuer claim validation, in order to support scenarios like that posed by Microsoft SSO. In domain_only mode, the only the host portion of the token’s iss claim must match that of the configured URL. This is done as a string comparison, so subdomains are not considered to match a parent domain. E.g. sub.domain.org is not a match for domain.org, or vice versa 
 We’ve deployed this change in to our CloudFoundry deployment, and verified that we can do a successful Microsoft SSO login.

Why an issue and not a PR

We’re raising this as an issue and not a PR because we’re not sure if this necessarily the right approach to take, and we’d like some feedback on the problem and our proposed solution.

[46bit]

@aeijdenberg While I appreciate your concern I wouldn’t underestimate how much investigation we did to get to this issue being filed and our modification running. We use Microsoft’s oid claim, described by https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens as:

oid: The immutable identifier for an object in the Microsoft identity system, in this case, a user account. This ID uniquely identifies the user across applications - two different applications signing in the same user will receive the same value in the oid claim. The Microsoft Graph will return this ID as the id property for a given user account. Because the oid allows multiple apps to correlate users, the profile scope is required to receive this claim. Note that if a single user exists in multiple tenants, the user will contain a different object ID in each tenant - they’re considered different accounts, even though the user logs into each account with the same credentials.

[aeijdenberg]

Notwithstanding the above, I just realised precisely what you mean - it’s not just the docs that says {tenantid} in the URL, they actually bake that into the Issuer URL returned as: https://login.microsoftonline.com/{tenantid}/v2.0.

Sigh - that makes things more difficult. I wonder if the reason for doing is that unlike Google’s Identity Platform, where all users (when identified by email) draw from a global namespace, whereas in Microsoft’s Identity Platform, can users with the same email address for example existing in multiple tenancies?

i.e. perhaps one needs the combination of tenancy and username/email in order to uniquely identify a user? Else I could spin up a new Azure AD tenancy, create a user with name “[e-mail]” and then use your sign-on (which ignores the tenancy) to impersonate you on your UAA?