SSO groups without completely overriding

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.

1 Like

The add and remove parameters do exactly what you need.

3 Likes

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?

2 Likes

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: