Set up SCIM provisioning

Let your identity provider create, update, and deactivate workspace users through SCIM 2.0, with a default role and a group-to-role mapping.

Written for
admin
Roles
owner, admin
Requires
Owner or Admin (only an owner can map to Owner); Business plan or trial; A verified domain; Browser session with a recent re-authentication
Feature
authentication

SCIM provisioning lets the identity provider manage workspace users: create them when they are assigned to the application, keep their names current, and deactivate them when they leave. It is configured on the SCIM provisioning card under Settings → People → Authentication. SCIM manages workspace users only; client users are managed under Clients. The endpoint reference for integrators is on SCIM.

Before you start

  • You need the Owner or Admin role and the Business plan or the trial.
  • Verify your domain first. SCIM provisions only addresses on a verified domain; a push for any other address is refused.
  • Mapping a group, or the default role, to Owner is an owner-only change.

Steps

  1. Under SCIM provisioning, turn on Enable SCIM provisioning.
  2. Choose the Default role for users no group mapping covers.
  3. Under Group → role mapping, select Add mapping for each group and the role it grants. Group names must match the provider's displayName; matching ignores case. Up to 200 mappings.
  4. Select Create bearer token and confirm your identity. The token is shown once; copy it.
  5. In the identity provider, configure provisioning with the Base URL shown on the card, https://saq.no/scim/v2, and the token.

The card shows the time of the last request, the last error if any, and the number of provisioned users and groups. Revoke stops a token immediately.

Roles and authority

  • A user's role is the highest role among the groups they belong to, else the default role. Mapping changes apply at once, also to people created by JIT provisioning, from the groups claim of their last login.
  • A token carries the authority of the person who created it. A token created by an admin can grant Admin or Member however the mapping reads; only a token created by an owner can grant Owner, and an admin-minted token cannot demote or deactivate an owner. Demoting the creator caps their tokens at the new role; removing them from the workspace revokes their tokens, and another owner or admin creates a new one.
  • A promotion to Owner or Admin revokes the person's personal API tokens, and they must have two-factor authentication before they can enter the workspace.
  • Adopting an existing member never demotes them: a create for an address that is already a member keeps their role when it is higher than the mapping says. From then on, group changes apply the mapping in both directions.

What the identity provider may do

Resource Operations
Users Create, get, list (filter on userName or externalId), replace, update (active, displayName, name, externalId), deactivate, delete.
Groups Create, get, list, rename, add and remove members, delete.

userName is the email address and cannot be changed through SCIM; it is the person's global login. Attributes SAQ does not store (title, phone numbers) are accepted and ignored. The name of a person who already had a SAQ account before SCIM saw them is not rewritten; the profile belongs to the person.

What deactivation does

Setting active to false, or deleting the user, does the same as removing them under Members:

  • The membership ends, with its project memberships and viewer grants.
  • The person's API tokens for this workspace are revoked.
  • Their name on old tickets, comments, and time becomes a placeholder such as "Former member 3".
  • Their account and their other workspaces are untouched.

The SCIM resource keeps its id, so the provider can reactivate the person later; their real name shows again. The last-owner rule applies: an owner cannot be deactivated while they are the only owner.

Rules

  • A person removed by an admin, or who left, is not re-joined by JIT provisioning. A SCIM push does bring them back.
  • People on domains you have not verified (a consultant's personal address, say) cannot be pushed. Invite them instead.
  • Provisioned users use seats like invited ones. When the plan has no seats left, the create is refused.
  • On a plan without SCIM, and in a read-only workspace, existing tokens can still deactivate users but not create or update them, so a downgrade never strands people who should be removed.

Common problems

The provider reports invalidValue on create. The address is not on a verified domain. Verify the domain, or invite the person.

A user was pushed but their role did not change. They are in more groups than the provider puts in the token (see the group overage note on Set up single sign-on), or the mapping's group name differs from the provider's displayName.

An owner was not deactivated. The token was created by an admin, or the person is the last owner.

  • SCIM 2.0 reference Endpoints, attributes, filters, PATCH semantics, provisioning rules, error codes, and example requests for provisioning workspace users and groups from an identity provider.
  • Authentication settings overview How the Domains, Single sign-on, SCIM provisioning, and Local accounts cards work together, what the plan requires, how to verify a domain, and what forcing single sign-on does.
  • Set up single sign-on (OIDC) Connect a workspace to Microsoft Entra ID or any OpenID Connect provider, test and activate the connection, and understand who it logs in and how MFA is handled.
  • Manage members and invitations Invite workspace users by email, set and change their role, remove them or let them leave, and understand how seats are counted.
  • Plan, seats, and subscription The plans and what each includes, the subscription states and the 30-day trial, what read-only mode means, how seats are counted, and how to subscribe, change plan, or be invoiced.