Open in ChatGPTOpen in Claude

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.

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

• A team-level or organization-level SAML configuration.
• Group sync enabled on that configuration by Coralogix.
• Coralogix groups 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

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

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 keeps a record of the memberships it granted and only removes those. Memberships assigned manually by an admin or through SCIM 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

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

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 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 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

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/<team>, 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

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.

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.
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

• 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

• 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/<team> 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.