UAA dropping the access token when being integerated with any IDPr
Rohit04061992 opened this issue · 5 comments
SECURITY NOTICE: If you have found a security problem in the UAA, please do not file a public github issue. Instead, please send an email to security@cloudfoundry.org
Thanks for taking the time to file an issue. You'll minimize back and forth and help us help you more effectively by answering all of the following questions as specifically and completely as you can.
What version of UAA are you running?
77.10.0
Problem Statement
We are building multi provider multi tenant system where we are using 2 uaa , federating with each other using oidc , and there we want to have id_token and access_token both to be honored when creating the session in the uaa instance , by default uaa considers id_token coming from external identity provider .
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/187740633
The labels on this github issue will be updated when the story is started.
To be honest, I dont get your issue.
What do you expect from UAA to see finally ?
Alright , let me detail out .
In
So basically when uaa integerates with some IDP and that idp returns as per standard oidc spec access token , id token and refresh token how can uaa take in both the tokens when creating the session.
Ok, thank you. Maybe I do some explains about the flow.
The OIDC flow uses the id_token (only or always) because from standard this is the token which is always a JWT and if you have groups for a user the groups should appear in id_token.
Some IdP have an extra scope for authorization_code flow where you can request scope"openid email groups" and then you get groups claim within the id_token.
The access_token is part of OAuth2 (OIDC includes OAuth2) but by default an access token is opaque and therefore hard to parse . With extra userinfo call an opaque access token could be converted into readable information and then yes groups could be read out there.
So your request is, that the flow should use access_token in exchange instead of id_token ?
May I ask what IdP you are using ? Most of IdPs have configurable Admin UI where you can configure the content of the id_token ( and / or access token) so that you can get groups or roles in id_token.
Hi,
I have found #1463 where it shows UAA supports access_token already.
see
https://github.com/cloudfoundry/uaa/pull/1463/files#diff-111e27ec77818be646f5a9eaa9e8612809f58606834180c9c3f3cb862d02ef77
I tested from one UAA to another UAA with this flow but finally it does not work, but because of minor things we could fix,
So, before such a fix, I would like to know, if it would work for you:
Integration to oauth2 provider using access_token + /userinfo claim mapping.
Because of assumption, that access_token is opaque the userinfo call is need and already there , e.g.
https://github.com/cloudfoundry/uaa/blob/develop/server/src/main/java/org/cloudfoundry/identity/uaa/provider/oauth/ExternalOAuthAuthenticationManager.java#L606-L619