How to Map Identity Provider Groups to RudderStack Groups

Manage RudderStack group membership from your identity provider by mapping its groups to RudderStack groups.
Available Plans
  • enterprise

  •   4 minute read  

SCIM group sync is in Public Beta and available in the Enterprise plan only. Contact RudderStack Support to enable it for your organization.

This guide explains how to link groups in your identity provider (IdP) to RudderStack groups, so that users get the right access when you add them to a group in your IdP.

Overview

Group mapping links an IdP group name to one or more RudderStack groups. Your IdP controls who is in each group, while workspaces and policies stay in RudderStack.

Group mapping works with:

  • Okta and Azure Entra ID: Membership stays in sync through SCIM.
  • Google Workspace: RudderStack doesn’t support SCIM with Google Workspace, so it assigns groups only at the user’s first sign-in. See Map identity provider groups in RudderStack for details.

How it works

  1. You create RudderStack groups and configure a workspace policy for each one.
  2. You make your IdP groups visible to RudderStack — by pushing them over SCIM, or by sending them in the SAML response for Google Workspace.
  3. You map each IdP group to the RudderStack groups it should grant.
  4. Users in the IdP group become members of the mapped RudderStack groups and inherit their policies.

One IdP group can map to several RudderStack groups, and several IdP groups can map to the same RudderStack group.

Example

The following mapping gives a set of users view-only access to a sandbox workspace:

IdP groupRudderStack groupGroup workspace policy
sandbox-usersSandbox View OnlyView-only access to the sandbox workspace

Anyone you add to sandbox-users in your IdP gets view-only access to that workspace. You don’t need to do anything in RudderStack for each new user.

Before you begin

  1. Contact the RudderStack team to enable group mapping for your organization.

  2. Ask an organization Admin to manage the mappings, or to give you the Admin role.

  3. Create the RudderStack groups you want to map to, and configure their workspace policies.

  4. Make your IdP groups available to RudderStack:

Add a mapping

  1. Go to Settings > Access Management and click the Group Mapping tab.
  2. Click Add mapping.
Group Mapping tab in Access Management
  1. In the Add group mapping dialog, enter the IDP group name. It must match the group’s display name exactly as it appears in your IdP.
  2. Under RudderStack groups, select one or more groups.
  3. Click Add mapping.
Add group mapping dialog with two RudderStack groups selected

If the IdP group name is already mapped, RudderStack adds your selected groups to its existing ones.

Edit a mapping

  1. In the Group Mapping tab, click the edit icon next to the mapping.
  2. Under RudderStack groups, add or remove groups. You can’t change the IDP group name.
  3. Click Save.

If you remove a group, the dialog shows a warning and the Save button turns red. For Okta and Azure Entra ID, saving removes members of the IdP group from the removed RudderStack group unless another of their IdP groups still maps to it. For Google Workspace, update existing users’ permissions manually in RudderStack; group mappings apply only at first sign-in.

Edit group mapping dialog showing a warning about removing a RudderStack group

Remove a mapping

  1. In the Group Mapping tab, click the delete icon next to the mapping.
  2. Review the RudderStack groups listed in the confirmation dialog.
  3. Click Remove.

For Okta and Azure Entra ID, members of the IdP group lose the listed RudderStack groups, except any that another of their IdP groups still maps to. For Google Workspace, removing a mapping affects future first sign-ins only; revoke existing users’ access manually in RudderStack.

How membership syncs

The following table applies to Okta and Azure Entra ID:

ActionResult
A user joins a mapped IdP groupThe user gets all the RudderStack groups mapped to that IdP group.
A user leaves an IdP groupThe user loses its mapped RudderStack groups, except any that another of their IdP groups still maps to.
A user is deactivated in your IdPThe user is removed from every mapped RudderStack group in your organization.
You add, edit, or remove a mappingThe change applies straight away to the IdP group’s current members.
An IdP group is deletedIts members lose the mapped RudderStack groups, except any that another of their IdP groups still maps to. The RudderStack group and the mapping stay, so the mapping applies again if you push a group with the same name.
You add a mapping before the IdP group is pushedRudderStack saves the mapping and applies it when the group arrives.

Example

Consider the following mappings:

IdP groupRudderStack groups
data-engineeringProd Editors, Dev Editors
analyticsProd Viewers, Dev Editors

A user in both IdP groups gets all three RudderStack groups. If they leave analytics, they lose Prod Viewers but keep Dev Editors, because data-engineering still maps to it.

See more

Questions? Let's figure it out together.

Join the RudderStack Slack community to connect with other users, customers, and the RudderStack team — or reach out for direct support.

Slack community Join now Email support Reach out