SCIM Provisioning
This page's description of IdP-managed groups (read-only in the Starhive UI, editable only from
your IdP) matches the most recent SCIM work in the codebase (starhive-development: "SCIM 2.0
Groups sync: IdP-managed workspace groups," "Record the groups-sync v2 direction"). Unlike a lot of
what's been migrated so far, this page was already accurate and current.
Starhive supports automatic user provisioning via SCIM 2.0: your identity provider (IdP) creates, updates, and removes Starhive users and groups automatically. Your IdP becomes the single source of truth for workspace access — no invitations to send, no manual offboarding.
SCIM is enabled per workspace on request (contact Starhive), and requires a configured Single Sign-On connection. The walkthrough below uses Okta as an example.
Before you start
- You're a Starhive workspace administrator.
- SSO is already configured.
- You have admin access to your identity provider.
- SCIM has been enabled for your workspace.
If SCIM will be your source of truth for membership, turn off "Automatically Add Users to This Workspace" in your SSO configuration — with it off, only users your IdP provisions (or who are explicitly invited) can enter the workspace.
Step 1 — Generate a SCIM token
- Workspace settings → Single Sign-On → SCIM provisioning.
- Copy the SCIM base URL shown.
- Generate token, and copy it from the dialog.
The token is shown only once — store it securely. Generating a new one immediately invalidates the previous token. Tokens are valid for 365 days.
Step 2 — Connect your identity provider
| Setting | Value |
|---|---|
| SCIM connector base URL | The base URL from Step 1 |
| Unique identifier field for users | userName |
| Authentication | HTTP header — Authorization: Bearer <token> |
| Provisioning actions | Enable Create Users, Update User Attributes, Deactivate Users |
Provisioning is one-way (IdP → Starhive) — no import configuration is needed on your side.
In Okta: on your Starhive SAML application, set Provisioning to SCIM (General tab),
then on the Provisioning tab fill in the integration settings above, Test Connector
Configuration, and under To App enable Create Users, Update User Attributes, and Deactivate
Users. Your IdP's default attribute mappings (userName as email, name.givenName /
name.familyName, displayName) are what Starhive expects.
What gets synchronized
- Users — provisioned immediately as workspace members, no invitation email sent. They're marked IdP-managed in the user list. An existing Starhive account is linked rather than duplicated.
- Profile updates — a name change in your IdP is pushed on the next profile update (requires Update User Attributes).
- Deactivation — unassigning or deactivating the app for a user in your IdP removes them from the workspace, without deleting their account or affecting other workspaces they belong to.
- Groups — groups pushed by your IdP appear as IdP-managed groups: name, membership, and lifecycle are controlled by your IdP, so they're read-only in the Starhive UI. They can be used in permission settings like any other group. Groups created directly in Starhive coexist with them and stay fully editable — see User Groups.
First sign-in
A provisioned user's first SSO sign-in requires a one-time email verification code, unless you've verified their email domain — see Verified Domains.
Troubleshooting
| Symptom | Likely cause / fix |
|---|---|
| "Test Connector" fails with 401 | Token was revoked or regenerated elsewhere, or pasted with a duplicated "Bearer" prefix — generate a new one and re-paste. |
| Names don't update after an IdP rename | Enable Update User Attributes / Push Profile Updates in your IdP. |
| A provisioned user is asked for an email code | Their domain isn't verified — see Verified Domains. |
| One user shows a provisioning error, others sync fine | That user is the workspace owner, who can't be deprovisioned — transfer ownership first, or leave them unmanaged. |
| Users stop syncing after SSO config was deleted/recreated | The new config has a new SCIM token; update it in your IdP, then remove and re-add the app's group assignment to re-provision everyone, and re-verify domains on the new config. |