Skip to content
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

Merged
merged 2 commits into from
Nov 27, 2020

Conversation

NickMeves
Copy link
Member

@NickMeves NickMeves commented Oct 19, 2020

#834

Description

Add User & Groups fields from the Session to the /oauth2/userinfo endpoint. Previously only email and preferredUsername were included.

groups is set to omitempty in the JSON tag as most installations won't use the allowed-groups authorization configuration.

How Has This Been Tested?

Unit Tests

Checklist:

  • My change requires a change to the documentation or CHANGELOG.
  • I have updated the documentation/CHANGELOG accordingly.
  • I have created a feature (non-master) branch for my PR.

@NickMeves NickMeves requested a review from a team as a code owner October 19, 2020 02:00
@NickMeves NickMeves force-pushed the is-834-userinfo-expansion branch from 1b23b73 to 784a934 Compare October 19, 2020 02:01
@NickMeves NickMeves linked an issue Oct 19, 2020 that may be closed by this pull request
Email: session.Email,
Groups: session.Groups,

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?

Copy link
Member Author

@NickMeves NickMeves Oct 29, 2020

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.

Copy link

@anannaya anannaya Oct 29, 2020

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

}
`

Copy link
Member Author

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?

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.

Copy link
Member Author

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.

Copy link
Member Author

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

JoelSpeed
JoelSpeed previously approved these changes Nov 8, 2020
Copy link
Member

@JoelSpeed JoelSpeed left a 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

@NickMeves
Copy link
Member Author

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.

@NickMeves
Copy link
Member Author

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

@JoelSpeed Finally circled back to this one. Added some more cases of viable session formats in a test table. Ready for another quick look.

@NickMeves NickMeves force-pushed the is-834-userinfo-expansion branch from a84ae8d to 7407fbd Compare November 26, 2020 03:01
Copy link
Member

@JoelSpeed JoelSpeed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@JoelSpeed JoelSpeed merged commit 2706909 into oauth2-proxy:master Nov 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

More fields in /oauth2/userinfo
3 participants