Skip to content

Single sign-on (SAML / OIDC)

Venturi federates authentication to your own identity provider over SAML 2.0 or OpenID Connect (OIDC), so your team signs in to app.venturi.systems with the same identity, policies, and MFA they use everywhere else. Okta, Microsoft Entra ID (Azure AD), Ping, Google Workspace, and any standards-compliant SAML/OIDC IdP are supported. SSO is a fail-closed authentication path: if the IdP cannot assert an identity, no one gets in.

SSO answers two questions for your security team at once — who is allowed in (authentication) and, when combined with group mapping and SCIM provisioning, what they can do once they are in (authorization). You configure it once from the admin console, and from then on your IdP is the source of truth for membership.

SSO is one of several auth methods

A new tenant can sign in immediately with email/password, passkey (WebAuthn/FIDO2), or Google / GitHub / Microsoft OAuth. Enterprise SSO layers federated identity on top, and — once verified — you can enforce SSO-only to disable every other method tenant-wide.

Target-state — IdP-federated SSO enforcement

The SAML/OIDC federation flow, verification gates, and fail-closed contract described on this page are the committed design. Live enforcement of IdP-federated SSO 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 you configure

Step What it does Surface
Choose a protocol SAML 2.0 or OIDC against your IdP Settings → SSO
Exchange metadata Upload IdP metadata / certificate, or paste the OIDC issuer + client credentials; Venturi returns its SP metadata, ACS URL, and entity ID Settings → SSO
Claim your domains Verify ownership of one or more email domains so Venturi knows those users belong to your tenant Settings → SSO
Map groups to roles Bind each IdP group to an Venturi role and scope Settings → SSO
Test the connection Run a live test assertion before the connection goes live Settings → SSO
Enforce SSO-only (optional) Disable password and OAuth methods tenant-wide Settings → SSO

Set up SAML or OIDC

  1. In Settings → SSO, choose SAML 2.0. Venturi shows your tenant's Assertion Consumer Service (ACS) URL, SP entity ID, and metadata URL.

  2. In your IdP, create a SAML application using those values. Map the following attributes into the assertion:

    Venturi attribute SAML claim
    Email (NameID) urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    Display name http://schemas.xmlsoap.org/.../name
    Group membership groups (multi-valued)

  3. Upload your IdP's metadata XML (or its signing certificate and SSO URL) back into Venturi.

  4. Run the test assertion. The connection stays disabled — and is never shown as green — until a test assertion succeeds.
  1. In Settings → SSO, choose OIDC. Venturi shows your tenant's redirect URI (callback URL).
  2. In your IdP, register a confidential web application with that redirect URI and request the openid profile email groups scopes.
  3. Paste the issuer URL, client ID, and client secret into Venturi. Venturi discovers the IdP's endpoints from the issuer's .well-known/openid-configuration.
  4. Run the test login. The connection activates only after a successful round-trip.

Verification gates activation

The SSO setup step is validation-first: it blocks on domain verification plus a successful test assertion, and renders an explicit, recoverable error if either fails. Venturi never marks an unverified IdP as live.

Claim your email domains

Claiming a domain (for example, acme.com) does two things: it asserts that users on that domain belong to your tenant, and it enables optional just-in-time provisioning. You verify a domain with a DNS TXT record. A domain can belong to exactly one tenant, which is part of how tenant isolation is preserved at the identity layer.

Map IdP groups to roles

Group mapping is where federated identity becomes federated authorization. Each IdP group is bound to an Venturi role and scope:

IdP group                       →  Venturi grant
─────────────────────────────────────────────────────────────
venturi-admins                   →  Admin    @ Tenant
finops-leads                    →  FinOps   @ Tenant
platform-eng                    →  Engineer @ Workspace: Platform
payments-team                   →  Engineer @ Team: Payments
ai-program-exec                 →  Workforce-Data @ Tenant

When a user authenticates, their group claims resolve to the configured grants. Combined with SCIM, group changes in your IdP propagate to Venturi automatically — add someone to finops-leads in your IdP and they have FinOps access at next sync; remove them and the access is revoked.

Group mapping never escalates past your plan or past Admin

A mapping can only resolve to grants your plan includes, and can never resolve to more than Admin. It also cannot weaken the Workforce-Data legal gate or the k=5 cohort-suppression rule. See Roles & RBAC.

Enforce SSO-only

Once your SSO connection is verified and group mappings are in place, you can require SSO for the whole tenant. When you enable SSO-only:

  • Password and OAuth sign-in methods are disabled tenant-wide.
  • Existing non-SSO sessions are revoked at their next validation.
  • All future authentication flows exclusively through your IdP.

This is a fail-closed authentication change — it tightens access, takes effect immediately, and writes an immutable audit entry. You can restrict available methods per deployment at any granularity short of full SSO-only as well.

MFA and step-up

MFA is enforced by your IdP for the SSO flow, and Venturi can additionally require MFA tenant-wide or per role. Independently, a defined set of sensitive operations — changing role bindings, configuring the IdP or SCIM, creating an export, rotating credentials, placing a legal hold, or approving support break-glass — requires a fresh step-up assertion within a short freshness window, even inside a live session. See Roles & RBAC → Step-up & separation of duties.

What SSO does not change

  • Tenant isolation still comes first. A federated identity is still bound to exactly one tenant; nothing in an assertion can cross the tenant boundary.
  • No self-registration. Even with a claimed domain and JIT off, accounts are invitation- or IdP-driven; users cannot self-provision into your tenant.
  • The audit trail is yours. Every SSO configuration change, every sign-in, and every SSO-only enforcement event is recorded to your immutable audit log.

Next steps