Skip to main content

​
Overview

Once you connect an identity provider (IdP), your IdP decides who can use Bifrost and what they get. This page explains how that works day to day: what happens when someone signs in, when your IdP pushes a change over SCIM, when someone’s role or group is removed, and when someone leaves. Customers are the one exception. You manage them in Bifrost, and users reach them through their teams and business units. If you are setting up a provider for the first time, start with User Provisioning and your IdP setup guide.

​
The three ways changes arrive

You choose how sign-in and SCIM share the work with the claims sync mode, described in Choosing a sync mode.

​
Choosing a sync mode

In both mode, your IdP’s SCIM push and its sign-in token must agree. Any attribute or group you send over SCIM should also appear in the sign-in claims, with the same values. Bifrost keeps one stored copy of each user’s attributes and doesn’t merge the two: a SCIM push overwrites what the token sent, and the next sign-in overwrites what SCIM sent. A mismatch makes a user’s role, teams, or business units flip each time they sign in and each time your IdP pushes. If you can’t keep the two in sync, use SCIM only.
What changes between the modes:

​
What happens at sign-in

Every time someone signs in, Bifrost:
  1. Verifies the sign-in with your IdP.
  2. Finds the user, or creates them if they’re new (not in SCIM-only mode).
  3. Combines the token with what it remembers. Bifrost keeps a memory of the last value your IdP sent for each attribute. If this token leaves an attribute out, the remembered value is used. If the token includes the attribute, even as an empty value, the new value replaces the old one. This stops a slimmed-down token from accidentally stripping someone’s access, while still letting your IdP remove access deliberately.
  4. Decides the user’s role from your attribute mappings for roles. If no role can be decided, the sign-in is refused (see below).
  5. Updates teams, business units, projects, and access profiles from your mapping rules.
In SCIM only mode the token’s claims are ignored: steps 3 to 5 use what SCIM last sent for the user instead.

​
When a sign-in is refused

There is no default role in Bifrost, not even for the very first user. Every sign-in must resolve to a role, or Bifrost refuses it. A refused sign-in never deletes an account, and a new user who is refused is not created. Whether a returning user keeps their role depends on why the sign-in was refused: When a role is removed:
  • The access profiles that role gave the user are removed with it.
  • Their teams, business units, projects, and other access profiles are still updated from the token, as on a successful sign-in.
  • Their account is kept. Once your IdP sends a value that matches an attribute mapping for roles, their next sign-in gives them a role again.
Admins with User Provisioning: Update permission get a Sign-in refused notification explaining why, at most once an hour per user and reason. To set up your first admin, map an IdP group or attribute to the Admin role before anyone signs in.

​
How roles are decided

​
From your attribute mappings for roles

Each attribute mapping for roles says “when attribute X has value Y, give role Z”. When a user matches more than one mapping, your role resolution setting decides:
  • The role with the most permissions, ties by list order (default) - someone matching both Viewer and Admin becomes Admin.
  • The first matching role, by list order - the order of your mappings decides.
A mapping with the value * matches any value of that attribute. It is an ordinary mapping, not a fallback: it only matches when the attribute is present. If you have no attribute mappings for roles, Bifrost reads the role claim your IdP sends and matches it to a Bifrost role of the same name (ignoring case).

​
When your IdP changes a role

A user’s role always follows your IdP. Each time your IdP sends new data for a user, Bifrost works out their role again from your attribute mappings for roles, and changes or removes the current role to match. A role is never locked in once it’s set. When a role is removed:
  • Access profiles given by that role are removed.
  • If the user is left with no access profile at all, their virtual keys are removed too.
  • Access profiles, teams, and business units from other sources are unaffected.

​
Teams and business units

​
Where a membership comes from

Bifrost records where each team and business unit membership came from, and shows it on the member as Manual or Synced: Things to know:
  • Admins can still add members in Bifrost. A membership added in the dashboard or API is kept through every sync, so you can put people in teams and business units your IdP doesn’t know about.
  • Your IdP takes over a membership it also grants. If an admin adds someone to Platform and your IdP later grants Platform too, the membership becomes Synced and follows your IdP from then on, including removal.
  • Sign-in can remove SCIM memberships. In both mode, a sign-in whose token sends a new value for a mapped attribute removes any SCIM membership that value no longer matches, whether it came from a SCIM user attribute or a SCIM group. In SCIM only mode, a sign-in re-applies your current rules to what SCIM last sent, so it removes SCIM user-attribute memberships only when you’ve changed your rules since the last push. SCIM group memberships are kept until your IdP changes them.
  • Missing teams and business units are created. If a rule names a team or business unit that doesn’t exist, it is created on first use.
  • Removing all your team rules removes the memberships those rules created.

​
Access profiles from your IdP

Access profile mapping rules add profiles. Every rule a user matches applies, and the user holds every profile they match in addition to the profiles from their role and any assigned by hand. See Multiple profiles.
  • A profile the user still matches is left alone, keeping its budget and usage.
  • A profile they stop matching is removed.
  • If an admin assigned a profile by hand and a rule later grants it, the rule takes it over.

​
When someone leaves

​
What removes a user

A failed session refresh on its own never removes anyone. The user is signed out and asked to sign in again. Bifrost removes the user only when, after the refresh fails, it checks with your IdP’s directory and your IdP reports the user as inactive or gone. If your IdP has no directory API, or the check fails, the user is kept.

​
What removal does

When a user is removed, Bifrost:
  • Removes their virtual keys and all their access profiles.
  • Removes their team, business unit, and MCP memberships.
  • Ends their dashboard and desktop-agent sessions.
  • Removes their personal budget and rate limit.
Service accounts are never removed this way.

​
Background sync and sessions

When SCIM Provisioning is on, the background jobs are off and the dashboard’s Sync users and bulk import are unavailable. Your IdP must push every change, including removals. Check that your IdP’s SCIM connector has deprovisioning turned on.
A refresh token can carry fewer claims than the original sign-in token. Because Bifrost remembers each attribute and only treats an attribute as changed when it is actually present, a slim refresh token never strips anyone’s access.

​
Which token Bifrost reads

  • Most providers (Google, Okta, Entra, Auth0, generic OIDC): the ID token.
  • Keycloak: the access token, because Keycloak puts its roles there.

​
Applying rule changes to existing users

Mapping rules apply to each user at their next sign-in or SCIM push. To apply them to everyone now, save your rules and choose one of:
  • Reconcile existing users - Re-evaluates every user against the new rules, using the data Bifrost stored at their last sign-in or SCIM push. In SCIM-only mode it uses what SCIM sent.
  • Sync users from your IdP - Re-reads users from your IdP’s directory (SCIM Provisioning off only). Best when stored data may be out of date.
  • Not now - Users pick up the rules at their next sign-in or SCIM push.
Before running a reconcile:
  • Preview changes for existing users shows a sample of users who would gain or lose a role, team, business unit, access profile, or project, including anyone who would lose every access profile and with it their keys.
  • Check a specific user shows exactly what would change for one person.
  • Keep users with missing data unchanged - When on, a user whose stored data lacks an attribute is left alone. When off (default), a missing attribute counts as empty, so whatever it granted is removed.
Reconcile skips service accounts, users an admin created by hand, and users with no stored data. A preview is tied to the rules it was made with, so if the rules change before you apply it, Bifrost asks you to preview again.

​
Switching modes

A reconcile running when the mode changes stops, and should be run again.
Switching from both to SCIM only assumes your sign-in token and SCIM have been sending the same attributes and groups, with the same values, from the start. Bifrost doesn’t merge the two: it stores the attributes from sign-in claims and overwrites them with the ones SCIM pushes. After the switch, roles, teams, and business units come only from that stored SCIM data. A user whose role came from a token claim that SCIM never sent is refused at their next sign-in, until SCIM sends a value that matches. Check that both carry the same data before you switch.

​
Troubleshooting