-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add User & Groups to Userinfo #850
Add User & Groups to Userinfo #850
Conversation
1b23b73
to
784a934
Compare
Email: session.Email, | ||
Groups: session.Groups, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For our ORG Groups are part of userInfo Endpoint .. Could you pls handle the Groups claim from UserInfo endpoint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The session.Groups
is populated from the groups
claim in the IDToken in the OIDC Provider (other Providers can populate a session.Groups
how they see fit as well e.g. calling a a provider Userinfo endpoint in EnrichSessionState
to get more data for the session).
Using the session
to populate the userinfo
endpoint is the most provider agnostic way to get data uniformly across all providers.
What were you thinking is potentially missing that you needed with this implementation? I think if you are looking for anything extra dynamic from an IdP userinfo
endpoint that logic belongs in the Provider implemented in EnrichSessionState
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I adapted this function to get the grops claims, Correct me If I am missing anything.
`
// userID cand Groups claim was not present or was empty in the ID Token
if claims.UserID == "" || len(claims.Groups) == 0 {
// BearerToken case, allow empty UserID
// ProfileURL checks below won't work since we don't have an access token
if token == nil {
claims.UserID = claims.Subject
}
profileURL := p.ProfileURL.String()
if profileURL == "" || token.AccessToken == "" {
return nil, fmt.Errorf("id_token did not contain user ID claim (%q)", p.UserIDClaim)
}
// If the userinfo endpoint profileURL is defined, then there is a chance the userinfo
// contents at the profileURL contains the email.
// Make a query to the userinfo endpoint, and attempt to locate the email from there.
respJSON, err := requests.New(profileURL).
WithContext(ctx).
WithHeaders(makeOIDCHeader(token.AccessToken)).
Do().
UnmarshalJSON()
if err != nil {
return nil, err
}
userID, err := respJSON.Get(p.UserIDClaim).String()
if err != nil {
return nil, fmt.Errorf("neither id_token nor userinfo endpoint contained user ID claim (%q)", p.UserIDClaim)
}
claims.UserID = userID
Groups, err := respJSON.Get(p.GroupsClaim).StringArray()
if err != nil {
return nil, fmt.Errorf("neither id_token nor userinfo endpoint contained Groups claim (%q)", p.UserIDClaim)
}
claims.Groups = Groups
}
return claims, nil
}
`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I follow! In the profileURL
where there is fallback email
fetching logic if it isn't in a claim
, your IdP provides access to the groups as well?
That would be a very good addition to the OIDC Provider groups support; I like it.
It is out of scope from this PR -- can you make this into its own PR so we can discuss this issue specifically and work out the best implementation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@NickMeves Sure ..Thank you so much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just looked it up on mine (OneLogin), it includes it too 😄
So yours doesn't include the groups
claim in the IDToken (which I guess makes since you mentioned they give you errors if you ask for the groups
scope). But they have that data available on the profileURL
?
Which OIDC IdP is this? I'm curious about that split and how many other users might be affected by that behavior with their OIDC IdP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case you are feeling adventurous -- I made this Issue for a refactor I noticed this needs after looking at your sample code above: #883
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, would prefer to have a couple of different test cases rather than just the one, but I'll leave that up to you if you want to add more or leave for another day
Good call -- I'll add a few variants later today when I rebase. |
784a934
to
a84ae8d
Compare
@JoelSpeed Finally circled back to this one. Added some more cases of viable session formats in a test table. Ready for another quick look. |
a84ae8d
to
7407fbd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
#834
Description
Add User & Groups fields from the Session to the
/oauth2/userinfo
endpoint. Previously onlyemail
andpreferredUsername
were included.groups
is set toomitempty
in the JSON tag as most installations won't use theallowed-groups
authorization configuration.How Has This Been Tested?
Unit Tests
Checklist: