Single Sign-On (SSO)

UDMG supports Single Sign-On (SSO) for User authentication, enabling centralized identity management, strengthening security, and providing a seamless login experience for administrators. By allowing Users to authenticate through an external Identity Provider (IdP), UDMG integrates easily into your organization's existing identity infrastructure.

Each UDMG Domain supports a single SSO provider. Upon SSO login, UDMG validates the IdP assertion/token, verifies authorization, issues its own session tokens, and Just-in-Time (JIT) provisions the User if needed.

info

SSO authentication is currently supported only for Users; it cannot be used to authenticate Accounts.

Before You Begin

Supported Protocols and IdPs

UDMG supports two widely adopted authentication protocols for SSO. These are open standards for exchanging authentication and authorization data between an IdP and Service Providers (SPs) like UDMG:

• SAML (Security Assertion Markup Language) 2.0
• OIDC (OpenID Connect)/OAuth 2.0

UDMG supports any IdP that conforms to the SAML or OIDC/OAuth 2.0 specifications. The table below lists a selection of commonly used IdPs that have been tested and formally validated. If your IdP is not included, it is still likely to work with UDMG, as unlisted providers may simply not have undergone our complete validation process.

Identity Provider	SAML 2.0	OIDC / OAuth 2.0
Okta
Microsoft Entra ID (Azure AD)
Google Workspace
PingFederate
Auth0

Before configuring SSO in UDMG (the Service Provider), ensure your IdP is fully configured and operational. Download your IdP metadata file or directly obtain the necessary configuration details from your issuer. See required Field Descriptions

Provisioning and Identity Management

UDMG supports automated Just-in-Time (JIT) provisioning for users authenticated via SSO. When a user successfully signs in to the UDMG Admin UI through a configured SSO provider for the very first time, their account is automatically created within UDMG—no manual setup is required.

On First Login

When a User first signs in with SSO, UDMG processes the identity assertion or token returned by the IdP:

• If the Username Attribute Name is present and resolves to a unique username, UDMG creates a new User and populates the mapped attributes (e.g., name, email, role).
• If the Username Attribute Name is missing, or if a User with the same username exists but has a different Login Method (e.g., Standard or LDAP), the login is denied.

On Subsequent Logins

When an SSO-provisioned User logs in again, UDMG re-evaluates authorization and:

• Updates mapped attributes (e.g., name, email, role) if they differ from the IdP response.
• Refreshes the Updated timestamp and Version number whenever any User data is modified.

info

The User's Username is immutable to preserve identity consistency. The Login Method (equal to SAML or OIDC) and the association with the originating SSO Provider are also not changeable.

On User or SSO Removal/Change

If a User is removed from the IdP:

• The User remains visible in the Users list but will no longer be able to log in.
• If the User authenticates again after an SSO provider has been replaced, they may be re-provisioned as a new User depending on whether the new IdP emits a different value for the configured Username Attribute Name.

Group Attribute, Roles, and Authorization

After a User is authenticated through SSO, UDMG 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 configuration.

For each UDMG role, you can configure the exact IdP value (group or claim) that grants that role. Leaving a role mapping blank disables assignment for that role. If all role mappings are blank, UDMG applies the Missing or Unrecognized Role Policy instead:

• 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).

If a User's IdP attributes contain multiple matching values, UDMG assigns the most privileged role from the following list (in descending order of privilege):

• Domain Administrator
• Pipeline Management
• Operator
• Read-only

If no values match, or if the Group Attribute Name is missing entirely, UDMG applies the configured Missing or Unrecognized Role Policy.

For SAML configurations, when group attributes are returned as a single string, values are split using the configured Group Delimiter.

Role assignments are re-evaluated on every login. If a User's group membership or mapped role changes in the IdP, UDMG updates the User's role accordingly.

Login Experience

Once an SSO provider has been configured for a Domain, a button for that provider appears on the Domain's login page beneath the standard Username and Password fields.

When a User clicks the SSO button, UDMG redirects them to the configured IdP to authenticate. After the IdP completes authentication, it returns the User to UDMG, redirecting the User to their requested page or the default landing page.

Also, Users can automatically log into the UDMG Admin UI by navigating to a direct SSO URL. Simply append /auth/{domainId}/sso to your UDMG Base URL (hostname). This will redirect users to their IdP login screen, and upon successful authentication, they'll be automatically directed to the UDMG Admin UI landing page.

info

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 Full Redirect URI for OIDC.

Session Behavior

After a successful SSO login, UDMG establishes and manages its own application session; it does not reuse IdP tokens. When a User signs out, only the the UDMG session ends. Single Logout (SLO) across the IdP or other applications is not supported.

If an SSO provider is 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 prompts for login.

Configuring an SSO Provider

SSO is configured at the Domain level, meaning it can only be used to authenticate Users within that specific Domain. If you want to use the same SSO provider across multiple Domains, it must be configured separately in each Domain.

To configure an SSO provider for Users, follow these steps:

1. From the Sidebar, click General > Domain.
2. Click Single Sign-On (SSO).
3. Fill out the fields for the new SSO settings using the Field Descriptions table, which includes separate tabs for OIDC / OAuth 2.0 and SAML.
4. Click Save.

Field Descriptions

SAML

Name	Description	Specifications	Required
Name	The name of the SSO configuration.	Must be unique. Must follow the Standard Naming Pattern.	Yes
Description	The description of the SSO configuration.		No
Protocol	Select SAML.	Cannot be modified after creation. If a different protocol is needed, the current SSO provider must be deleted and a new one added.	Yes
Identity Provider (IdP)	The selected IdP's name and icon are displayed on the login page under the single sign-on section. If your IdP is not listed below, then it is displayed as 'Other.' Options: Microsoft Entra ID (Azure AD) Okta Google Workspace Ping Identity Other		Yes
Identity Provider (IdP) SSO URL	The IdP's SSO endpoint URL that Users are redirected to for login.	Must be a valid HTTPS URL.	Yes
Service Provider (SP) Entity ID (Issuer)	A unique identifier for your Service Provider (entity issuer) that the IdP recognizes.	Must be a valid HTTPS URL.	Yes
Audience URI (Expected Audience)	The URI that specifies which Service Provider the SAML assertion is intended for. Only change the field if your IdP sends a different audience value than your Security Provider Entity ID.	Must be a valid HTTPS URL.	Yes
UDMG Base URL	The base URL of your UDMG instance, prefixed by HTTPS. This should be the hostname where your UDMG application is accessible.	Must be a valid HTTPS URL.	Yes
Full Redirect URI	The complete redirect URI that is automatically generated and should be configured in your IdP as the callback URL for SAML authentication.	Must be a valid HTTPS URL.	Yes
Credential Containing Client ID & Secret	The Credential that references the CA Certificate that is used to verify the signature on the SAML response from the IdP.	Must reference an already created X509 Certificate.	Yes
Username Attribute Name	The name of the attribute to use as the unique user identifier. If not specified, the default NameID element will be used. This value should be globally unique and not change over time (e.g., email, uid, userPrincipalName).		Yes
Email Attribute Name	The name of the attribute that contains the User's email address.		Yes
Name Attribute Name	The name of the attribute that contains the User's name.		Yes
Last Name Attribute Name	The name of the attribute that contains the User's last name		Yes
Group Attribute Name	The name of the attribute from which the role will be derived. This could be an existing attribute or a custom one, such as mftRole.		Yes
Delimiter (for Single String Attributes)	If the Group Attribute Name is returned as a single string, specify the delimiter (e.g., ; or ,).		Yes
Group Attribute to Role Mapping	Map IdP group/role values to UDMG roles. For each UDMG role, enter the exact value from your IdP that should grant that role.	info For more information on this field configuration, refer to Group Attribute, Roles, and Authorization.	No
Missing or Unrecognized Role Policy	Specifies whether to deny or downgrade the role if the group attribute was not found or the role could not be identified or mapped. Options: Deny login Assign to default role		Yes
Default Role	Specifies the default role to assign if the role attribute is missing or does not contain a recognized role. Options: Read-only Domain Administrator Operator Pipeline Management	Default value: Read-only.	Yes

OIDC / OAuth 2.0

Name	Description	Specifications	Required
Name	The name of the SSO configuration.	Must be unique. Must follow the Standard Naming Pattern.	Yes
Description	The description of the SSO configuration.		No
Protocol	Select OIDC / OAuth 2.0.	Cannot be modified after creation. If a different protocol is needed, the current SSO provider must be deleted and a new one added.	Yes
Identity Provider (IdP)	The selected IdP's name and icon are displayed on the login page under the single sign-on section. If your IdP is not listed below, then it is displayed as 'Other.' Options: Microsoft Entra ID (Azure AD) Okta Google Workspace Auth0 Ping Identity Other		Yes
UDMG Base URL	The base URL of your UDMG instance, prefixed by HTTPS. This should be the hostname where your UDMG application is accessible.	Must be a valid HTTPS URL.	Yes
Full Redirect URI	The complete redirect URI that is automatically generated and should be configured in your IdP as the callback URL for OIDC authentication.	Must be a valid HTTPS URL.	Yes
Issuer URL	The base URL of the OpenID Provider that is used to discover other OIDC endpoints.	Must be a valid HTTPS URL.	Yes
Credential Containing Client ID & Secret	The Credential that contains the Client ID (unique identifier assigned to your application Service Provider by the IdP) and authentication password for OIDC/OAuth 2.0.	Must reference an already created Key Pair.	Yes
Authorization Endpoint	The endpoint for initiating the authentication flow.	Must be a valid HTTPS URL.	Yes
User Info Endpoint URL	The URL of the OIDC endpoint used to retrieve additional user profile information.		Yes
Token Endpoint	The endpoint for exchanging the authorization code for tokens.	Must be a valid HTTPS URL.	Yes
Scopes	The permissions or identity data the Service Provider Client is requesting, such as "openid email profile" or 'openid'.	Must be a valid, space-separated string.	Yes
Username Attribute Name	The name of the attribute to use as the unique user identifier. If not specified, the default NameID element will be used. This value should be globally unique and not change over time (e.g., email, uid, userPrincipalName).		Yes
Email Attribute Name	The name of the attribute that contains the User's email address.		Yes
Name Attribute Name	The name of the attribute that contains the User's name.		Yes
Last Name Attribute Name	The name of the attribute that contains the User's last name		Yes
Group Attribute Name	The name of the attribute from which the role will be derived. This could be an existing attribute or a custom one, such as mftRole.		Yes
Group Attribute to Role Mapping	Map IdP group/role values to UDMG roles. For each UDMG role, enter the exact value from your IdP that should grant that role.	info For more information on this field configuration, refer to Group Attribute, Roles, and Authorization.	No
Missing or Unrecognized Role Policy	Specifies whether to deny or downgrade the role if the group attribute was not found or the role could not be identified or mapped. Options: Deny login Assign to default role		Yes
Default Role	Specifies the default role to assign if the role attribute is missing or does not contain a recognized role. Options: Read-only Domain Administrator Operator Pipeline Management	Default value: Read-only.	Yes

Managing an SSO Provider

Viewing SSO Provider Details

To view the details of an SSO provider, follow these steps:

1. From the Sidebar, click General > Domain.
2. Click Single Sign-On (SSO) card you want to view.

SSO provider details include all parameters given in the Field Descriptions table above, plus the following read-only metadata:

SSO Provider Metadata

Name	Description
UUID	Universally Unique Identifier of this SSO provider.
Version	Version number of the latest configuration of the SSO provider.
Created	Date and time this SSO provider was created.
Updated	Date and time this SSO provider was last updated.

Editing SSO Provider Details

To edit the details of an SSO provider, follow these steps:

1. From the Sidebar, click General > Domain.
2. Click the Single Sign-On card you want to view.
3. Click the Edit button above the SSO provider details.

info

SSO-provisioned Users cannot be edited at all.

Deleting SSO-Provisioned Users

To delete an SSO-provisioned User, follow these steps:

1. From the Sidebar, click General > Users.
2. Click the Username of the User you want to delete.
3. Click the Delete button above the User details.
4. You will be asked to confirm the deletion. Click Delete.

info

Deleting an SSO-provisioned User removes them from the Users list, but they will reappear if they authenticate again. To permanently prevent access, first remove the User from your IdP, and optionally delete them from the Users list.

Deleting an SSO Provider

danger

Before deleting an SSO provider, ensure that at least one Admin User with Standard authentication remains available. Otherwise, you may lose administrative access to UDMG.

Deleting an SSO provider configuration is straightforward; however, you must plan what to do with any orphaned Users that have already been provisioned via the provider. Those options include:

Option	When to Choose	Result
Delete the Users	No plans to migrate to a new provider, or don't want to preserve User records.	Users are removed from UDMG; if they authenticate later via an active SSO provider, they will be re-provisioned.
Retain as orphaned	You need the records for auditing but do not want Users to log in.	Users remain visible but cannot authenticate; even with a new provider configured, their usernames remain tied to the deprecated provider.

To delete an SSO provider, follow these steps:

1. From the Sidebar, click General > Domain.
2. Click Single Sign-On (SSO).
3. Click the Delete button above the SSO provider details.
4. You will be asked to confirm the deletion. Click Delete.

info

Deleting an SSO provider blocks new login attempts for associated Users. Existing sessions remain active until they expire or the User logs out.