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 (formerly Azure Active Directory), Ping Identity, Google Workspace, and any standards-compliant SAML/OIDC IdP are supported. New federated sign-ins fail closed when the IdP cannot assert an identity. Established sessions retain their existing deadlines, and the enumerated recovery administrators retain their separate MFA-protected local access.

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 at Settings / Admin / Identity / SSO in the admin console, and from then on your IdP is the source of truth for membership.

Enterprise sign-in follows your verified federation

An invitation-bound bootstrap administrator can use local password or passkey authentication before federation cutover. After SAML/OIDC verification, enterprise tenants default to SSO-only for every non-exempt user. Social sign-in is disabled by default; a tenant administrator may enable it for invited users in an eligible non-enterprise deployment. It never bypasses the enterprise SSO policy.

What you configure

All six steps use Settings / Admin / Identity / SSO.

Step Action
Choose a protocol SAML 2.0 or OIDC against your IdP
Exchange metadata Upload IdP metadata / certificate, or paste the OIDC issuer + client credentials; Venturi returns its SP metadata, ACS URL, and entity ID
Claim your domains Verify ownership of one or more email domains so Venturi knows those users belong to your tenant
Map groups to roles Bind each IdP group to a Venturi role and scope
Test the connection Run a live test assertion before the connection goes live
Verify enterprise SSO-only Confirm server-enforced SSO after federation, including enumerated recovery administrators

Set up SAML or OIDC

  1. In Settings / Admin / Identity / 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 Default SAML name
    Email (NameID format) urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    Display name http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
    Group membership groups (multi-valued)

    These are the attribute names Venturi reads by default. If your IdP emits a different name, enter that name in the attribute mapping instead. For example, once you add a group claim, Microsoft Entra ID sends group object IDs in http://schemas.microsoft.com/ws/2008/06/identity/claims/groups, so you map that attribute and bind the object IDs to roles.

    When you add that group claim in Microsoft Entra ID, emit only Groups assigned to the application (or apply a group filter). Entra ID puts at most 150 groups in a SAML assertion. Above that limit it omits the groups claim entirely, and that user receives no group-based grant.

    Entra ID also fills the display-name claim above with the user principal name by default. To show a different value, sign in to the Microsoft Entra admin center and browse to Entra ID > Enterprise apps > All applications. Select the application, select Single sign-on, then select Edit in Attributes & Claims and change that claim’s source attribute.

  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 / Admin / Identity / 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. Venturi requests the openid, profile, and email scopes, plus groups where your IdP defines that scope, and reads group membership from a groups claim in the ID token. Configure your IdP to emit that claim. For Okta, set a groups claim filter on the app’s OpenID Connect ID token. Microsoft Entra ID has no groups scope, so add a groups claim in the app registration’s token configuration and emit only Groups assigned to the application. Entra ID includes at most 200 groups in a JWT and omits the groups claim for a user above that limit.
  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 and stores the client secret encrypted under your tenant’s KMS key; you rotate it at Settings / Admin / Credentials.
  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.example) 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 or a well-known HTTPS file; until the proof is detected, the domain stays pending and cannot be used for federation or JIT. 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 a Venturi role and scope:

Text Only
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 once your IdP sends the change; remove them and the access is revoked within the sync SLA.

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 cohort-only boundary, its legal gate, or the k=5 minimum cohort size. A mapping that would confer Admin, as venturi-admins does above, is held until an existing Admin confirms the grant in the console with a fresh step-up assertion. An IdP group claim alone never makes anyone an Admin. See Roles & access control.

Enforce SSO-only

After your SAML/OIDC connection passes verification, enterprise tenants default to server-enforced SSO-only access:

  • Non-exempt users receive SSO_REQUIRED for password, passkey-only, or social sign-in, including a direct API attempt.
  • Existing non-exempt, non-SSO sessions are revoked at their next validation.
  • Explicitly enumerated local break-glass administrators retain recovery access protected by MFA, step-up, independent audit, and periodic recovery testing. Ordinary SCIM deprovisioning does not remove those recovery accounts.
  • Venturi API keys and the SCIM bearer token are unaffected; manage them at Settings / Admin / Credentials.

If the IdP is unreachable, new federated sign-ins fail closed. Established sessions continue only until their existing deadlines; only the enumerated recovery administrators can use local authentication.

Federation cutover and identity-policy changes write append-only audit entries. Eligible non-enterprise tenants can restrict available authentication methods or opt into SSO-only access through the same identity surface.

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 at Settings / Admin / Identity. Independently, a defined set of sensitive operations requires a fresh step-up assertion, presented within the last 5 minutes by default, even inside a live session. The set covers enabling Active (Gate) for a workload, changing residency lane, creating or rotating API keys, and changing a role binding. It also covers configuring the IdP or SCIM, creating an export, changing the plan or billing settings, placing or releasing a legal hold, and approving support break-glass. See Step-up and 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 append-only audit log.

Next steps

Give feedback on this page

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

Copy page details 
Docs feedback: Single sign-on (SAML / OIDC)
Page: https://docs.venturi.systems/administration/sso/