SCIM Provisioning

Audience: Identity Engineers, Platform Engineers
Time: ~30 min (IdP app + Control Plane)
Prerequisites: SSO already configured (recommended); Super Administrator access; SCIM feature enabled in your release

SCIM 2.0 automates user lifecycle from your identity provider into the Control Plane — create, update, group membership, and fast deprovisioning.

Overview

Your IdP (Okta, Entra ID, Google Workspace, etc.) pushes user and group changes to Control Core instead of manual CSV or admin UI entry.

Design goals:

• RFC 7643 / 7644 User and Group resources
• Sub-100ms session revocation when a user is deactivated or deleted in the IdP
• Bearer-token SCIM clients registered per tenant in scim_client_configurations

Planned endpoints

Authentication: Authorization: Bearer <scim-client-token> (token shown once at client creation; only hash stored server-side).

Deprovisioning SLA

When the IdP sets active: false or deletes a user:

1. Control Plane marks the user suspended
2. All active sessions for that user are revoked via the Redis revocation bus (target under 100ms p99)
3. Audit event recorded for SIEM export

Troubleshooting (design validation): If sessions remain active after IdP deprovision in a staging test, verify SCIM PATCH reached the Control Plane (HTTP 204), Redis revocation subscribers are running on all API replicas, and clock sync is healthy.

IdP setup checklist

1. Create a SCIM app in your IdP pointing at your Control Plane base URL + /scim/v2.
2. Generate a SCIM bearer token in Control Core (admin UI or API when available).
3. Map IdP attributes to Control Core username, email, display name, and role/group.
4. Enable push updates for create, update, and deactivate events.
5. Run a test user create → sign-in → deactivate → confirm immediate API 401.

SSO vs SCIM

Use both: SSO for authentication, SCIM for authoritative lifecycle.

Next steps

• SSO with SAML & OIDC
• Session management
• User management