-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Improvements to Google group authentication #172
Comments
First off. passing 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. |
Done. Opened #174. I'll work on cleaning up the logic to use the new api calls hopefully tonight. |
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 The auth appears to work when I only do domain based authorization, however. It's only when introducing a group that I have issues. |
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. |
@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! 🥇 |
So we're finally looking closer into group level access with oauth2_proxy and we discovered some problems with the current approach.
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?
The text was updated successfully, but these errors were encountered: