1. Help
  2. Security & Compliance
  3. Identity & Access
  4. Single Sign-On
  1. Help
  2. Security & Compliance
  3. Identity & Access
  4. Single Sign-On
purple icon for coordination.
We’ve moved!
Our Help Center has a new home and our URLs have changed. Please update your bookmark to this page before April 30, 2026

Single Sign-On

Configuring SAML and OIDC single sign-on, including identifier matching, JIT provisioning, and assertion binding requirements.

Overview

Xurrent supports single sign-on through SAML and OIDC connectors. Each connector determines how users are identified, how new users are provisioned on first sign-in, and how assertions from the identity provider are validated.

Identifier matching

The SSO identifier determines which value is used to match an incoming sign-in to an existing person record.

Primary email

When the identifier is set to Primary email, users are matched on their primary email address. Any claim or attribute configuration is automatically cleared to prevent misconfiguration.

Authentication ID

When the identifier is set to Authentication ID, the value used for matching is configurable:

  • OIDC connectors accept a configurable claim name, defaulting to sub.
  • SAML connectors accept an optional attribute name override, so a stable SAML attribute can be used instead of NameID.

This matters for identity providers that do not guarantee stable email addresses or NameIDs, which is common in education federations and national academic identity systems. An unstable identifier otherwise produces duplicate user accounts or identity mismatches.

SAML just-in-time provisioning

When a user is provisioned through SAML JIT provisioning and the SAML organization attribute is empty, the user is assigned to the account's default organization. This matches how Xurrent assigns organizations elsewhere in the platform.

SAML assertion binding checks

Sign-in enforces the SAML specification's Destination, Recipient, and Audience binding checks, confirming that each assertion was issued for this service provider and this ACS endpoint.

No action is needed for accounts whose identity provider sends standard SAML values, which is the default for Okta, Microsoft Entra ID, Google Workspace, OneLogin, ADFS, and other major identity providers configured against the service provider metadata. Existing cross-account setups, including directory accounts with multiple support domains and accounts grouped by certificate fingerprint, continue to work without changes.

Accounts running a custom identity provider configuration should confirm that:

  • The identity provider's Destination and Recipient values match the ACS URL in the Xurrent SSO settings.
  • The Audience matches the service provider entity ID.

Mismatches appear as sign-in failures in the SSO audit log.

Related

For automated user and group provisioning outside of sign-in, see SCIM User and SCIM Group.