Skip to content

User provisioning with SCIM

SCIM 2.0 makes your identity provider the source of truth for who has a Venturi account and what they can do. Once SCIM is enabled, joiners, movers, and leavers flow from your IdP into Venturi automatically: create a user in your IdP and a Venturi account appears; change their group and their role changes; deprovision them and their access is removed. No manual user administration, and, critically, no orphaned access when someone leaves.

Deprovisioning is fail-closed. When your IdP sends the deprovisioning request, Venturi deactivates the account, revokes its active sessions server-side, resolves every grant to deny, and records the event in your audit log, all within the sync SLA. No degraded or cached access survives.

SCIM complements SSO

SSO governs authentication (proving who someone is at sign-in). SCIM governs the account lifecycle (whether the account exists at all, and what groups/roles it carries) ahead of time. Run both: SSO for sign-in, SCIM for lifecycle, and IdP group mapping as the bridge between them.

What SCIM manages

Effects of changes sent by your identity provider (IdP). Role mappings connect IdP groups to Venturi roles:

Object Change Effect
Users Created Account provisioned, email-bound
Users Updated Profile and status synced
Users Removed Account deactivated (fail-closed)
Groups Created Group recognized
Groups Updated Membership synced
Groups Removed Membership removed → grants recomputed
Role mappings Created Admin-configured in Venturi
Role mappings Updated Re-evaluated each sync
Role mappings Removed N/A

Venturi implements the standard SCIM 2.0 Users and Groups resource types over the standard /scim/v2 endpoints, including ServiceProviderConfig, Schemas, and ResourceTypes discovery, so the SCIM provisioning built into Okta, Microsoft Entra ID, and any other SCIM 2.0 client works without custom code. A DELETE on a user is a soft delete (deactivate and tombstone) that preserves audit history; re-provisioning the same externalId re-links the account rather than creating a duplicate.

By default, SCIM endpoints accept 10 requests per second per bearer token, with bursts of up to 50. A client that exceeds that rate receives 429 Too Many Requests with a Retry-After header.

Enable SCIM

  1. In Settings / Admin / Identity / SCIM, enable SCIM provisioning. Venturi returns your tenant’s SCIM base URL (https://api.venturi.systems/scim/v2 on the SaaS tier; a self-hosted deployment uses its own instance host) and issues a bearer token. The value shown in the console is authoritative.
  2. In your IdP’s provisioning settings, paste the base URL and bearer token.
  3. Configure attribute mappings (email, display name) and group push so your IdP sends group membership to Venturi.
  4. In Settings / Admin / Identity / SSO, map each pushed IdP group to a Venturi role and scope.
  5. Run Test connection in Settings / Admin / Identity / SCIM. The SCIM connection goes live only after the test passes; a failed test leaves the configuration unverified, and it cannot provision.
  6. Start provisioning. New accounts, group changes, and deprovisioning take effect within the sync SLA.

Rotate the SCIM token like any other credential

The SCIM bearer token is a long-lived credential until you rotate it, and it is managed at Settings / Admin / Credentials in the admin console. Rotate it on your normal schedule or immediately if it is ever exposed. Rotation is a step-up-protected, audited action: the old and new tokens both work until the overlap window shown in the panel closes, so provisioning continues while you update your IdP, and already-provisioned users are not interrupted.

Sync SLA

Your IdP decides when it sends a change: some IdPs push changes as they happen, and others send them on a provisioning cycle (Microsoft Entra ID, for example, runs periodic incremental cycles). Venturi’s sync SLA starts when the SCIM request reaches Venturi:

Change your IdP sends Effect in Venturi Commitment
Create a user Account created, email-bound, with no grants beyond its mapped groups When Venturi acknowledges the request
Change group membership Effective roles recomputed from the group-to-role map On the user’s next authorization decision; cached decisions are invalidated by the change
Deactivate or delete a user Account deactivated, active sessions revoked server-side, every grant resolved to deny Sessions revoked within 60 seconds by default, and within 300 seconds at most

If revocation cannot complete within 300 seconds, Venturi forces short-TTL revalidation of every session so stale access fails closed rather than lingering.

The sync SLA covers changes your IdP delivers. A change can also fail to arrive, for example a deactivation lost during an IdP outage. To catch it, Venturi reconciles its accounts against your IdP every 60 minutes by default. Each run flags any account that is active in Venturi but deactivated or absent at the source, and your admins can fix it with a one-click remediation.

An account that three consecutive reconciliations find orphaned (the default threshold) is deactivated automatically, with all of its sessions revoked. A run that cannot get a complete read from your IdP, such as during an IdP outage, still reports drift. It never auto-deactivates an account only because that account was absent from the incomplete read. Reconciliation findings and the orphan threshold are shown and set at Settings / Admin / Identity / SCIM.

The deprovisioning guarantee

Deprovisioning is the control your security team cares about most, so it is the one Venturi makes strongest:

Text Only
User removed/disabled in your IdP
        │
        ▼  (IdP sends the change; Venturi applies it within the sync SLA)
Venturi account → deactivated
        ├─ active sessions revoked server-side
        ├─ every grant resolves to deny
        └─ deprovision recorded in the audit trail
        ▼
No degraded, cached, or residual access survives: fail closed

The account’s audit history is preserved: overrides, reviews, approvals, and policy changes the user made remain in the append-only audit log even though the account can no longer authenticate. If the user is also the subject of a data-erasure request, their personal data is handled under the platform’s retention and erasure path (crypto-shred within 30 days), while the non-personal audit record persists under its own lawful basis.

Just-in-time (JIT) provisioning

JIT provisioning auto-creates an account on a user’s first SSO login, without a prior SCIM push. It is off by default and uses the IdP’s explicit provisioning policy:

  • It activates only for a claimed, verified email domain.
  • A matching IdP group-to-role mapping assigns the configured grants.
  • If no mapping matches, the account has zero grants and cannot be used until an administrator assigns a role. It does not receive Viewer access automatically.
  • The creation is recorded in the audit log like any other.

Use JIT to provision mapped users at their first federated sign-in; use SCIM group push to provision and update membership before they sign in. Both paths respect the configured group-to-role grants, tenant boundaries, and seat limits.

Least privilege is the default at every entry point

Whether an account arrives by invite, by SCIM, or by JIT, it never starts with more than the access it was explicitly granted. Elevation is always an admin action, and always audited.

Manual provisioning still works

SCIM does not remove the manual path. An admin can still invite a user by email from the admin console; the invited user completes registration using an authentication method allowed by the tenant policy. Self-registration is never available: all accounts are invitation- or IdP-gated to preserve tenant isolation. You can run SCIM for your federated population and invite the occasional contractor or auditor by hand, in the same tenant.

Next steps

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details 
Docs feedback: User provisioning with SCIM
Page: https://docs.venturi.systems/administration/scim/