Managing group membership via authentication

[angus (Angus McLeod)]

@david

We should try to keep the super-technical stuff out of the group settings if possible. Having to link to syntax documentation probably means it should be simplified, or relegated to the admin site settings. I think we should leave that part up to each auth plugin to implement, because it can vary so much.

I agree.

@david

Taking OIDC as an example, that plugin would add a new site setting openid_connect_roles_claim . If using Okta, the admin would configure that as groups . I think string array is a pretty standard format for OIDC, but we could explore more complex options here if really necessary.

hm yes, however there are cases in which supporting a boolean claim makes sense. But yes, I agree let’s keep it simple for now by just supporting a string array.

Doing it authenticator by authenticator, I guess we’d also have a group_sync_enabled? method in the Auth::Authenticator which would be overriden in individual authenticators, and in the generic authenticators upon the existence of a value in the relevant setting.

That actually raises an interesting question. This could also be used by the specific service authenticators, such as facebook (“groups”?), google (“groups”?) and discord (“roles”?). Not sure whether their id tokens would contain such info, but perhaps worth considering from a technical design perspective (i.e. the ability to add this down the track). Not a primary concern for v1 though I don’t think.

@david

To receive this information, Auth::Result would be given a new roles attribute, which accepts a simple array of strings. Core will then take this (in Auth::Result#apply_user_attributes! ), and load it into a new UserAssociatedRoles table with columns ( provider_name , user_id , role ). This UserAssociatedRoles table gives us the ‘membership source identification’ you mentioned in the OP.

Those mechanics sound fine, however I’m curious why we’ve switched to using “roles” instead of “groups” here. Not a huge issue, but want to be sure there’s not something I’m missing.

From a UX perspective I can see confusion arising out of that use of nomeclature (i.e. “roles” and “groups” at the same time), even if it’s grounded in a useful technical distinction. Also possible developer confusion if coming to this without this background context.

I like the seperate table, however perhaps we should have a foreign key association with user_associated_accounts instead of provider_name? It could be useful in things like cleanup operations. I guess the answer to that question is partly how much we want the group/role association to be interlinked with the associated account from a product perspective. Would there be any downside to linking the two now?

** Edit, I guess we already have the association via the user_id.

@david

Role names would be prefixed with the provider_name . Autocomplete would be based on all the existing values in the UserAssociatedRoles table, but we would also accept non-autocompleted values in case the role hasn’t been seen by Discourse yet.

That sounds fine, however I’m just thinking that we also have this information on a provider basis by virtue of the site setting you proposed, which would also cover the case of when the role hasn’t been seen. Perhaps there’s a way to use Discourse.authenticators here, i.e. an in-memory list of providers’ and their claims?

@david

• Add members when they have a matching role from the auth provider
• Remove members when that role disappears
• Allow adding/removing in Discourse as well
• If an admin tries to remove a user which was added via an auth provider, show a warning “this user may be added again next time they log in”

I think that’s a good compromise. Particularly if we also have the site setting mentioned below.

@david

For sites that really don’t want that, we could have a site setting like remove_group_membership_when_auth_role_lost (default true).

On a plugin (i.e. authenticator) basis? If so, I’m on board. That should service that need for v1.

Good summary of the user flow Pending the relatively minor suggestions I’ve made, I’m on board with the direction.