Yeah, I feel it’s better to be explicit, for v1 of this feature set at least. I haven’t come across a use case yet where auto-creation has been really needed, i.e. the group couldn’t just be set up and configured by the site admin prior to any claims being handled.
Perhaps we could move to auto-creation as an option after we do the explicit version?
In terms of Group Settings, it would be something like
Settings Section: Membership (i.e. the existing section)
Settings Group Title: Authentication Management
Settings:
- Service: List of authentication services. “All” would be an option. This setting would also function as an “enabled / disabled” state for this feature set. i.e. the default would be “None”.
- Claim: text input to identify id token claim. The “description” for this feature (perhaps in a post here on meta) would explain the supported formats, e.g. boolean, comma-delineated string etc.
- Mode: see below
Yes, if there was a strict / permissive setting we’d have to explain it concisely. I think the way to approach that would be to focus on “addition” and “removal”. You could perhaps describe it like this
Setting: “Mode”
Option 1 (permissive):
- Label: “Add Members”
- Description: “Allow members to be added to this group on authentication”
Option 2 (strict):
- Label: “Add and Remove Members”
- Description: “Allow members to be both added and removed on authentication. This will disable manual membership controls.”
The reason I’m keen to keep the “permissive” option is that when working with clients on this kind of thing before, that is the most common use case, i.e.
-
The main need is to allow for access to a group depending on a state in an external service
-
The need to remove access depending on the state in the external service is more marginal, i.e. people do lose access and should be removed, but this is relatively less important
-
There is often a desire to retain the ability to manually control membership in Discourse. When I’ve implemented the “strict” approach this has been “surprising” (i.e. “Why did person X lose membership?”) despite explaination(s) and it functioning (technically) as it should.
Yes this is important, as folks will often wonder “why” someone is added or removed, particularly in strict mode, and we (i.e. “Discourse”) won’t have control over the veracity of the claims the external auth service is making.
Perhaps a new type of “Remove User” and “Add User” action that includes the auth service responsible for the action, i.e. “Remove User ([service name])”.