Role assignment via SCIM and SSO in Frontegg

In typical setups, user identities are managed through SCIM, while authentication is handled via SSO. SCIM is responsible for provisioning users, assigning group memberships, and keeping user data in sync. SSO protocols like SAML manage authentication and can optionally include group information during login.

SCIM-based provisioning

SCIM (System for Cross-domain Identity Management) is an open standard protocol—often used alongside SAML—that enables automatic synchronization of user and group data from an identity provider (IdP) to third-party platforms like Frontegg.

With SCIM, the IdP becomes the single source of truth for user and group data. This means that any change made to users or groups on the IdP side (e.g., adding or removing users from groups, updating user attributes) will trigger an API request to Frontegg to reflect the update in real time.

Role assignment via SCIM

The IdP defines users, groups, and their relationships. The flow for user provisioning with or without group membership is described below:

→ Upon a user's creation through SCIM, they are assigned the default environment role. If group membership is included in the SCIM payload, those groups will be automatically created in Frontegg and the user will be assigned as a member of the group.
→ Roles are not automatically assigned through SCIM, they can be assigned to the user's groups after the groups are created, either by end users from the self-service portal, or via management portal.
→ When a user logs in, any roles assigned through SCIM group membership will be added on top of their default role.

Example

Conditions:

• Environment default role: Read-Only

• User's IdP groups: Admins

Result after provisioning - Read-Only

How roles are calculated

Roles derived from SCIM group mappings are not stored in Frontegg's database. Instead, they are calculated dynamically and injected into the user's JWT during login.

Key behavior

• SCIM roles are computed dynamically at login, based on current group memberships.
• They are not persisted in Frontegg’s database and not reflected on the Frontegg management portal.
• SCIM roles are added on top of the user’s existing role.

SAML/OIDC authentication

When users authenticate via SSO, roles can be assigned through the below attributes:

• Via the default SSO role — if no group mappings apply
• Via group-to-role mappings (available for SAML) — if the SAML assertion contains groups that match mapped roles in Frontegg

Default role assignment

User already exists in Frontegg before connecting through SSO

If the user was already registered on the account in Frontegg before the SAML connection was configured for their email domain, they will retain their existing role that was assigned to them upon user creation. The role will not be updated based on the SAML configuration.

User provisioned after SSO configuration was created

If the user is created on the account after the SAML/OIDC connection is set up (i.e., the user is provisioned via SSO), the assigned role will depend on the SSO response and Frontegg's configuration:

• Group-to-role mapping:
  If the SAML response includes groups, and any of those groups exactly match (case-sensitive) a group mapped to a role in Frontegg, the user will be assigned the corresponding role.

• Default SSO role:
  If the SAML response does not include any matching groups, the user will receive the Default SSO Role configured for the SAML connection.

Example

Conditions:

• First user on the account (tenant), created with Admin role.

• Default SSO role: Read-Only

Result after authenticating via SSO - Admin

Dynamic role evaluation on login

Continuous group checking feature enables dynamic role updates by evaluating the user’s SAML response on every login.

Similar to the role assignment described earlier, Frontegg inspects the groups included in the SAML response. When Continuous Group Checking is enabled:

• Every time a user logs in, the system checks the SAML response for group attributes.
• The user’s role is overridden on each login, regardless of their previously assigned role.
• If the SAML response includes groups that match roles mapped in Frontegg (case-sensitive), the user is assigned the corresponding role(s) along with the default SSO role.
• If no matching groups are provided (either no groups or unmapped groups), the user is assigned only the Default SSO Role configured for the connection.

Continuous group checking feature will override the user’s role on every login, making role persistence dependent entirely on the current SAML response. This behavior can be either enabled or disabled for the entire environment.

Example:

Conditions:

• First user on the account (tenant), created with Admin role.

• Default SSO role: Read-Only

• Continuous group checking is enabled

• User is a member of IdP Admins groups

Result after authenticating via SSO - Read-Only, Admin

Summary & glossary

When users are provisioned via SCIM and authenticate through SSO, roles are assigned either at creation or on login—depending on how group data is handled. With Continuous Group Checking enabled, roles are updated on each login based on SAML group memberships. Without it, roles are assigned once during provisioning, using default roles and SCIM group mappings.