User Provisioning (SCIM)

SSO decides who can sign in. SCIM decides who is a member.

Without SCIM, signing in through your identity provider is not enough on its own — someone still has to invite each person into the organization by hand, and remove them by hand when they leave. SCIM closes that gap: assign the Stallion app to a user in your identity provider and they appear as a member; unassign them and their access is gone, along with every active session.

What SCIM controls

Roles

SCIM can set one thing: the member's organization role.

Per-project roles stay in the console. If you grant someone Release Manager on a specific project, that grant survives every SCIM role change — it is deliberately treated as outranking anything derived from the organization role.

SSO Admin is not provisionable

SSO Admin cannot be assigned over SCIM, by design. It is the break-glass role that lets a named person sign in with a password if your identity provider goes down, and it governs who may change your SSO configuration.

If your identity provider could grant it, a compromised provider could mint itself a password bypass around the very SSO it controls. And because Stallion requires every organization to keep at least one SSO Admin, a routine deprovisioning sweep could otherwise remove the last one and lock you out of your own account.

SSO Admins are managed by SSO Admins, in Members. A SCIM request that would remove your last SSO Admin is refused with a 409, and the member keeps their access — you will see the rejection in the activity log on the SCIM settings page.

Setting it up

1. Go to Settings → Federation → User provisioning (SCIM).
2. Select the Default role — what a provisioned user gets when none of their groups is mapped. Most organizations leave this as Member.
3. Click Generate token. Copy both the SCIM Base URL and the bearer token.

4. Paste both into your identity provider's provisioning settings and run a sync. See the Microsoft Entra ID guide for the exact fields.
5. Once your groups have synced, map them to roles in the Group role mapping table.

The base URL is region-specific

Your organization lives in a region, and the SCIM URL shown on the settings page is the one for your region. A request sent to the wrong regional host is refused with an error naming the correct one — it is never silently accepted, so a misconfiguration fails loudly rather than half-applying changes.

Group role mapping

Groups carry no permissions on their own. A group becomes a Stallion role only when you map it, so the dozens of unrelated groups your identity provider pushes are simply ignored.

• Only groups your identity provider has actually synced appear in the table — you map a group that exists rather than typing a name that may never match.
• A user in several mapped groups gets the highest role among them.
• A user in no mapped group gets the default role.
• Mappings are keyed on the group's stable identifier, so renaming a group in your identity provider does not break it.

Changing a mapping applies immediately to everyone currently in that group — you do not have to wait for the next sync.

Turning SCIM on and off

Pause stops your identity provider changing anything while leaving every existing member exactly as they are. Pausing is not a mass deprovision.

Revoke destroys the token and disables provisioning. The correlation records between Stallion accounts and identity-provider users are kept, so re-enabling later resumes where it left off instead of re-creating everyone as new.

Enabling SCIM on an existing organization

Members you invited by hand before turning SCIM on are adopted, not duplicated — your provider's first sync claims them rather than failing on them.

Adoption does not change anyone's role. Turning SCIM on is not a re-grading of your organization: until your identity provider actually says something about someone, they keep exactly the access they had. In particular the admin who set the organization up does not get demoted by their own first sync.

A member becomes Managed by SCIM — the badge in Members, and a disabled role picker — only once a group mapping actually assigns their role. Before that, their role is still yours to edit in the console, because SCIM has not decided it.

While your organization has no group mappings at all, SCIM does not touch roles for anyone. It still creates and removes members; it simply has no opinion about what they should be. The activity log says so explicitly:

roles unchanged — no group role mappings configured yet

Keeping an account outside SCIM

Sometimes you want an account your identity provider cannot touch — most often the person who set the organization up and configured SSO. There are two levels, and they transfer at different moments.

Do not assign them to the SCIM application. This is the one that matters. Assignment is what creates their SCIM record, and from that point your identity provider owns their lifecycle: unassigning them later removes them from the organization, along with every active session. Left off the SCIM application entirely, they are invisible to provisioning — nothing syncs them, nothing can deprovision them.

They can still sign in. Sign-in is governed by your OIDC application, which is a separate assignment; see the two applications.

Do not put them in a mapped group. If they are assigned to the SCIM application but you still want to control their role by hand, keep them out of every group you have mapped to a Stallion role. A mapped group is what transfers role ownership and locks the console picker.

Troubleshooting

The SCIM settings page shows the last request received, the last error, and a log of recent provisioning activity, including anything Stallion refused.