This question came up on the ADFS PR: https://github.com/oauth2-proxy/oauth2-proxy/pull/1021/files (it uses UPN for email in the end it looks like)

In related Azure PRs, I raised the question of if UPN is appropriate for User instead of the IDToken subject.

This would be a substantial breaking change to azure unless it is toggle-able with a configuration.

I'm not an Azure user, so I'll need to defer to the Azure community-base on the best practices around this.

CC: @weinong @codablock

Go ahead and toss up a PR. At the very least the idiomatic changes you have made in those commits look good. I had it on my TODO list to jump back into the Azure provider and clean it up, it needed some standardization if I recall to streamline the style & syntax with our other providers after a few different contributors last touched it.

Keep in mind if you aren't already - we don't want to directly do anything special with the headers -- we should only populate the SessionState fields from the providers. Anything we set there will get consumed by other parts of the proxy appropriately.

@acobaugh you can configure which claim to use for email by --oidc-email-claim=upn

Oh Nice - is that new for Azure from your latest PR @weinong -- Or have we had that for a while when we added it for the OIDC provider?

If its from your latest PR that I just approved, my memory is getting bad fast 😅

well, extracting email claim from id_token was new from my PR. At the same time, thanks for all your refactoring to make oidc verifier and options available to azure provider. So I just take advantage of that :)

@weinong Ah, I'll have to try that. Not sure how I missed that. Would it still be desirable to set both user and email headers? In any event, once consensus is reached, I wouldn't mind putting together a PR to make this provider more idiomatic.

@weinong Ah, I'll have to try that. Not sure how I missed that. Would it still be desirable to set both user and email headers? In any event, once consensus is reached, I wouldn't mind putting together a PR to make this provider more idiomatic.

In general we've standardized on User matching the ID Token subject, and this is pretty constant across the providers (that have claims).

So let's not touch that field.

Someday in the future, for any OIDC based providers, we plan to support adhoc Claim -> Session -> Header support (this will be after v8 with structured configs is released). That probably unlocks the customizability you want for the UPN field I imagine?

At the moment, you can only fudge with the oidc-email-claim like @weinong mentioned.

oidc-email-claim is a noop for the azure provider in v7.0.1 based on testing I just did.

My understanding of User was that value would be exposed via x-auth-request-user, and it isn't currently getting set to anything. The Azure provider doesn't seem to do anything with sub. When I looked at sub in Azure, it wasn't set to anything I can decipher, unless I just don't understand the encoding mechanism.

I also don't see the mechanism that would allow oidc-email-claim to do anything, as everything is pretty hard-coded to only ever use email in the Azure provider. The generic OIDC provider appears to use it, though, but that's not the provider I'm using.

And yes, arbitrary claim->session->header support would be helpful to us, but not for UPN, but rather for custom claim mappings where we want to expose extension attributes via headers to our UI apps.

So I guess my next question is: is oidc-email-claim intended to only be used by the generic oidc provider, or do we want a specific option just for azure, eg. azure-email-claim? The oidc provider is the only one that consumes that option from what I can tell.

I think allowing Azure to use the same option oidc-email-claim is preferable over adding a new option

@acobaugh would you mind sharing the list of arguments you used?

This is what I had set up in our dev instance. But, unless I'm reading something wrong, there's nothing in the Azure provider today that uses the EmailClaim option.

      cookie-domain: ".dev.k8s.psu.edu"
      cookie-name: "_oauth2_proxy_k8s_dev"
      session-cookie-minimal: "false"
      set-xauthrequest: "true"
      pass-access-token: "true"
      oidc-email-claim: "upn"

@acobaugh in my PR, oidc verifier won't be set unless oidc issuer is set. try --oidc-issuer-url=https://sts.windows.net/{tenant-id}/