cube-js · keydunov · May 22, 2026 · May 22, 2026 · May 22, 2026
@@ -136,9 +136,7 @@ the **Viewer** role by default. To assign a different role, expand the
 
 The selected role applies **only when a user is first created** during
 provisioning. Existing users are not modified on subsequent SSO logins or
-SCIM updates. It is applied **in addition to** any roles your identity
-provider sends via the [role attribute](#configure-attribute-mappings)
-(subject to the `rolesMap`).
+SCIM updates.
 
 <Info>
 
@@ -158,13 +156,6 @@ exists.
 
 </Warning>
 
-<Info>
-
-Admin status cannot be set via SSO. To grant admin permissions, update
-the user's role manually in Cube under **Team & Security**.
-
-</Info>
-
 ## Map roles by group
 
 For finer-grained role assignment, enable **Map roles by group** in the
@@ -192,33 +183,17 @@ To configure group-based role mapping:
      ID), use the GUID instead.
    - **Cube role** — pick a default or [custom role][ref-custom-roles].
 
-How it's applied:
-
-- On every SAML SSO login, Cube reads the user's groups from the SAML
-  assertion and assigns the mapped role for each group that matches.
-- Group mapping is **additive**: roles are added on every login, but a
-  user is never demoted on subsequent logins (e.g. removing them from an
-  Entra group does not strip the corresponding Cube role — adjust the
-  user's roles in Cube manually).
-- Users whose groups don't match any entry still receive the
-  [default role](#default-role-for-new-users) on first login.
-- The **Default role for new users** picker continues to apply at
-  provisioning time as the always-on baseline.
-
-The same `groupsRolesMap` is also consumed by [SCIM][ref-scim] when
-groups are pushed and members are added, so a single configuration drives
-both SAML SSO and SCIM group sync.
-
-<Info>
-
-The legacy `rolesMap` setting (a translation from raw IdP role values to
-Cube role names, applied to the **Role attribute**) continues to work
-and is applied **in addition to** `groupsRolesMap`. They read different
-SAML attributes (`role` vs. `groups`) and can be used side by side —
-typical setups using Entra App Roles for the role attribute and Entra
-security groups for the group attribute.
-
-</Info>
+For SAML SSO, group mappings are evaluated **only when a new user is
+auto-provisioned** on first login. If any matching group resolves to a
+Cube role, those roles are assigned to the new user **instead of** the
+configured [default role](#default-role-for-new-users). The default role
+is used as a fallback when no IdP group matches (or when the mapped Cube
+roles no longer exist). Existing users' role assignments are never
+modified by subsequent logins.
+
+The same mapping is also applied by [SCIM][ref-scim] when group
+memberships are pushed, so a single configuration drives both SAML SSO
+and SCIM group sync.
 
 ## Assign users
 

@@ -87,23 +87,16 @@ Users**.
 ## Map roles by SCIM group
 
 If you have configured [Map roles by group][ref-saml-map-roles-by-group]
-on the SAML setup page, the same `groupsRolesMap` is applied whenever
-SCIM provisions group memberships from Entra:
-
-- When Entra adds a user to a synchronized group, Cube looks up the
-  group's **display name** (case-insensitive) in the configured mapping
-  and assigns the corresponding Cube role to that user.
-- Role assignment is **additive**: a user is never demoted on subsequent
-  group sync. Removing a user from an Entra group does not strip the
-  corresponding Cube role — adjust the user's roles in Cube manually.
-- The match is on the SCIM group **display name** that Entra pushes (the
-  `displayName` attribute in the **Group** mapping), not the group
-  object ID. Make sure the **IdP group name** entries in Cube match
-  exactly (case-insensitive) what Entra sends.
+on the SAML setup page, the same mapping is applied when SCIM provisions
+group memberships from Entra — when Entra adds a user to a synchronized
+group, Cube assigns the mapped role to that user. Role assignment is
+**additive**: removing a user from an Entra group does not strip the
+corresponding role; adjust the user's roles in Cube manually.
 
 No separate configuration is required on the SCIM side — once the
-mapping is defined on the SAML page, it drives both SAML SSO login and
-SCIM group sync.
+mapping is defined on the SAML page, it drives both SAML SSO and SCIM
+group sync. Match is on the group **display name** Entra pushes (the
+`displayName` attribute in the **Group** mapping, case-insensitive).
 
 ## Syncing user attributes
 

@@ -119,8 +119,7 @@ the **Viewer** role by default. To assign a different role, expand the
 
 The selected role applies **only when a user is first created** during
 provisioning. Existing users are not modified on subsequent SSO logins or
-SCIM updates. It is applied **in addition to** any roles your identity
-provider sends via the role attribute (subject to the `rolesMap`).
+SCIM updates.
 
 <Info>
 
@@ -163,32 +162,17 @@ To configure group-based role mapping:
      appears in the SAML assertion (case-insensitive).
    - **Cube Cloud role** — pick a default or [custom role][ref-custom-roles].
 
-How it's applied:
-
-- On every SAML SSO login, Cube Cloud reads the user's groups from the
-  configured **Groups attribute** and assigns the mapped role for each
-  group that matches.
-- Group mapping is **additive**: roles are added on every login, but a
-  user is never demoted on subsequent logins (e.g. removing them from an
-  Okta group does not strip the corresponding Cube role — adjust the
-  user's roles in Cube Cloud manually).
-- Users whose groups don't match any entry still receive the
-  [default role](#default-role-for-new-users) on first login.
-- The **Default role for new users** picker continues to apply at
-  provisioning time as the always-on baseline.
-
-The same `groupsRolesMap` is also consumed by [SCIM][ref-scim] when groups
-are pushed and members are added, so a single configuration drives both
-SAML SSO and SCIM group sync.
-
-<Info>
-
-The legacy `rolesMap` setting (a translation from raw IdP role values to
-Cube role names, applied to the **Role attribute**) continues to work
-and is applied **in addition to** `groupsRolesMap`. They read different
-SAML attributes (`role` vs. `groups`) and can be used side by side.
-
-</Info>
+For SAML SSO, group mappings are evaluated **only when a new user is
+auto-provisioned** on first login. If any matching group resolves to a
+Cube Cloud role, those roles are assigned to the new user **instead of**
+the configured [default role](#default-role-for-new-users). The default
+role is used as a fallback when no IdP group matches (or when the mapped
+Cube Cloud roles no longer exist). Existing users' role assignments are
+never modified by subsequent logins.
+
+The same mapping is also applied by [SCIM][ref-scim] when group
+memberships are pushed, so a single configuration drives both SAML SSO
+and SCIM group sync.
 
 ## Test SAML authentication
 

@@ -134,23 +134,16 @@ profile updates.
 ## Map roles by SCIM group
 
 If you have configured [Map roles by group][ref-saml-map-roles-by-group]
-on the SAML setup page, the same `groupsRolesMap` is applied whenever
-SCIM pushes group memberships:
-
-- When Okta adds a user to a pushed group, Cube Cloud looks up the
-  group's **display name** (case-insensitive) in the configured mapping
-  and assigns the corresponding Cube Cloud role to that user.
-- Role assignment is **additive**: a user is never demoted on subsequent
-  group sync. Removing a user from an Okta group does not strip the
-  corresponding Cube Cloud role — adjust the user's roles in Cube Cloud
-  manually.
-- The match is on the **group display name** that Okta pushes via SCIM,
-  not the Okta group ID. Make sure the **IdP group name** entries in
-  Cube Cloud match exactly (case-insensitive) what Okta sends.
+on the SAML setup page, the same mapping is applied when SCIM pushes
+group memberships from Okta — when Okta adds a user to a pushed group,
+Cube Cloud assigns the mapped role to that user. Role assignment is
+**additive**: removing a user from an Okta group does not strip the
+corresponding role; adjust the user's roles in Cube Cloud manually.
 
 No separate configuration is required on the SCIM side — once the
-mapping is defined on the SAML page, it drives both SAML SSO login and
-SCIM group sync.
+mapping is defined on the SAML page, it drives both SAML SSO and SCIM
+group sync. Match is on the group **display name** Okta pushes
+(case-insensitive).
 
 [ref-saml]: /admin/sso/okta/saml
 [ref-saml-default-role]: /admin/sso/okta/saml#default-role-for-new-users