Skip to main content
SCIM provisioning lets your identity provider create, update and deactivate Compliance Command Center accounts automatically, so joiners and leavers are handled by your directory instead of by hand. It is a licence-gated add-on (algovoi-command-center-scim) that ships in the Verifiable Compliance Suite and pairs with the console’s existing SSO (SAML, OIDC, LDAP, Active Directory) and its authenticator-app MFA. It reuses the console’s own identity model rather than adding a parallel one:
  • a SCIM User is a console account, in the same store your SSO providers read;
  • a SCIM Group is one of the four fixed RBAC roles (admin, compliance_officer, auditor, viewer); no new role or group concept is introduced;
  • every provisioning change (create, update, deactivate, role assignment) is appended to the console’s Falcon-signed, offline-verifiable audit chain, so provisioning is itself compliance evidence.
Deprovisioning is a soft deactivate: DELETE marks the account inactive, it can no longer sign in, and the account plus its audit history are retained as evidence. Nothing is hard deleted.

​
1. Enable it

The add-on is off by default and licence-gated. It becomes active when three things are true:
  1. Installed. It ships in the suite bundle; a standalone deployment installs algovoi-command-center-scim alongside the console.
  2. Licensed. Your AlgoVoi suite bundle_license (the same one that unlocks the rest of the suite) satisfies it. With no valid licence the console does not mount the SCIM endpoint at all, so it stays unreachable, fail-closed.
  3. Reachable over TLS. The endpoint lives under your console origin at /scim/v2.
When those hold, the console exposes the SCIM base URL:

​
The SCIM bearer token

The SCIM endpoint authenticates with a dedicated bearer token, entirely separate from human sign-in. Set it explicitly, or let the console bootstrap one on first run:
Your IdP presents it on every call as Authorization: Bearer <token>. To rotate, set a new COMMAND_CENTER_SCIM_TOKEN and restart the console, then update the token in your IdP. Treat it like any production secret.

​
2. What it provisions

A newly provisioned user starts at the least-privilege viewer baseline; assign a role by adding the user to the matching group. Removing a user from their role group returns them to viewer. The console can never be left without an administrator: any change that would deactivate or demote the last active admin is refused.

​
3. Set up your identity provider

The three providers below all speak standard SCIM 2.0. In every case you supply the same two values.

​
Okta

  1. In the Okta admin console, open Applications, create or open your app, and go to the Provisioning tab. Choose Configure API Integration and enable it.
  2. Set Base URL to https://your-console-host/scim/v2 and API Token to your SCIM bearer token, then Test API Credentials.
  3. Under Provisioning to App, enable Create Users, Update User Attributes and Deactivate Users. Deactivation calls DELETE/PATCH active=false, which soft-deactivates the account.
  4. Map attributes so Okta userName maps to console userName and email maps to emails.value.
  5. Under Push Groups, push the groups that correspond to the four roles. Name them to match a role (admin, compliance_officer, auditor, viewer) or the role label (for example Administrator); the console accepts a pushed group only when it maps to an existing role.

​
Azure AD (Microsoft Entra ID)

  1. In Enterprise applications, open your app and select Provisioning. Set Provisioning Mode to Automatic.
  2. Set Tenant URL to https://your-console-host/scim/v2 and Secret Token to your SCIM bearer token, then Test Connection.
  3. In Mappings, keep Provision Azure Active Directory Users and Groups enabled. Ensure userPrincipalName maps to userName and mail maps to emails[type eq "work"].value.
  4. Assign users and groups to the app. Azure sends PATCH with active=false on unassignment, which deactivates the account.
  5. Name the assigned groups to match the four roles so membership sets the console role.

​
OneLogin

  1. In OneLogin, open the app’s Configuration and enter the SCIM Base URL https://your-console-host/scim/v2 and the SCIM Bearer Token.
  2. Set the API Connection to Enable and confirm the connection succeeds.
  3. On the Provisioning tab, enable Create user, Delete user and Update user. Delete performs a soft deactivate.
  4. Map SCIM Username to userName and the email attribute to emails.value.
  5. Use Rules or group mappings so that role entitlements map to the four role groups.

​
4. Deprovisioning

When your IdP disables or unassigns a user, it calls the SCIM endpoint to deactivate the account. The effect:
  • the account is marked active=false (a soft deactivate, never a hard delete);
  • the user can no longer sign in through any provider (local, LDAP, AD, OIDC, SAML);
  • the account record and its full audit history are retained as evidence;
  • a scim_user_deactivate entry is written to the signed audit chain.
Existing signed sessions are stateless and expire on their own TTL, so deprovisioning stops new sign-ins immediately and closes out access as sessions lapse.

​
5. Audit evidence

Every SCIM operation is appended to the same Falcon-1024 signed, hash-linked audit chain the rest of the console uses, and re-verifies offline from the Audit page or the validation pack. The actions you will see: Each entry records the target account and is hash-linked to the previous one, so the provisioning history is tamper-evident and exports as part of your compliance evidence.

​
6. Endpoint reference

Base path https://your-console-host/scim/v2. All calls require the bearer token. Pair SCIM with authenticator-app MFA for the full “MFA plus auto-provision” enterprise identity story, all self-hosted and evidenced on the same signed chain.