@david Continuing the discussion from
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
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.