XTD Platform provides support for single sign-on (SSO) through a customer-provided SAML 2.0-compatible external Identity Provider (IdP) such as Microsoft SSO or Okta.

The external IdP authenticates the customer user before allowing access to Platform services.

To integrate XTD Platform with your IdP, Customer Single Sign On using SAML requires an initial exchange of configuration values between your organization (the Identity Provider or IdP), and XTD Platform (Service Provider or SP).

In this article:

• Overview
• Customer Provided Information
  • SAML 2.0 Metadata URL
  • SAML Attribute Mapping
  • Customer Email Domain
• XTD Platform Provided Information
  • Single sign-on URL
  • User pool ID for Audience URI (SP Entity ID)
• User Permissions and Roles
• Limitations

Overview

Customer Single-Sign On using SAML requires an initial exchange of configuration values to and from the Customer (Identity Provider) and XTD Platform (Service Provider).

This article outlines the values that are exchanged between parties.

What you need to provide

• SAML 2.0 Metadata URL
• SAML Attribute Mapping
• Customer Email Domain

SAML 2.0 Metadata URL

Obtain the Metadata URL from your IdP. The Metadata URL helps configure the SAML service provider (XTD Platform).

Examples of Metadata URLs:

Microsoft

https://login.microsoftonline.com/dcb260f9-022d-4495-8602-eae51035a000/federationmetadata/2007-06/federationmetadata.xml?appid=9999059b-8a15-498b-b473-b0f8578a1000

Okta

https://integrator-79950000.okta.com/app/exkuva5uejH6BuefS000/sso/saml/metadata

IdP Metadata Security Considerations

Your IdP should, at a minimum, follow these security guidelines for metadata:

IdP Certificate and Signing algorithms:

• For encryption and signing, prioritize modern algorithms over legacy algorithms.
• RSA 2048+ or Elliptic Curve (P-256, P-384).
• SHA-256 or stronger for signatures.

Metadata Related:

• Include the IdP Organization and Contact Person information in the metadata (ideally, a group email address).
• Publish metadata over HTTPS with valid certificates.
• Optionally sign the metadata XML with a trusted signing certificate.
• Make metadata available via a well-known URL (e.g., https://idp.example.com/metadata).
• If distributing manually, ensure integrity (e.g., signed file or checksum).
• Don’t embed expired certificates; remove old ones.
• Keep metadata minimal – include only what is necessary for relying parties.
• Use separate test and production metadata to avoid confusion.
• Notify SPs (XTD) well in advance of changes (such as certificate rotation).

SAML Attribute Mapping

Provide the SAML attributes used by your IdP that will map to the equivalent attributes used by XTD Platform Service Provider.

The attributes to map are:

• email (email address)
• given_name (first name)
• family_name (last name, surname)

Examples of Identity Provider mappings:

Customer Email Domain

Provide the email domain(s) of users who are allowed to log in through SSO.

This can be a list if there are multiple domains. For example, if you use "user1@x.z.com" and "user2@y.z.com" email addresses, you must provide x.z.com and y.z.com, and not just z.com. However, if only users in y.z.com should be allowed to login, then you only need to provide y.z.com.

What XTD Platform provides

Your IdP needs configuration values from XTD Platform for their specific organization. XTD Platform provides:

• Single sign-on URL
• Userpool ID for Audience URI (SP Entity ID)

Add these values to your IdP application’s SAML settings.

Single Sign-on URL

This is the URL that your IdP will send successful SAML responses to.

Example:

https://c04667050101447f88dbds000.auth.us-east-1.amazoncognito.com/saml2/idpresponse

User Pool ID for Audience URI (Service Provider Entity ID)

A user pool contains the registered users for an organization.

This value is the user pool ID of your organization’s user pool. The user pool ID is used to construct the Audience URI (SP Entity ID).

User pool ID Example:

us-east-1_OxJo2sTkj

SP Entity ID Example:

urn:amazon:cognito:sp

User Permissions and Roles

XTD Platform does not currently support roles, groups, or permissions provided by the IdP.

After a user has been onboarded successfully, they have a XTD Platform role of "Customer User", with limited permissions. An existing "Customer Admin" user can log in and adjust the user’s role or permissions from XTD Platform.

Limitations

• IdP-initiated logins are not supported.
• Real-time enforcement of the IdP state is not supported. This means that disabling accounts or sessions on the IdP does not result in immediate enforcement on XTD Platform (SP).
• XTD Platform does not invoke the single-logout service specified in IdP metadata when a user logs out of XTD Platform.