vmware-tanzu
Option to bypass /userinfo
Is your feature request related to a problem? Please describe.
I'm trying to use pinniped with ADFS 2016 and have it return the email of users.
ADFS won't return "extra" claims (such as email) if the resource = urn:microsoft:userinfo. I cannot find any official documentation that affirms that but it's what I found on the internet and also what I see when I test.
In the same time, ADFS won't accept a request to the endpoint /userinfo if the resource ≠ urn:microsoft:userinfo. https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/development/ad-fs-openid-connect-oauth-concepts#high-level-ad-fs-authentication-flow
Even if pinniped got all required claims from the id token, if available it will request the /userinfo endpoint (which is fine). If the request to the endpoint fails, pinniped retursn an error and the authentication request is a failure.
Describe the solution you'd like
In my case, the solution is to not request the /userinfo endpoint as it's not working. What I tested successfully is to add "true ||" in the test for the existence of this endpoint (https://github.com/vmware-tanzu/pinniped/blob/main/internal/upstreamoidc/upstreamoidc.go#L402).
My request is to have an configuration node to bypass this call.
Describe alternatives you've considered
We tried numerous times to configure ADFS to accept the pinniped's request on /userinfo, without any success.
We tried adding the parameter resource=<adfs web api identifier> or scope=<adfs web api identifier>/openid <adfs web api identifier>/profile …. Those request are valid and correctly parsed by ADFS (messing with the identifer produces an error) but it does not allow to request /userinfo.
We tried
We got an 401 from ADFS calling /userinfo and this message:
UserInfoListener.ValidateAccessToken: The access token in the request doesn't have required audience 'urn:microsoft:userinfo'. Actual audience
As mentioned above, using resource=urn:microsoft:userinfo makes ADFS happy with calling the /userinfo endpoint but we won't have any policy applied thus no email claim (only upn, sub, unique_name, but we really need email).
Are you considering submitting a PR for this feature?
- How will this project improvement be tested?
- How does this change the current architecture?
- How will this change be backwards compatible?
- How will this feature be documented?
Additional context
Previous issue: https://github.com/vmware-tanzu/pinniped/issues/2238
