title: Identity Providers & SSO category: Security tags: sso, saml, oidc, identity-provider, azure-ad, okta priority: Normal
Identity Providers & SSO
IdentityCenter supports federated authentication through external identity providers, allowing your users to sign in with their existing corporate credentials via Single Sign-On (SSO). The Identity Providers page at Administration > Identity Providers (/admin/identity-providers) is where you configure and manage these integrations.
What Are Identity Providers?
An identity provider (IdP) is an external authentication system that vouches for a user's identity. Instead of maintaining a separate username and password in IdentityCenter, users authenticate against their existing IdP and are granted access automatically.
Benefits of SSO integration:
- Reduced password fatigue — Users sign in once and access IdentityCenter seamlessly
- Centralized authentication — Enforce your organization's password policies and MFA at the IdP level
- Faster onboarding — New users can access IdentityCenter immediately through JIT provisioning
- Improved security — Fewer credentials to manage means fewer attack surfaces
Supported Protocols
IdentityCenter supports two industry-standard protocols:
| Protocol | Standard | Best For |
|---|---|---|
| SAML 2.0 | XML-based assertion exchange | Enterprise IdPs (ADFS, PingFederate, Okta) |
| OpenID Connect (OIDC) | OAuth 2.0 extension with JWT tokens | Cloud-native IdPs (Azure AD/Entra ID, Google Workspace) |
Supported Identity Providers
The following providers have been tested and are fully supported:
| Provider | Protocol | Notes |
|---|---|---|
| Azure AD / Entra ID | OIDC (recommended), SAML | Most common enterprise choice |
| Okta | SAML, OIDC | Supports both protocols equally well |
| Google Workspace | OIDC | Use Google's OAuth 2.0 endpoints |
| PingFederate | SAML | Widely used in large enterprises |
| ADFS | SAML, OIDC (limited) | On-premises Active Directory Federation Services |
| OneLogin | SAML, OIDC | Cloud-based identity management |
Tip: Any provider that implements standard SAML 2.0 or OIDC should work with IdentityCenter, even if not listed above.
Setting Up a SAML 2.0 Provider
Step 1: Create a New Provider in IdentityCenter
- Navigate to Administration > Identity Providers
- Click Add Identity Provider
- Select SAML 2.0 as the protocol type
- Enter a Name for the provider (e.g., "Corporate ADFS" or "Okta Production")
Step 2: Configure SAML Settings
Provide the following settings from your IdP:
| Setting | Description | Example |
|---|---|---|
| Metadata URL | The IdP's federation metadata endpoint | https://idp.example.com/FederationMetadata/2007-06/FederationMetadata.xml |
| Entity ID | The IdP's unique identifier | https://sts.example.com/adfs/services/trust |
| SSO Service URL | The IdP's sign-on endpoint | https://idp.example.com/adfs/ls/ |
| Certificate | The IdP's X.509 signing certificate | Upload the .cer file from your IdP |
Step 3: Configure Your IdP
In your identity provider, register IdentityCenter as a relying party:
- Assertion Consumer Service (ACS) URL:
https://your-identitycenter.example.com/saml/acs - Entity ID / Audience:
https://your-identitycenter.example.com - Name ID Format:
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Step 4: Configure Certificate Settings
- Upload or paste the IdP's public signing certificate
- IdentityCenter validates SAML assertion signatures against this certificate
- Set a reminder to rotate the certificate before it expires
Important: Certificate expiration is the most common cause of SSO outages. Monitor expiration dates and plan rotation at least 30 days in advance.
Setting Up an OIDC Provider
Step 1: Register IdentityCenter in Your IdP
In your identity provider (e.g., Azure AD app registration), create a new application:
- Set the Redirect URI to
https://your-identitycenter.example.com/signin-oidc - Note the Client ID and generate a Client Secret
- Copy the Authority URL (the issuer endpoint)
Step 2: Configure OIDC in IdentityCenter
- Navigate to Administration > Identity Providers
- Click Add Identity Provider
- Select OpenID Connect as the protocol type
- Fill in the connection details:
| Setting | Description | Example |
|---|---|---|
| Client ID | The application/client ID from your IdP | a1b2c3d4-e5f6-7890-abcd-ef1234567890 |
| Client Secret | The secret generated in your IdP | Store securely; shown only once in most IdPs |
| Authority URL | The OIDC issuer/discovery endpoint | https://login.microsoftonline.com/{tenant-id}/v2.0 |
| Redirect URI | Where the IdP sends users after authentication | https://your-identitycenter.example.com/signin-oidc |
| Scopes | Requested permission scopes | openid profile email |
Step 3: Verify Discovery
IdentityCenter uses the OIDC discovery document (.well-known/openid-configuration) to automatically configure signing keys, token endpoints, and supported claims. Verify that the Authority URL resolves to a valid discovery document.
User Attribute Mapping
After authentication, the IdP sends claims (attributes) about the user. IdentityCenter maps these claims to internal user fields:
| IdP Claim | IdentityCenter Field | Notes |
|---|---|---|
email / http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress |
Primary user identifier | |
name / http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name |
Display Name | Full name of the user |
given_name |
First Name | Used for personalization |
family_name |
Last Name | Used for personalization |
preferred_username |
Username | Login identifier |
groups |
Roles | Map IdP group memberships to IdentityCenter roles |
Configure claim mappings in the Attribute Mapping section of each identity provider configuration. Custom claim mappings can be added for organization-specific attributes.
Just-In-Time (JIT) Provisioning
JIT provisioning automatically creates an IdentityCenter user account the first time someone authenticates through an external IdP:
- Enable JIT Provisioning in the identity provider configuration
- Set a Default Role for newly provisioned users (e.g., "Viewer" or "Analyst")
- Configure which claims populate the new user's profile
When a user authenticates for the first time:
- IdentityCenter checks if a matching account exists (by email)
- If no match is found and JIT is enabled, a new account is created automatically
- The user's profile is populated from the IdP's claims
- The configured default role is assigned
Tip: Combine JIT provisioning with role mapping to automatically assign roles based on IdP group memberships. For example, map the "IT-Admins" IdP group to the "Administrator" role in IdentityCenter.
Testing SSO Connections
After configuring a provider, always test the connection before enabling it for all users:
- Click Test Connection on the identity provider configuration page
- You will be redirected to the IdP's login page
- Authenticate with valid credentials
- IdentityCenter displays the claims received and the mapped user attributes
- Verify that the expected claims are present and correctly mapped
If the test fails, check the error message and refer to the Troubleshooting section below.
How DynamicAuthenticationService Works
IdentityCenter uses a DynamicAuthenticationService to load identity provider configurations at runtime. This means you can add, modify, or remove providers without restarting the application. When a provider is saved:
- The configuration is stored in the
IdentityProviderstable (columns:Name,Type,Configuration,Metadata) DynamicAuthenticationServicepicks up the change and registers or updates the authentication handler- The new provider appears on the login page immediately
Troubleshooting
Common SAML Errors
| Error | Cause | Fix |
|---|---|---|
| Invalid signature | Certificate mismatch between IdP and IdentityCenter | Re-upload the IdP's current signing certificate |
| Audience mismatch | Entity ID in IdentityCenter does not match the IdP's relying party config | Ensure the Entity ID is identical on both sides |
| Assertion expired | Clock skew between servers | Sync server clocks using NTP; increase the allowed time skew tolerance |
| Name ID not found | IdP is not sending the expected Name ID claim | Configure the IdP to send email as the Name ID |
Common OIDC Errors
| Error | Cause | Fix |
|---|---|---|
| Invalid client | Client ID or Secret is incorrect | Verify the Client ID and regenerate the secret if needed |
| Redirect URI mismatch | The redirect URI in IdentityCenter does not match the IdP's registered URI | Ensure the URIs match exactly, including trailing slashes |
| Token validation failed | Authority URL is incorrect or unreachable | Verify the Authority URL and check network connectivity |
| Insufficient scopes | Required claims are not being returned | Add profile and email to the requested scopes |
Certificate Expiration
SAML signing certificates typically expire every 1-3 years. To handle rotation:
- Obtain the new certificate from your IdP administrator
- Upload the new certificate to the identity provider configuration in IdentityCenter
- Test the connection with the new certificate
- Remove the old certificate after confirming the new one works
Best Practices
- Use OIDC when possible — It is simpler to configure and uses modern JWT tokens
- Always test in a staging environment first before rolling out SSO to production users
- Monitor certificate expiration dates and set calendar reminders for rotation
- Enable JIT provisioning to eliminate manual user creation
- Map IdP groups to IdentityCenter roles for automatic role assignment
- Keep a local admin account as a fallback in case SSO is misconfigured or the IdP is unavailable
Next Steps
- Multi-Factor Authentication — Add a second layer of security
- API Key Management — Configure programmatic access
- Security Hardening Guide — Comprehensive security best practices
- Quick Config Wizard — Initial setup including authentication