ID-token does not propagate 'preferred_username' from Azure ID Token

[jmspring]

Per Azure AD docs Azure will not expose the email even if the claim is required. However, it does return a 'preferred_username' which is not propagated up from dex.

Returned in the id_token from AD:

{
  "aud": "96a785df-28b3-46d7-a2c7-faa0ac583f70",
  "iss": "https://login.microsoftonline.com/c439dff3-770f-4dfb-b30a-1829e265cd78/v2.0",
  "iat": 1492794891,
  "nbf": 1492794891,
  "exp": 1492798791,
  "aio": "ASQA2/8DAAAAGrYAPsRBk+FF+nf8Ei4amfbYMMyewzFWxaAxMWH1so0=",
  "name": "John Smith",
  "oid": "9a810744-a596-4cc8-889e-60bebde91437",
  "preferred_username": "jsmith@k8soidctest.onmicrosoft.com",
  "sub": "2WPQS2QH_gdtHPgKxw91SOS5LEVMiTzLQF-oJzBcJu4",
  "tid": "c439dff3-770f-4dfb-b30a-1829e265cd78",
  "uti": "m12W4eWvf0qYO__Dwe0DAA",
  "ver": "2.0"
}

In AD, in order to get information about the user, a second call is required to the /me endpoint in Microsoft Graph.

The claims dex returns:

{
  "iss": "https://dex.plusonetechnology.net:5556",
  "sub": "CisyV1BRUzJRSF9nZHRIUGdLeHc5MVNPUzVMRVZNaVR6TFFGLW9KekJjSnU0EgVhenVyZQ",
  "aud": "example-app",
  "exp": 1492881592,
  "iat": 1492795192,
  "at_hash": "AN4VYbnwmjkR_EPkdmypcA",
  "email_verified": false,
  "name": "John Smith"
}

Thoughts?

[jmspring]

@ericchiang after some input from a colleague, it looks like the "emailClaim" configuration that is noted here would actually handle the case of dealing with Azure AD. Is there a reason the "emailClaim" mapping was removed? Is there any reason not to add it back? (It looks like there was a big rewrite).

[ericchiang]

@jmspring that logic wasn't ported as part of the v2 switch. Maybe @rithujohn191 would be okay with adding a configurable email claim back in?

[jmspring]

Thanks Eric.

I'm happy to attempt the work if he is. We have a few customers interested in OIDC solutions integrating with Azure AD and this would be the logical / easiest fix. I don't know if/when Azure AD will expose / support the email claim for OIDC. Per this one needs to directly call the Graph API endpoint to get email info. Which, given the bearer token Sex gets, would be possible to populate the OIDC call to dex from the client app, but would require a custom connector for AD, most likely.

[rithujohn191]

@jmspring if you would like to take this up I would be more than happy to review the PR. If not I could add it in myself.

[jmspring]

@rithujohn191 - some of us are having an internal hackfest this week, I'll take a stab starting this week. I'll use the old PR as reference.

[jmspring]

So - adding the emailClaim plumbing was pretty straight forward (small change), however, that will only satisfy the Dex requirement for an email address internally. Unfortunately, to integrate with Kubernetes, the email needs to be verified.

Near term, to integrate Dex, using a username of the form - is the likely only option.

I'll have to look at the Dex approach to verifying the email address. Within Azure AD, a second call to the Graph API is needed to get specific details about the user (at least for now).

[srenatus]

With #1459, you should be able to configure this to use preferred_username. Also, since this issue, there's a "microsoft" connector that consumes the mentioned "Graph" API. 🧹 Cleaning this up. 😃