SSO groups without completely overriding

AI-generated summary

The discussion revolves around using SSO groups in Discourse without overriding existing groups. The original question posed by sok777 is whether it’s possible to pass membership groups from an external website via SSO without removing users from their current trust_level group and other manually assigned groups.

Falco suggests using the add_groups and remove_groups attributes in the SSO payload to achieve this. These attributes allow for specifying group membership without overriding existing groups. sok777 confirms that using add_groups would not remove users from their current groups.

However, mattdm raises a concern about users being removed from groups on the SSO side but not being added to the remove_groups list. Falco clarifies that this would indeed result in the user remaining a member on the Discourse site.

The discussion further explores the use of sso overrides groups and how it affects group membership. Falco recommends enabling this setting and passing the relevant groups in the groups parameter to ensure accurate group membership. mattdm links to a related topic on Meta Discourse regarding the impact of sso overrides groups on trust_level and staff groups.

Is there a way to use groups via SSO without overriding all existing groups?
For example, I want to pass two types of membership groups from my external website - let’s say group_a and group_b.
However, I don’t want users to lose their current trust_level group and also, some users have their own groups which then allows them to access a private category.

By reading forum posts here and the manual it seems that selecting the SSO groups will override and remove users from all existing groups, unless the SSO will pass their current groups too. That’s an issue, because it means I’ll have to manually update each user’s current group in the external site’s db.

Am I missing something here?
Many thanks folks.

The add and remove parameters do exactly what you need.

Thanks! so using the add_groups would NOT override or remove the users from current groups? And I would still be able to manually create and allow groups?

If this is used, and a user is removed from the group on the SSO side but not added to the remove_groups, they’ll stay a member on the Discourse site, right?

What do you mean by “this”, groups or the individual add_groups and remove_groups ?

What are the exact params and endpoint you are calling?

The individual ones. I’m not actually doing anything yet, just trying to understand.

So, SSO usually happen during the login flow.

All the groups, add_groups and remove_groups parameters are optional, and deal with group membership.

This has nothing to do with having a valid user on the site. Unless you make all the site categories only readable by members of specific groups.

Sorry, let me rephrase. Let’s say we have 1200 groups in our SSO. If we want to have group membership synced with that without using sso overrides groups, if someone is a member of three groups, those three groups would need to be listed in add_groups and the 1197 others in remove_groups (just in case they were previously in one of those 1197 and have been removed)?

In your case, and assuming your don’t have other manual groups in the Discourse instance, you should enable the sso overrides groups site setting, and pass the 3 groups the user is currently a member of in the groups parameter of the SSO payload.

On login we will ensure that the user is a member of those 3 groups and not a member of every other manual group.

Ok, that brings me to this question: What happens to trust level and staff groups when using sso overrides groups? :slight_smile: