SCIM provisioning

SCIM (System for Cross-domain Identity Management) lets your identity provider push user and group changes into ScaiDrive automatically. New hire → IdP creates the account → SCIM pushes to ScaiDrive → user is ready to sign in. Termination → IdP disables → SCIM pushes → ScaiDrive suspends.

ScaiDrive's SCIM endpoint follows SCIM 2.0 (RFC 7644). It's tested against Okta, Entra ID (Azure AD), Google Workspace SCIM, and OneLogin.

When to use SCIM#

You don't need SCIM if:

• Your org is small and users sign in just-in-time via SSO.
• You're fine with users self-creating on first SSO sign-in.

You probably want SCIM if:

• You have > a few hundred users and want central lifecycle management.
• You need accounts pre-created before users sign in (e.g., to assign shares before day one).
• You need automatic deprovisioning when someone is terminated in the IdP.
• You need group memberships kept in sync between systems.

Enabling SCIM#

Identity → SCIM → Enable SCIM.

ScaiDrive issues:

• SCIM Base URL — https://drive.example.com/scim/v2/
• SCIM token — bearer credential. Shown once; treat as a secret. Rotate from the same page.

In your IdP's provisioning configuration, paste the base URL and token. Then map attributes (see below).

Attribute mapping#

ScaiDrive's User resource has these standard SCIM attributes:

Plus the enterprise extension:

And a ScaiDrive extension for the things SCIM doesn't standardize:

Group resources support members, name, and externalId.

Provisioning patterns#

One-way push (most common). Your IdP owns identity; ScaiDrive is a downstream consumer. Disable creating users directly in the ScaiDrive admin console (System → Settings → User management → Read-only mode) so admins can't accidentally create accounts that drift from the IdP.

Just-in-time + SCIM fallback. Allow users to self-create on first SSO sign-in and have SCIM push the same users. Matching by externalId or sub keeps the two paths from creating duplicates. This is the default and it's fine.

Selective SCIM. Some IdPs let you filter which users get pushed. Common pattern: only push users in a specific IdP group (scaidrive-users) — keeps the ScaiDrive user list smaller than your whole org.

Group provisioning#

Groups can be pushed by SCIM too:

• ScaiDrive creates a group with a matching slug.
• Membership is overwritten by SCIM on each sync — don't hand-edit SCIM-managed groups in the admin console (a banner warns you).
• Delete a group in the IdP → SCIM marks it deleted in ScaiDrive (memberships are revoked, but shares the group was on don't lose their grants; they just have no members from that group).

Rate limits#

The SCIM endpoint enforces 600 requests/min per token. Standard IdPs (Okta, Entra ID) stay well below this on normal syncs. For initial bulk imports you may need to throttle in your IdP's connector settings.

Troubleshooting#

• "401 Unauthorized" → SCIM token is wrong or has been rotated. Reissue from the SCIM page.
• Users push but are inactive after → check the IdP's mapping of active; some IdPs default to false for new accounts pending an email confirmation.
• Group memberships flapping → the IdP is doing PATCH-incremental sync; check the IdP's SCIM connector logs. ScaiDrive prefers PUT replacement of group members, which most IdPs support as an alternative.
• Audit trail of SCIM activity → Compliance → Audit Log, filter by event_type=scim.*.

What's next#

• Identity providers — the SSO side.
• Users and groups.