User provisioning with SCIM

SCIM 2.0 makes your identity provider the source of truth for who has an 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 an 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.

Target-state — SCIM provisioning enforcement

The SCIM 2.0 lifecycle, fail-closed deprovisioning, and group-to-role mapping described on this page are the committed design. Live IdP-driven provisioning wired against the canonical identity model is a Target-state control, not yet general. The binding label and gate are in Docs authority & product state.

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	—

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 → SSO/SCIM, enable SCIM provisioning. Venturi returns your tenant's SCIM base URL (https://app.venturi.systems/scim/v2) 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 → SSO, map each pushed IdP group to an Venturi role and scope.
5. Start provisioning. New accounts and group changes take effect within the sync SLA.

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:

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.