Skip to content
This repository has been archived by the owner on Jan 24, 2019. It is now read-only.

Improvements to Google group authentication #172

Open
jburnham opened this issue Nov 18, 2015 · 5 comments
Open

Improvements to Google group authentication #172

jburnham opened this issue Nov 18, 2015 · 5 comments

Comments

@jburnham
Copy link
Contributor

So we're finally looking closer into group level access with oauth2_proxy and we discovered some problems with the current approach.

  1. Either Google added or I missed the fact that you can query the list of groups a user is a member of in a single call https://developers.google.com/admin-sdk/directory/v1/reference/groups/list passing in userKey.
  2. Once someone successfully authenticates with any oauth2_proxy, theoretically they could successfully log into a different proxy instance that does restricts users to a group that user is not a part of because it uses the same cookie name. This assumes the cookie is valid and doesn't need to be refreshed, therefore the second proxy would forego the need to check group membership. The workaround would be to use different cookie names for group restricted services but that seems hacky. Ideally the same oauth2_proxy cookie payload should be able to be used across your infrastructure, even services that require specific groups. If you try to hit a service where you are not a member of that group you should get a 403 ( I suppose this might cause the cookie to be invalidated, but I don't see a problem with that )

For 1, this is easy enough to do so I'll work on that however for 2 I'm not sure what would be the best solution. #28 mentioned the ability to pass a header to backend services that shows the list of groups a member is a part of. The main issue that I can think of is how to store the list of groups a member is a part of in a secure, immutable way so that oauth2_proxy can easily check group membership on every request and also pass the group membership as a header. Do I add onto the SessionState type to add a Groups field that also gets serialized and encrypted into the oauth cookie? Perhaps instead I add a Provider specific part to the SessionState that allows each provider to put whatever it wants in there and it's up the the provider on how to store and parse it beyond it being a string in SessionState ( So for google, it can store groups, but github could store org and team memberships). Does anyone have a different idea on how this can be done?

@jehiah
Copy link
Member

jehiah commented Nov 18, 2015

First off. passing userKey to /v1/reference/groups/list is awesome. I'm pretty sure that's new (or i'm going to be kicking myself). I think that works out better than listing all members for the group (current implementation) but it unfortunately still requires an admin token and can't be called with a user token to get the users group list (oh well).

Can you open a separate issue for the second item (clarification/improving multiple oauth2 proxies using different group restrictions and cookie sharing). I don't think it's a good choice to stuff group membership in the cookie, and the periodic re-validation that's implemented now (to avoid upstream oauth calls on every requests) causes some limitations here. I think there could be ways to workaround it though but let's separate that discussion from the group listing.

@jburnham
Copy link
Contributor Author

Done. Opened #174. I'll work on cleaning up the logic to use the new api calls hopefully tonight.

@jadametz
Copy link

Not sure this is relevant to the enhancements in how the API is called, but I'm having general problems getting the group specific auth to work in the first place. I've followed the instructions in README.md as best as I could (although they don't seem to exactly align with Google's UI) but am ultimately getting a 403 for a user that is in my provided group.

The auth appears to work when I only do domain based authorization, however. It's only when introducing a group that I have issues.

@Vestaxis
Copy link

We had this issue as well. For us the problem was that we had members in a group that didn't belong to our organisation. The current code assumes that all group members are users of the Google account that the API is polling. If you want to add users to a group with external email addresses, you have to disable the user checking here: https://github.com/bitly/oauth2_proxy/blob/master/providers/google.go#L188.

For us this meant that we didn't want to check whether a member of a group matched the user id of the person signing in (https://github.com/bitly/oauth2_proxy/blob/master/providers/google.go#L211) but simply whether the email address of a member matched the email address of the person signing in.

@danielsmith-eu
Copy link

@jehiah @jburnham - has there been any progress on this?

This issue affects me too, and it sounds like @Vestaxis solution would work for me - It'll take me a bit of time figuring out Go (not used it before), so if this is something that can be done without too much effort by anyone who's more familiar, I'd appreciate it! 🥇

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

5 participants