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 a user is removed in your IdP, the next SCIM sync deactivates their Venturi account, revokes their active sessions server-side, resolves every grant to deny, and records the event in your audit log. 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. Most enterprises run both: SSO for sign-in, SCIM for lifecycle, and IdP group mapping as the bridge between them.

SCIM activation

SCIM provisioning stays off until create, update, deprovision, and group-to- role validation pass for the tenant. After activation, deprovisioning fails closed and the tenant’s verification record is the availability evidence.

What SCIM manages

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

Venturi implements the standard SCIM 2.0 Users and Groups resource types over the standard /scim/v2 endpoints, so your IdP’s native Venturi integration (Okta, Microsoft Entra ID, and any SCIM 2.0-compliant provider) works without custom glue.

Enable SCIM

1. In Settings / Admin, open Identity and enable SCIM provisioning. Venturi returns your tenant’s SCIM base URL (https://app.venturi.systems/scim/v2 on the SaaS tier; a self-hosted deployment uses its own instance host) and issues a bearer token.
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, under Identity, map each pushed IdP group to a Venturi role and scope.
5. Start provisioning. New accounts and group changes take effect within the sync SLA: accepted changes target completion within 60 seconds, with a hard maximum of 300 seconds for session revocation. A breach forces short-TTL revalidation so stale access fails closed.

Rotate the SCIM token like any other credential

The SCIM bearer token is managed in the credential rotation panel of the admin console. Rotate it on your normal schedule or immediately if it is ever exposed; rotation is a step-up-protected, audited action and does not interrupt already-provisioned users.

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
        │
        ▼  (next SCIM sync, 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 immutable 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 (a ≤30-day crypto-shred), 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, useful for broad, low-privilege rollouts. It is off by default and is deliberately conservative:

• It activates only for a claimed, verified email domain.
• A JIT-created account receives the lowest role (Viewer-equivalent). Anything beyond that requires an admin to elevate it explicitly.
• The creation is recorded in the audit log like any other.

Use JIT when you want every employee on a claimed domain to be able to read their own team’s views with zero admin toil; use SCIM group push when you want roles to be driven by IdP group membership.

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 by choosing an auth method. 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

• Decide the role each IdP group maps to in Roles & RBAC.
• Configure sign-in and SSO-only enforcement in SSO.
• Watch provisioning events land in the audit log.