Configure organization SSO

DVARA Cloud is the hosted AI governance platform. Organization SSO lets you govern who can enter one workspace without asking a platform operator to reconfigure the whole service. You validate a revision first, then activate it only after DVARA can trust the identity provider and your email domain.

DVARA Cloud only

This self-service workflow is available in DVARA Cloud. It is separate from deployment-wide identity-provider configuration for a self-managed Enterprise installation.

A workspace admin can manage SSO for that workspace. A platform owner can manage it after selecting the workspace. The developer and viewer roles cannot create, validate, or activate a connection.

Choose organization or deployment-wide SSO

If you operate	Use	Scope
DVARA Cloud	Settings → Organization SSO, at /settings/sso	One organization's workspace and verified email domains.
A self-managed Enterprise installation	The deployment's OIDC or SAML settings	The entire installation.

The Keycloak, Okta, Microsoft Entra ID, Auth0, and SAML setup guides describe the second case. Do not copy those deployment settings into the organization form.

Create a draft revision

Open Settings → Organization SSO and choose OIDC or SAML. Each save creates a new draft revision that cannot be edited after it is saved. A draft never changes the live sign-in route, so you can prepare a replacement while the current revision remains active.

For OIDC, enter the issuer, client ID, client secret, and the claim names DVARA should use for email, name, groups, roles, and, when required, the workspace. For SAML, enter the identity provider's metadata URL. Add the signing certificate and PKCS#8 private key together when the provider requires signed authentication requests.

Choose how new users enter the workspace:

Policy	Behavior
Invite only	The default. The person must already have an invitation before SSO completes.
Just in time	DVARA creates the workspace user after a valid first sign-in.

Set default roles for people whose identity claims do not map to a DVARA role. Organization SSO can grant the workspace roles admin, developer, and viewer; it does not grant a platform role.

Validate before activation

Choose Validate while the revision is still a draft. DVARA fetches the real provider metadata rather than accepting the form on syntax alone.

For OIDC, the discovered issuer must exactly match the configured issuer, and the authorization, token, key-set, and optional user-info endpoints must use public HTTPS addresses. For SAML, the metadata must contain a valid identity provider descriptor. If the provider requires signed requests, the revision must contain both signing values.

DVARA refuses localhost, .local, private, reserved, credential-bearing, or fragmented provider addresses. It also rechecks the resolved address when it connects, so a public hostname that later resolves to an internal address is not accepted. Provider metadata is limited to 1 MiB and must answer within the connection time limits.

Your DVARA Cloud sign-in address and the identity provider must both be externally reachable over HTTPS. This lets the browser complete the redirect and prevents server-side metadata discovery from reaching private services.

Prove control of your email domain

Add an email domain to the validated connection. DVARA shows its verification value once. Publish it as a DNS TXT record:

Name:  _dvara-sso
Value: dvara-verification=<verification-token>

Choose Check DNS after the record is visible publicly. DNS publication can take time; a pending result changes nothing and is safe to retry. A domain can belong to only one organization SSO connection, and at least one domain must be verified before activation.

At sign-in, DVARA uses the person's email domain to find the active connection. If the domain is unverified, unmapped, or has no active connection, DVARA does not redirect the browser to an identity provider.

Preview claim mapping

Before activation, select the revision and paste a sanitized identity-claim sample into Claim mapping preview. The preview accepts JSON up to 32 KiB and does not save the sample.

{
  "email": "maya.chen@claims.example.com",
  "email_verified": true,
  "name": "Maya Chen",
  "groups": ["claims-reviewers"],
  "roles": ["viewer"],
  "workspace": "claims-production"
}

Check that the preview finds the expected email, resolves at least one allowed workspace role, and, when you configured a workspace claim, reports a match. OIDC sign-in also requires email_verified: true. If no role or group maps, DVARA uses the revision's default roles.

Activate the connection

Activate only a revision that has passed validation and has a verified domain. Activation makes that revision live and retires the previous active revision in one change. People can then enter their email on the sign-in page; DVARA uses the verified domain to send them to the correct organization provider.

Keep a built-in platform owner account available as a recovery path. Test an invited non-owner account in a separate browser session before treating the rollout as complete.

Roll back or recover sign-in

To roll back, select a previously validated or retired revision and activate it. DVARA retires the current revision and restores the selected configuration; you do not edit an active revision in place.

DVARA rechecks provider metadata during sign-in. If the provider becomes unsafe or unavailable, it refuses the connection, returns the person to the sign-in page with an organization-SSO-unavailable message, and records a TENANT_SSO_CONNECTION_REFUSED audit event with the connection, protocol, and reason. It does not include the provider response body in that evidence.

Use the built-in owner account to recover access. You can restore a known-good retired revision or create a new draft, validate it, verify its domain, and activate it. This revision workflow keeps a failed repair from replacing the last working connection.

For role boundaries beyond SSO administration, see Check role access.