@david Continuing the discussion from https://github.com/discourse/discourse-openid-connect/pull/7#issuecomment-758082333 As you probably can guess, I’m also keen to see a stable solution to this problem, which is not specific to the openid-connect plugin. Let’s see if we can figure out a way forward To pick up on the point you’ve raised. How do you decide which groups to add and remove the user from? And how does that affect manually adding/removing users from groups in Discourse itself? a user authenticates via OIDC with groups ['group1', 'group2'] In the discourse UI, the user is added to group3 later, the same user authenticates via OIDC with groups ['group1'] Inspecting this as a human, we can see that the final state should be group1, group3 (group2 should be removed). But I don’t think there is enough state being tracked to make that decision programmatically. Similarly: a user authenticates via OIDC with groups ['group1', 'group2'] In the discourse UI, the user is removed from group1 later, the same user authenticates via OIDC with groups ['group1', 'group2'] Now what should happen? An admin has explicitely removed the user from group1 , but OIDC just added them back. This is very confusing UX for the admin. We may need some way to identify groups as ‘externally managed’, and hide all the add/remove UI :thinking: I think there’s a few ways we could handle this issue (they’re non-exclusive) Group and token attribute identification In any implementation, explicit identification of which groups can have their membership managed via authentication; and which attributes in an auth token govern group membership should be required, whether that be via site settings, group settings or otherwise, and default should be “off”. Strict or permissive handling Handling is “strict” if a user is removed when the group is absent from the identified token attribute. Handling is “permissive” if a user is not removed when the group is absent from the identified token attribute. The strict/permissive state would be set on a per-group basis. There’s an example of how you could do this in a site setting here: Handle groups by mattcg · Pull Request #7 · discourse/discourse-openid-connect · GitHub. The same approach could be done via a group setting. As you suggest, you could disable group membership addition / removal via the groups admin if the handling was “strict”. Membership source identification You could also possibly store the source of the group membership in the group_users table to allow for a “mixed” approach within a group, i.e. an admin can’t remove memberships created via auth token. The more I think about this, the more I’m thinking this should be done via group settings.

Following this with interest — and throwing this in as related Does `sso overrides groups` work with Oauth2? For my use case, I’d be perfectly happy with the Discourse Connect behavior to be implemented for other auth providers.

Great :slight_smile: we’re getting there. [image] david: I am a little hesitant about the ‘secondary authorization’ thing, and also the provider_domain column. Can you elaborate some more on why they’re needed? Seems like they’re quite google-specific… is there a reason we can’t request the admin.directory.group.readonly scope during the first auth request? And maybe just prefix the group name with the domain? (or exclude the domain entirely, since I assume people will only be using this with a single google ‘hosted domain’?) I’ll deal with each in turn. Incremental authorization The reason you can’t request group permissions on the first request is that you don’t know who’s signing in, or what they’re comfortable with sharing. You could restrict google associated group mapping to people using the google_oauth2_hd setting, however this would limit the scope of the feature a fair bit. Having a team that uses google apps in addition to “public” users who also want to use google auth is relatively common. *edit I should clarify, that if you ask for a groups scope and the user cannot give it (e.g. their HD has not delegated authority to non admin users as described above) then the auth will fail. You can’t request optional scopes alongside required scopes. Moreover, that approach, i.e. asking for a groups scope up front as a standard practice in implementing this in the various authentication methods, would be arguably more google-specific than the alternative, as you don’t always have the equivalent of the hosted domain system to restrict login to. For example, I could be wrong, but I don’t think there’s a way to restrict Github OAuth2 login to a specific github organisation. In other words in a number of cases you’d be left with the choice of asking everyone who uses that auth method to grant the relevant groups scope, or not using the feature. That approach may work in some contexts, but not in many. This incremental authorization approach gives different auth methods more flexibility in implementing the feature. It’s true Google has been championing incremental authorization in the OAuth2 space, for example the working papers on the subject have all been written by a googler [image] OAuth 2.0 Incremental Authorization OAuth 2.0 authorization requests that include every scope the client might ever need can result in over-scoped authorization and a sub- optimal end-user consent experience. This specification enhances the OAuth 2.0 authorization protocol by adding... However the concept is not Google-specific (other people don’t necessarily call it “incremental authorization”). It’s relatively common in different forms in mobile apps, and is being adopted in OAuth2 by other providers. For example, here’s Facebook’s docs on the same subject. You’re probably familiar with the field already, but it is considered “good practice” to tell people you’re about to ask for more permissions than the standard basic info; and maybe why. If the user clicked “Sign up with Facebook” in a Discourse login form, and then, in addition to their email, they were also asked for access to their facebook groups, they might drop off. Facebook puts it like this As a general rule, the more permissions an app requests, the less likely it is that people will use Facebook to log into your app. In fact, our research shows that apps that ask for more than four permissions experience a significant drop off in the number of completed logins. This raises the question of whether it’s a good idea to be asking for additional scopes at the point of authentication in the first place, and basically I concluded that we don’t really have any other good options. There’s the need to have immediate access to groups in some scenarios (as you alluded to), and there’s also just the reality that without it being asked up front many users would not take an additional step to authorize their groups on a service, in say their profile, or the groups page. It has to be done at the point of authentication, which brings us back to the issue referenced above, and why I implemeted a “secondary authorizatiton” system. It is indeed intended to be a lightweight “system” insofar as it is relatively easy for another service, say Facebook or Github, to implement a secondary authorization request to obtain access to the user’s groups after they have authenticated and optionally passing a certain test relating to their basic info. Each provider just needs to Return a result with secondary_authorization_url Use the state parameter to detect which authorization request the user is up to Provide a omniauth_secondary_authorization_description for users/omniauth_callbacks/secondary_authorization.html.erb. e.g. this is the one for google, which the user sees before they confirm the secondary authorization redirect As you've signed in with a %{domain} email, we need to ask for permission to view your %{domain} groups. None of these parts are google-specific. What I would like to do here is allow the user to say “no” to the secondary request, and still authenticate. In the Google Apps HD scenario this isn’t really an issue as if their account is part of a hosted domain, then they’re unlikely to want to, or be in a position to, say no. However it should be accomodated to allow for the full range of authentication secnarios here I think. Finally, it should also be noted that secondary authorization is not required for associated_groups to work. An auth provider can just ask for the groups scope up front, and then add the groups to the auth result after receiving the first response. Indeed, we should probably build that in as an option to the basic oauth2 and openid connect plugins. Provider Domain I do think there needs to be some form of secondary identifier in the associated_groups table that’s readable by the site admin. There are a number of scenarios in which a group name by itself may not be enough. There’s the possibiity of name conflicts across each services’ equivalent concept, e.g. multi-domain google group management (you can have multiple domains in one workspace too) mutli-org github group management multi-server discord role management etc We could change domain to namespace perhaps. We could include it in the group’s name, but would that give as any advantages? It may be useful to query by the “domain” or “namespace” at some point. Yes, perhaps namespace would be better than domain. The reason it needs to be “admin readable” is that it’s used in the label seen by the admin in the groups UI, partly for disambiguation purposes. I’m mulling whether it makes sense to attempt to also store a provider_id here (if one exists). Could be useful down the track perhaps. [image] david: We need to be careful here. Any group memberships need to be assigned before the user loads the site for the first time. Otherwise, they won’t see group-specific things the first time they log in (e.g. secure categories). So I think changes to user_associated_group records should be processed synchronously. But for group_associated_group record changes, I think you’re right. Changes there could affect thousands of users, so they will need to be processed in_batches. I think I’d start by doing it synchronously, with a loading spinner in the UI. That way, admins will clearly be able to see when it’s running/done. If we see it getting close to 30 seconds (the unicorn request timeout), then we might need to think about a background job. We might also need to think about adding some DistributedMutex locking here. For example, if a user logs in while a group_associated_group change is being processed, what happens? Happy to discuss this kind of stuff on GitHub once we get the overall architecture finalised. Yup, agree with all this, and thanks for the tips. I’ll give this part a go and we can discuss it further on the PR.

@david I’ve just pushed a few updates on this one including DistributedMutxes and in_batches in group_associated_group Acceptance tests (already had rspec) Will need some further work no doubt, but it’s currently working according to spec and all tests are passing. Take it for a test drive, let me know what you think and what changes you’d like. https://github.com/discourse/discourse/pull/12446

Perhaps worth marking it as a non draft for now?

Hi @angus! I’m curious if you’ve made any further progress on this? I’m very interested in the simple “strict” behavior, as I understand it, and since we control our Oauth2/OpenID connect provider, I’m not worried about the “secondary authorization” case. Any chance that something like that could land sooner? If it’s any help, our environment is documented here: Infrastructure/Authentication - Fedora Project Wiki, and I’ve configured DIscourse to request oauth2 scope openid profile email https://id.fedoraproject.org/scope/groups Basically, all I want is: Leave the trust level and staff groups alone Add the user to any existing Discourse groups in the list from SSO that are in the list if they’re not there already Remove the user from any groups they are in that aren’t in the list I freely admit I don’t understand all the intricacies… is there a complication I don’t understand?

I’ve put aside time this weekend to work on this Matt. I’ll have an update next week, probably on the PR on github. https://github.com/discourse/discourse/pull/12446

Awesome — thank you so much. I don’t mean to nag, but Discourse Support suggested that posting in this topic would be the best way to see the current state of things. :slight_smile: I’m excited for your work on this, because there is so much we can do with the Fedora discourse sites once we have this that we just can’t right now!

Note that I’ve made an updated draft PR with a new approach (incorporating changes requested by @david on my last attempt). As mentioned in the comments to the PR, I’m looking to finish it off sometime this week. https://github.com/discourse/discourse/pull/14835

Just so I’m not getting myself excited for no reason — this says “google”… will it also work with non-google oauth2 sso?

It’s a generic system, but the first supported use case will be groups in a google workspace. Once the system is in place adding support for additional providers will not be too difficult.

Managing group membership via authentication

Development

jimkleiber (Jim Kleiber) March 10, 2022, 11:57pm 29

I’m also excited for this to be available for non-Google oauth2/openID logins…any update on if/when that option might be available?

Topic		Replies	Views
Memberpress: how to add users to groups upon Sign up WordPress	39	10178	January 9, 2022
Manage group membership in Discourse with WP Discourse SSO Administrators groups , wordpress , payments , how-to	77	19258	May 7, 2023
Allow moderators to add a member to a group? Feature	48	11664	December 28, 2017
Groups API - manually syncing group membership? Development rest-api	8	1853	December 13, 2022
Improved Group Members Management Feature rfc , spec	30	11763	January 7, 2016

Managing group membership via authentication

Related topics