External Identity Provider Support Matrix by Build

Crosswork Assurance external identity provider (IdP) support follows aod-deployer/manifest.yml and deployer configuration. The 25.07 release branch supports SAML 2.0; build 26.10.2 also supports OpenID Connect (OIDC) and Lightweight Directory Access Protocol (LDAP).

Match your installed build and tenant configuration before configuring single sign-on (SSO).

Authentication and Authorization Map

Identity and access management (IAM) connects your tenant to an external IdP. The external IdP authenticates the user; Crosswork Assurance assigns roles, user groups, and permissions.

Create Crosswork Assurance users with roles and optional user groups before sign-in. An IdP account alone does not grant Crosswork Assurance access. Crosswork Assurance does not delegate authorization or import IdP groups as permissions. See Delegated Authentication.

Build Baselines

This matrix covers the modern AAA IAM system using /api/v3/idps: Kubernetes deployments managed by Replicated and Docker Swarm deployments migrated from legacy AAA systems.

Use the authentication, authorization, and accounting (AAA) version pinned at components_version.uniform.skylightaaa in your build's manifest.yml.

The release/25.7.250 branch pins AAA 1.144.11, matching 25.7.250-177.

This reference covers deployer builds through 26.10.2.

Protocol Support Matrix

Legend: Supported means available for an IAM tenant, subject to the requirements below. Not supported means unavailable through the listed build's IAM IdP integration.

Updating within the 25.7.250 maintenance line does not add OIDC or LDAP.

SAML boundary: 25.7.214 is the last build without IAM SAML 2.0 support; support starts in build 25.7.215. Both pin AAA 1.129.0; 25.7.215 adds IdP API routing and browser redirect changes. OIDC and LDAP start in 25.7.481 (AAA 1.180.0). See Configure an External Identity Provider.

Configuration Requirements and Limits

Configure external providers through Crosswork Assurance APIs using tenant-admin or skylight-admin in the correct tenant context. Provider configuration is unavailable in the Crosswork Assurance user interface.

Use your installed build's schema, the IAM API Reference, and IdP Setup Guide for configuration guidance.

Shared Sign-In Requirements

• Crosswork Assurance-initiated sign-in: Start SSO from the Crosswork Assurance login page. SAML supports service provider initiated (SP-initiated) SSO; IdP-initiated sign-in is not supported.
• User association: A Crosswork Assurance user can have one external IdP association. Updating the association replaces the previous selection. An empty association list removes the selection.
• User identity: The external identity must match the email address of the provisioned Crosswork Assurance user. User creation, roles, and group membership remain Crosswork Assurance administrative tasks.
• Tenant default: Where supported, a tenant can have one default IdP. A default selection does not grant roles or permissions.
• Connectivity: The browser must reach Crosswork Assurance and the external sign-in service. IAM must reach the applicable metadata, discovery, token, user information, or LDAP endpoints.

An air-gap installation does not remove these connectivity requirements. Use an IdP reachable within your permitted network; a SAML metadata file avoids fetching metadata from an external URL.

SAML Requirements

SAML configuration accepts an IdP metadata XML file or a metadata URL. Use one metadata source per request. Build 26.10.2 requires an HTTPS metadata URL or well-formed XML that declares the email address NameID format.

The IdP must return the user's email address as the SAML NameID. The required format is:

urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Crosswork Assurance signs SAML authentication requests. Configure the IdP with your deployment's service provider entity ID and Assertion Consumer Service (ACS) URL. Use generated IAM details for your deployment.

25.07 update limits: AAA 1.144.7 updates only the default IdP flag. AAA 1.144.9 and later maintenance versions, including 1.144.11, add name and metadata updates. SAML PATCH requests use multipart/form-data.

Provider removal: The 25.7.250 builds disable providers; 26.10.2 deletes them. Both interrupt sign-in for associated users. Arrange replacement associations or local password onboarding before removal; the 25.7.250 APIs have no reactivation operation.

OIDC Requirements

In build 26.10.2 (AAA 1.272.0), OIDC has these requirements:

• An HTTPS issuer URL that supports OIDC discovery. The issuer must match exactly, including case and a trailing slash when present.
• A client ID and the callback URL generated for your deployment, registered with the external IdP.
• Scopes that include email; the API accepts openid, profile, and email.
• An email claim that matches the provisioned Crosswork Assurance user. Attribute mapping can use the ID token or the user information endpoint.

Callback URL restrictions: Some OIDC providers, including Google, reject redirect URIs with non-loopback IP addresses. The integration is unsupported for a deployment whose generated IP-based callback URL the provider rejects. Configure Crosswork Assurance with a DNS hostname that satisfies the provider's rules, and register the generated HTTPS callback URL.

Client secret limit in build 26.10.2: Creating an IdP requires a nonempty clientSecret, even with Proof Key for Code Exchange (PKCE). Secret-free public client creation is unavailable through this API.

LDAP Requirements

In build 26.10.2 (AAA 1.272.0), LDAP requires Transport Layer Security (TLS):

• LDAP over TLS (LDAPS): Use an ldaps:// server URI.
• StartTLS: Use an ldap:// server URI with StartTLS enabled. Plaintext LDAP binds are not supported.
• Certificate trust: Provide the root certificate authority (CA) certificate for either TLS method. IAM must trust the LDAP server certificate.
• Directory search: Provide the server list, base distinguished name (DN), bind DN, bind password, and user search base.
• Email lookup: The userFilters list must contain exactly mail. When you supply attribute mappings, both the user ID and email attributes must map to mail.

The directory's mail value must match the Crosswork Assurance user's email address. Arbitrary username filters and directory group to Crosswork Assurance role mapping are not supported by this integration.

Common SSO Failure Patterns

Response text and status depend on the installed build. Use these patterns to narrow the cause, then follow the linked guidance.

Related References

• Configure an External Identity Provider
• Delegated Authentication
• Crosswork Assurance API documentation