Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Faccount-management%2Fuser-management%2Fsaml-group-sync.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Faccount-management%2Fuser-management%2Fsaml-group-sync.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.) # SAML group sync SAML group sync aligns a user's Coralogix group memberships with the groups your identity provider (IdP) sends in the SAML assertion. When group sync is enabled, your IdP drives group membership on every SSO login: adding a user to a group in your IdP grants the matching Coralogix group on their next login, and removing them revokes it. Note SAML group sync is in beta. Coralogix enables it for each SAML configuration; there is no self-serve setting yet. To turn on group sync for a configuration, contact your Coralogix account team. For general SAML setup, see [SSO with SAML](https://coralogix.com/docs/user-guides/account-management/user-management/sso-with-saml.md). ## Why use group sync[​](#why-use-group-sync "Direct link to Why use group sync") Without group sync, SSO controls who can sign in, but an admin still assigns groups by hand or relies on default groups that apply only at provisioning. Group sync closes that gap: * New team members receive the right access on first login, straight from their corporate identity. * Moving a user between IdP groups updates their Coralogix access on the next login, with no manual step. * Access removed in the IdP is removed in Coralogix, so offboarding and role changes propagate. ## What you need[​](#what-you-need "Direct link to What you need") * A team-level or organization-level SAML configuration. * Group sync enabled on that configuration by Coralogix. * Coralogix [groups](https://coralogix.com/docs/user-guides/account-management/user-management/assign-user-roles-and-scopes-via-groups/create-and-manage-groups.md) whose names match the group values your IdP sends. Matching is by name and is case-sensitive; there is no mapping table. ## How group sync works[​](#how-group-sync-works "Direct link to How group sync works") On every successful SSO login for a configuration that has group sync enabled: 1. Coralogix reads the group values carried in the SAML assertion. 2. Each value is matched against the permission groups defined in the team, by exact, case-sensitive name. 3. The user is added to matched groups they are missing, and removed from groups that group sync granted earlier but that no longer appear in the assertion. Group sync never blocks a sign-in. If synchronization cannot finish quickly, it completes in the background, and a sync failure never fails the login. ### A missing group attribute skips the sync[​](#a-missing-group-attribute-skips-the-sync "Direct link to A missing group attribute skips the sync") If the assertion carries no group attribute at all, group sync does nothing for that login rather than treating the user as a member of no groups. An absent attribute is indistinguishable from an identity provider that has stopped sending the claim, so revoking on it would strip access across your organization on a single misconfiguration. An attribute that is present but empty is different: it is a deliberate statement that the user should hold no synced groups, so the sync runs and revokes the memberships it granted. ### Group sync only removes what it granted[​](#group-sync-only-removes-what-it-granted "Direct link to Group sync only removes what it granted") Group sync keeps a record of the memberships it granted and only removes those. Memberships assigned manually by an admin or through [SCIM](https://coralogix.com/docs/user-guides/account-management/user-management/scim.md) are never removed by group sync. Default groups are the one exception. On the login that first provisions a user, the configuration's default groups are taken into group sync's ownership, so if they later stop appearing in the assertion, group sync can revoke them. Default groups added to an already-provisioned user's account stay outside that ownership and are never revoked. ### Unmatched groups[​](#unmatched-groups "Direct link to Unmatched groups") By default, when the assertion carries a group name addressed to the team that matches no existing group, Coralogix creates a group with that name. The created group has no roles or permissions until an admin assigns them, so it grants no access on its own. Ask your account team to turn this off if you would rather unmatched values be ignored. Two kinds of value are never created, because neither is addressed to the team being signed in to: a value qualified for a different team, and, on an organization-level configuration, a value carrying no team qualifier at all. ## Interaction with other group assignment methods[​](#interaction-with-other-group-assignment-methods "Direct link to Interaction with other group assignment methods") Access in Coralogix is additive: a user's effective permissions are the union of all their groups, whatever assigned them. To remove access completely, remove it from the source that granted it. | Method | When it applies | Can group sync remove it? | | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | | Group sync | Every SSO login | Yes, when the group leaves the assertion | | Default groups | On the login that creates or reactivates the membership, or on every login if [Always assign default groups on login](https://coralogix.com/docs/user-guides/account-management/user-management/sso-with-saml.md#advanced-settings) is enabled | Only those granted on the provisioning login | | Manual assignment by an admin | Anytime | No | | SCIM provisioning | Per your SCIM setup | No | If [Always assign default groups on login](https://coralogix.com/docs/user-guides/account-management/user-management/sso-with-saml.md#advanced-settings) is also enabled, the default groups are part of the desired set on every login, and the two settings work together. ## Organization-level SAML configurations[​](#organization-level-saml-configurations "Direct link to Organization-level SAML configurations") For an organization-level SAML configuration, group sync applies across the teams provisioned by that configuration. Because different teams can have groups with the same name, every value must identify its target team. Values with no team qualifier are ignored on an organization-level configuration, so a claim that works on a team-level configuration needs qualifying before it works here. Qualify a team either per value or per attribute: * **Per value**: send `team/group-name`, where `team` is the team's numeric ID or its URL slug. For example, `7000817/Admins` or `production/Admins`. * **Per attribute**: send an attribute named `groups/`, where every value is a group name belonging to that team. Use this form for a group whose own name contains a slash, and to send one attribute per team. The team ID and slug are matched case-insensitively. Group names are not. ## Set up group sync[​](#set-up-group-sync "Direct link to Set up group sync") Warning Configure your IdP to send only the groups meant for Coralogix. Any group name in the assertion that has no matching Coralogix group is created automatically, so an over-broad group claim adds groups you never intended. See [Unmatched groups](#unmatched-groups). 1. Contact your Coralogix account team to enable group sync for your SAML configuration. 2. In your IdP, add a group attribute to the SAML assertion for the Coralogix application. Coralogix reads an attribute named `groups`, or one whose name ends in `/groups`, which covers Microsoft Entra ID's `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` claim. Send only the groups relevant to Coralogix. 3. On an organization-level configuration, qualify each value with its team, as described in [Organization-level SAML configurations](#organization-level-saml-configurations). 4. Make sure Coralogix groups exist with names that exactly match the IdP group names, including case. Coralogix creates any missing groups without roles, so assign roles to them as needed. Group sync applies from the next SSO login onward. ## Troubleshooting[​](#troubleshooting "Direct link to Troubleshooting") * **A user did not get a group**: check that the group name in the assertion matches the Coralogix group name exactly, including case, and that the user completed a fresh SSO login after the IdP change. On an organization-level configuration, check that the value carries its team qualifier. * **No group changes at all**: confirm the assertion actually carries a group attribute. When the attribute is missing, group sync skips the login entirely. * **A user kept a group after being removed in the IdP**: group sync only removes memberships it granted. If the group was assigned manually, through SCIM, or as a default group, remove it at that source. * **Groups lag briefly after sign-in**: large synchronizations finish in the background right after login, so changes appear shortly after sign-in completes. ## Limitations[​](#limitations "Direct link to Limitations") * Matching is by exact, case-sensitive group name. There is no mapping or transformation table. * A slash separates the team qualifier from the group name, so a group whose own name contains a slash can only be synced through a `groups/` attribute. * Group sync applies at SSO login. Users who do not log in again are not re-synced. * Legacy SAML configurations are not supported. * Coralogix audit entries do not yet distinguish group changes made by group sync from other membership changes.