Skip to main content

Single sign-on (SSO)

SSO lets users sign in with your corporate IdP (SAML 2.0 or OpenID Connect) instead of, or in addition to, a local password. From Identity Management you can add connections, list them, remove them when supported, and rely on email-based routing at the normal sign-in page so the right IdP is offered for each domain.

Callback route (after the IdP redirects back): …/sso/callback (public).

Supported identity providers​

Praxis supports several SSO providers and two standard protocols, so you can match how your organization already manages identities:

  • Vendor presets — First-class setup for Google Workspace, Okta, Microsoft Entra ID (Azure AD), and Auth0. Each preset offers SAML 2.0 and/or OIDC where applicable, with tailored in-product hints and documentation links.
  • Bring your own IdP — SAML IdP for any SAML 2.0–compliant provider, and OIDC IdP for any OpenID Connect provider (discovery URL + client credentials).

You can configure more than one connection per organization—for example different IdPs for different email domains, or separate test and production IdPs. If several connections share a domain, users may see an IdP picker at sign-in.

Where to configure​

LocationScope
Identity Management → SSO (organization)Add connections for the whole organization or for a single tenant. For org-wide connections you can optionally set a default tenant for new SSO users.
Tenant settings → SSOAdd connections for that tenant only. The flow does not offer organization-wide scope, so the IdP cannot be attached to the wrong tenant by mistake.

Configure SSO appears when your user has the same organization-level access used for invitations at the org level (exact permission names depend on your deployment).

Add a connection (wizard)​

  1. Choose your identity provider — You pick a vendor card. Providers that support both protocols show separate SAML and OIDC actions; generic options show Continue for a single protocol.
  2. Connection details — The drawer shows provider-specific inline guidance and an optional Setup guide link when the product ships one.
  3. Register — After you submit, the product shows Configure your IdP with service provider values (ACS URL, audience, redirect URL, and related fields) to paste into the IdP. Keep that panel open until the IdP side is finished, then choose Done.

For supported vendors, the form pre-fills the role-mapping attribute or claim name you will use for groups or roles. You can change it before saving.

Scope (organization flow only)​

When you add a connection from Identity Management → SSO and your organization has tenants, you choose:

OptionMeaning
Organization-wide (all tenants inherit)The connection applies across the org. You can optionally set Default tenant on SSO login: new SSO users are automatically joined to that tenant. Leave the default blank if they should choose or land without an automatic tenant assignment.
Specific tenant onlyThe connection applies only to the tenant you select in the list.

Tenant-scoped flows opened from Tenant settings → SSO skip this section; the tenant is fixed.

Provider presets (reference)​

The Choose your identity provider step lists the same options as in the table below (order may match your product version).

Vendor presets​

PresetProtocolsNotes
Google WorkspaceSAML and OIDCGroup membership is not sent by default. In Google Admin, map a custom attribute (often named groups) into the SAML assertion or OIDC token.
OktaSAML and OIDCUse Group Attribute Statements (or the OIDC equivalent) so a groups (or similar) claim reaches the product.
Microsoft Entra IDSAML and OIDCEntra often sends group object IDs (UUIDs), not display names. Use each object ID as the IdP value in role-mapping rows. Users in more than roughly 200 groups may hit Entra’s overage claim behavior, which can break group-based mapping—in those cases use app roles or a filtered group set in Entra.
Auth0SAML and OIDCGroups and roles are not included by default. Add an Action (or legacy Rule) that copies the user’s groups or roles into the token or assertion.

Generic (any other IdP)​

PresetProtocolsNotes
SAML IdPSAML onlyAny SAML 2.0 IdP: you supply metadata (URL or pasted XML) and name the assertion attribute that carries groups or roles (for example groups, memberOf).
OIDC IdPOIDC onlyAny OpenID Connect IdP: discovery URL plus client credentials; you name the claim used for groups or roles (for example groups, roles).

SAML (typical fields)​

  • Use metadata URL or Paste XML — Fetch IdP metadata from a URL, or paste the XML directly.
  • Display name — Shown when users need to recognize this connection (for example in a multi-IdP picker).
  • Email domains — One or more domains, comma- or space-separated (for example acme.com, acme.org). Sign-in uses the email address domain to pick a connection.
  • Enforce SSO — Label in the UI: Enforce SSO — block password login for users in this org. When enabled, matching users should use IdP sign-in instead of a local password, subject to your deployment’s behavior.
  • Role mapping (optional) — See Role mapping below.

After a successful registration, copy the service provider values from Configure your IdP into your IdP application registration.

OIDC (typical fields)​

  • Discovery URL — The IdP’s .well-known/openid-configuration (or equivalent) document.
  • Client ID and Client Secret — From the IdP app registration.
  • Display name, email domains, Enforce SSO, and role mapping — Same ideas as SAML.

Role mapping​

You can map IdP group or role values to product roles Owner, Admin, Member, and Viewer:

  • IdP attribute name — SAML attribute or OIDC claim that lists the user’s groups or roles (for example groups).
  • Mappings — Each row is an IdP value (exact string from the IdP) mapped to an internal role.
  • Default role (on no match) — Used when the attribute is missing or no row matches.

If you add mapping rows, you must set the IdP attribute name; otherwise the product cannot evaluate mappings.

If you leave role mapping empty, provisioning uses the deployment’s default behavior (often everyone receives a single default role such as Member—confirm with your administrator guide if needed).

SSO connections list​

The SSO admin table typically includes type (SAML or OIDC), name, email domains, whether SSO is enforced, status, and actions such as remove when your version supports it. Opening an existing connection may show read-only IdP configuration, including how role mapping is stored for that connection.

Sign-in behavior​

  • Email first — On the standard sign-in screen, the user enters an email address. The product checks whether SSO is configured for that email domain.
  • Redirect or picker — If exactly one connection matches, the browser is usually sent to the IdP. If several connections match the same domain, the user picks which IdP to use.
  • Continue with SSO — If the user chose SSO from the method selector, the same domain check runs; if no SSO is available, they see an error instead of falling back to password.
  • Password path — If no SSO applies, the flow continues to password (unless Enforce SSO requires IdP sign-in for that domain—in that case the user should not rely on a shared local password).
  • Callback — After successful authentication, the IdP sends the user to /sso/callback, the session is established, and they continue in the product.

IdP and operations​

  • SAML certificates and metadata can expire or rotate. Plan updates in both the IdP and Identity Management when metadata or signing certificates change.
  • SSO is a shared responsibility: your network and identity teams own DNS and IdP app registration; org administrators own email domains and role mapping in the product.
  • Deletion and editing of connections depend on your product version; use the actions available on each row in the SSO list.

See also​