Single Sign-On (SSO)
USP supports Single Sign-On (SSO) to authenticate and authorize Users. One or more SSO providers (OIDC or SAML) can be configured so that Users authenticate via your enterprise Identity Provider (IdP). Just-in-Time (JIT) provisioning automatically creates User records on first successful login.
Multiple SSO Providers can be configured simultaneously. Each active mapping appears as a separate SSO option on the login page.
Before You Begin
Supported Protocols and IdPs
USP supports two widely adopted authentication protocols for SSO:
- SAML (Security Assertion Markup Language)
- OIDC (OpenID Connect)
While USP is designed to support any IdP that conforms to the SAML 2.0 or OIDC 1.0 specifications, the table below highlights a subset of popular providers that have been explicitly tested by our team:
| Identity Provider | SAML | OIDC / OAuth 2.0 |
|---|---|---|
| Okta | ||
| Microsoft Entra ID (Azure AD) | ||
| Google Workspace | ||
| Auth0 |
Provisioning and Identity Management
USP supports Just-in-Time (JIT) provisioning for SSO-authenticated Users: when a User first authenticates via a configured SSO provider, USP creates it internally—no pre-creation required.
For more details, refer to the specific protocol mapping: SAML SSO Mapping or OIDC SSO Mapping.
Roles and Authorization
After a User is authenticated through SSO, USP determines their Role based on the value returned by the IdP. This attribute contains one or more values—such as group names or role identifiers—which are compared against the Group Attribute Name defined in the SSO attribute mapping.
If no match is found or if the Group Attribute Name is missing entirely, USP applies the configured Missing or Unrecognized Role Policy:
- Deny login: The authentication attempt is rejected.
- Assign to default role: The User is allowed to log in with the specified Default Role (typically, Read-only).
Role assignments are re-evaluated on every login. If a User's group membership or mapped role changes in the IdP, USP will update the User's role accordingly.
Login Experience
Once an SSO provider has been configured, a button for that provider appears on the login page alongside the standard Username and Password fields.
When a User clicks the SSO provider button, USP redirects them to the configured IdP to authenticate. After the IdP completes authentication, it returns the User to USP, redirecting the User to their requested page or the default landing page.
Users can also start the SSO login flow directly by visiting /[domain]/sso.
If the IdP is configured for IdP-initiated login, it can send a signed authentication response directly to the Full Redirect URI—the Assertion Consumer Service (ACS) endpoint for SAML, or the redirect URI for OIDC.
Session Behavior
After a successful SSO login, USP establishes and manages its own application session; it does not reuse IdP tokens. Signing out ends the USP session only; Single Logout (SLO) across the IdP or other applications is not supported.
If an SSO provider is disabled or deleted, new logins are blocked but existing sessions remain active until they expire. When a session expires, Users are returned to the login page; if their IdP session is still valid, they may be signed back in without re-entering credentials, otherwise the IdP will prompt for login.
Configuring SSO
To enable an external IdP for User authentication, you must configure two protocol-specific items that work together:
- One SSO configuration: Defines trust and endpoints with your IdP.
- One SSO attribute mapping: References an SSO configuration and specify how IdP attributes map to USP User fields and roles.
An SSO configuration alone does not enable SSO. It must be linked by an SSO attribute mapping to take effect.
Setup steps
- Create an SSO configuration:
- SSO attribute mapping:
- Choose either SAML SSO Mapping or OIDC SSO Mapping, select the SSO configuration created in step 1 as the Identity Provider, and define attribute mapping.