Single Sign On

Explanation (Core Concepts)

What is Single Sign-On?

Single Sign-On (SSO) lets your users authenticate to xDP with the credentials they already use for your organization's identity provider (IdP) — instead of a separate xDP password. As a Governance & Security Administrator, you configure SSO to enforce your organization's existing login policies (password rules, session timeouts, conditional access) on xDP access, and to remove a second password that's a common phishing and credential-reuse target.

xDP's identity backend is Admin Central — the same tenant-aware identity service that backs user, group, and role management across the platform. SSO configuration lives in Admin Central rather than in xDP's own settings pages, because federation, credential validation, and provisioning are identity-layer concerns shared by every xDP capability, not a per-feature setting.

Key Concepts

• Identity provider (IdP) — Your organization's existing authentication system (for example, an enterprise directory service). The IdP is the source of truth for who your users are.

• SAML — A federation standard where the IdP asserts a user's identity to xDP via a signed XML assertion after the user authenticates with the IdP directly.

• OpenID Connect (OIDC) — A federation standard built on OAuth 2.0 that authenticates users via signed identity tokens; a common alternative to SAML for IdPs that support it.

• LDAP — A directory-based option for centralized authentication against an on-premises directory, listed alongside SAML and OIDC as a third federation method.

• SCIM provisioning — A standard (System for Cross-domain Identity Management) that lets your IdP automatically create, update, and disable xDP user accounts as people join, change roles, or leave — instead of an administrator managing accounts by hand.

• Auth URL / Redirect URI — The single endpoint xDP generates for your tenant (one for SAML, one for OIDC). You register this value on your IdP so it knows where to send users back after they authenticate.

• Claim / attribute mapping — The correspondence between the fields your IdP sends (name, email) and the fields xDP expects. A mismatch here is the most common cause of blank names or duplicate accounts after SSO login.

Capabilities

SSO in xDP is organized into two independent concerns you configure in Admin Central:

• Authentication (SAML, OIDC, or LDAP) (configuration) — Federates sign-in so users authenticate against your IdP and land in xDP already signed in. Each method shows its configuration Status (for example, Not Configured) on the SSO-authentication list.

• Provisioning (SCIM) (provisioning) — Automatically syncs user and group lifecycle events from your IdP into xDP, so access is revoked the moment someone is disabled upstream. Provisioning works alongside either SAML or OIDC.

Note: Authentication and provisioning are independent — you can federate sign-in without enabling SCIM, and vice versa. Most organizations enable both so that IdP-side offboarding immediately disables xDP access.

Warning: The email address your IdP asserts, the SAML NameID, and the SCIM userName must all resolve to the same address for a given person. If they diverge — commonly after an email change in the IdP — xDP can create a duplicate account instead of updating the existing one.

Tutorial (Getting Started)

Prerequisites

• You hold an administrator role in both xDP and your organization's identity provider.

• Your IdP supports SAML 2.0 or OIDC, and — if you plan to automate provisioning — SCIM 2.0.

Note: SSO and SCIM are configured in the Admin Central portal, not in xDP's own Settings pages — xDP only launches you into it.

Your First Workflow

This walkthrough federates sign-in for your tenant using SAML.

1. In xDP, click the Settings icon, then open Admin Central, and click Go to Admin Central (you may be asked to sign in again).

2. Go to Management → SSO-authentication. Click the kebab menu (⋮) next to SAML to open its configuration.

   
   

3. Copy the Auth URL shown — you'll register this same value as both the Entity ID and the Reply/ACS URL when you create the SAML application on your IdP.

   
   

4. On your IdP, create a new SAML application using the Auth URL from the previous step, and configure it to send firstName, lastName, and email as attributes on the assertion.

5. Your IdP gives you back a Single Sign On URL (its login endpoint) — paste that into xDP's Single Sign On URL field.

6. Optionally upload your IdP's federation metadata or signing certificate via Browse XML.

7. Click UPDATE to save.

8. Sign out of xDP. The sign-in screen now shows a Sign in with saml button — click it and confirm you're redirected to your IdP and back into xDP already authenticated.

   
   

Example: A platform team federates sign-in so employees use their existing corporate directory credentials for xDP, removing a standalone xDP password from their password manager entirely.

Tip: If you use Microsoft Entra ID (Azure AD) as your identity provider, follow Microsoft's guide to enable SAML single sign-on for an enterprise application for the IdP-side steps — the xDP-side steps above (Auth URL, attribute mapping) stay the same regardless of which IdP you use.

How-to Guides

Federate sign-in with OpenID Connect (OIDC) instead of SAML

You already have Admin Central access and want to federate sign-in using an OIDC-based IdP.

1. Go to Management → SSO-authentication, and open OpenID Connect from the kebab menu.

2. Note the Sign In & Out Redirect URL shown at the top — register this as the redirect URI when you create the OIDC application on your IdP.

3. Under OIDC Credentials (step 1 of the wizard), enter the Client ID and Client Secret your IdP issued for that application, then click Next.

   
   

4. Complete OIDC Provider Metadata (optional) and Endpoints & Claims: supply your IdP's Authorization, Token, Logout, and User Info endpoints, and confirm the Token Claims mapping — which xDP user attribute (Email, First Name, Last Name) maps to which claim name in your IdP's token. The defaults (email, firstName, lastName) match most IdPs; change them only if your IdP issues differently named claims.

5. Fill in Additional Information (optional), then review everything on Review Configuration before saving — including the claims mapping table.

   
   

6. Click Save. Sign out of xDP — the sign-in screen now shows a Sign in with oidc button.

   
   

Tip: If you use Microsoft Entra ID (Azure AD), see Microsoft's guide to enable SAML single sign-on for an enterprise application — the same Entra application supports OIDC; use its client credentials and endpoints in the wizard above.

Enable automated user provisioning with SCIM

You already have SAML or OIDC sign-in working and want new users provisioned automatically instead of created manually.

1. Go to Management → Provisioning and turn on Enable SCIM.

2. Copy the SCIM Base URL and Token shown.

   
   

3. On your IdP, open the same application's provisioning settings, switch provisioning mode to automatic, and enter the SCIM Base URL as the tenant URL and the Token as the secret. Test the connection.

4. Assign the users or groups on your IdP that should sync to xDP.

5. Confirm the synced groups appear in the Group Name / Roles / Mapped Domains Count table on the Provisioning page — it shows Group data not available until the first sync completes.

Tip: If you use Microsoft Entra ID, Microsoft's guide to manage automatic user provisioning for enterprise apps walks through the IdP-side provisioning setup.

Warning: Groups managed by SCIM can't have their role assignments edited directly in xDP — role changes for SCIM-managed groups must be made on the IdP side or in the SCIM mapping, or they'll be overwritten on the next sync. Treat the Token as a credential: copy it directly into your IdP, never into tickets or shared documents, and regenerate it if it's ever exposed.

Troubleshoot blank names or duplicate accounts after SSO login

You already have SSO enabled and are seeing malformed profile data.

1. If first name or last name is blank after login, confirm your IdP is sending attribute or claim names exactly as xDP expects — for SAML: firstName, lastName, email; for OIDC: whatever names are set in the Token Claims mapping. A mismatched name is the most common cause.

2. If a person has two xDP accounts, compare the email claim/attribute, the SAML NameID (if applicable), and the SCIM userName for that person — they must match exactly.

3. Re-test sign-in after correcting the mapping and confirm the profile fields populate correctly.

Note: Profile fields sourced from your IdP (name, email) are re-applied on every login — this is expected. Edit them on the IdP side, not in xDP directly.

Reference

Claim and attribute mapping

SSO field reference

Post-setup validation checklist

Best Practices

Tip: Enable both SAML/OIDC sign-in and SCIM provisioning together — sign-in federation alone doesn't revoke access when someone is offboarded upstream.

• Match identifiers exactly across SAML/OIDC and SCIM. The email claim, SAML NameID, and SCIM userName must resolve to the same address, or you'll get duplicate accounts.

• Test with identity-provider-initiated login, not just service-provider-initiated. Some misconfigurations only surface when the login starts from your IdP's app launcher.

• Treat IdP-side profile fields as the source of truth. Don't edit name or email inside xDP for SSO-federated users — your changes will be overwritten on the next login.

• Scope SCIM sync to the groups that need xDP access. Syncing your entire directory creates accounts for people who will never use the platform.

• Treat the SCIM Token and OIDC Client Secret like passwords. Copy them directly into your IdP's configuration, never into tickets, chat, or shared documents.