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.