Mapping IdP Groups to Roles
Group-to-role resolution is the single authorization join for federation and is provider-agnostic by construction: the transport (Entra/Okta over SAML or OIDC, Google or Cognito over OIDC, on-prem AD/OpenLDAP over LDAP) normalizes to a group-claim set, and that set is matched against role definitions independent of which IdP produced it. Roles decide which DB DevOps sections the user sees, and the server refuses a non-admin's changes in a section none of their roles include (403 SECTION_REQUIRED), on top of the built-in role's own checks. Only custom roles take groups; a user's built-in role comes from the role mapping above.
Configuration
- Administration → Roles → create or edit a custom role and select the sections it grants.
- In the role's Identity Provider Groups field, list the IdP group names/claims (comma-separated) that map to it, e.g.
DB-Admins, platform-engineers. Matching is on the claim value and case-insensitive, for providers that emit opaque group identifiers (Entra object GUIDs, unmapped LDAP DNs) enter the value the assertion actually carries. - Save. The same group names apply across every configured IdP, so a single mapping table covers a mixed-provider estate.
Resolution on Login
Each SSO login recomputes membership: the incoming claim set is intersected with every custom role's mapped groups, and when anything matches, the user's custom roles become exactly the matching ones (provisioning the account on first login), replacing roles assigned by hand. An empty intersection leaves the user's custom roles as they were, so a claim-plumbing failure neither locks them out nor grants more. If the roles cannot be applied, sign-in still succeeds with the user's current roles and the server logs a warning. Because resolution is live per login, revoke or elevate by editing IdP group membership; for accounts that should keep hand-assigned roles, leave their groups out of every role's mapping.