What Is SAML?
SAML (Security Assertion Markup Language) is an XML-based authentication protocol that has been the standard for enterprise single sign-on for over two decades. Many enterprise applications — especially older ones built before OIDC existed — only support SAML for federated authentication. SAML works by exchanging signed XML documents (called assertions) between an identity provider (IdP) and a service provider (SP) to prove a user’s identity. The Maverics Orchestrator can act as a SAML Provider, receiving assertions from your identity provider and translating them into authenticated sessions for your applications. This means your applications do not need to implement SAML directly — the Orchestrator handles the protocol complexity for them.Prerequisites
- A running Maverics Orchestrator — If you have not installed the Orchestrator yet, follow the Quick Start guide or see the installation reference.
- An identity provider account — While this guide demonstrates a SAML connector, the Orchestrator can connect to your IdP over OIDC, SAML, or LDAP. Your IdP does not need to support SAML specifically. Common IdPs include Microsoft Entra ID, Okta, and PingFederate.
- A target SAML application — An enterprise application that authenticates users via SAML assertions. Common examples include legacy portals, HR systems, and internal tools that were built for SAML-based SSO.
Configure SAML Federation
1
Create an Orchestrator Deployment
In the Maverics Console, all configuration lives within a Deployment — a managed Orchestrator instance with its own configuration, storage provider, and signing keys. Before you can create identity connectors and applications, you need a Deployment to hold them.
- Console UI
- Configuration
- Log in to the Maverics Console.
- Navigate to Deployments in the sidebar and click Create.
-
Enter a name for your deployment (e.g.,
SAML Federation). -
Select a deployment provider. The Console supports several options:
- AWS S3, Azure Blob Storage, or Google Cloud Storage — customer-managed cloud storage for production.
- GitHub or GitLab — deploy bundles to a Git repository.
- Download Only — manual bundle download for air-gapped environments.
- Click Create.
2
Configure the SAML Provider
The SAML Provider must be enabled and configured at the deployment level before creating connectors or applications. This configures the Orchestrator to act as a SAML identity provider to your downstream applications — issuing signed SAML assertions after authenticating users through your upstream IdP connector.The SAML Provider requires signing credentials (a certificate and private key) that the Orchestrator uses to sign assertions. Your downstream applications validate these signatures to ensure assertions came from a trusted source.
- Console UI
- Configuration
In the Maverics Console, SAML Provider settings are configured through the Deployment Settings dialog.
- Click the gear icon in the sidebar to open Deployment Settings.
- Find the SAML Provider section and configure the provider-level settings.
3
Connect your identity provider
Next, connect the Orchestrator to your identity provider as a SAML identity source. This tells the Orchestrator where to send users for authentication and how to validate the signed assertions it receives back.SAML supports two authentication flows, and it helps to understand the difference:
- SP-initiated — The user visits your application first. The Orchestrator (acting as the Service Provider) redirects the user to the identity provider for authentication, and the IdP sends the user back with a SAML assertion. This is the most common flow.
- IdP-initiated — The user logs into the identity provider first (through a portal or dashboard) and then navigates to the application. The IdP sends a SAML assertion directly to the Orchestrator without a prior authentication request.
- Console UI
- Configuration
- Navigate to Identity Fabric in the sidebar and click Create.
- Select your identity provider from the list. Choose a provider-specific SAML option (such as Okta (SAML) or Microsoft Entra ID (SAML)) or select Generic SAML for any SAML-compliant provider. OIDC and LDAP connector options are also available — this guide demonstrates the SAML connector path, but any connector type is valid here.
- Fill in the connector form:
The Enable IdP Initiated Login toggle allows authentication flows started by the identity provider. Enable this if your users will access the application from an IdP portal.
- Click Save.
Protocol translation: This guide shows a SAML connector, but the Orchestrator can connect to your IdP using any supported protocol — OIDC, SAML, or LDAP. The Orchestrator’s mode (SAML Provider) determines what protocol your application speaks. The connector determines what protocol your IdP speaks. These are independent — you can connect an OIDC-only IdP and the Orchestrator will translate to SAML for your application. See the Identity Fabric overview for all connector types.
4
Register your SAML application
Register your application as a SAML relying party (service provider) in the
apps section. This tells the Orchestrator which application to issue SAML assertions for, where to send the assertions, and which identity connector to use for authentication.- Console UI
- Configuration
In the Console, you create the SAML application and connect it to your identity provider in a single flow. The connector you select becomes the application’s authentication source.
- Navigate to Applications in the sidebar and click Create.
- Select SAML-based.
- Fill in the application form:
- Click Save.
- On the application settings page, find the Resources card and click Edit. Click Add Resource, select the SAML connector you created earlier, and click Save. A connector must be added as a resource before it can be selected as an authentication source.
- Find the Access Control card and click Edit.
- From the Select an authentication source dropdown, select your identity provider. To add more than one source, click Add identity provider.
- Click Save.
5
Configure assertion attributes
Configure the
nameID and claimsMapping to control which identity attributes appear in the SAML assertions your application receives. The nameID is the primary user identifier in the assertion, and claimsMapping adds additional attributes.- Console UI
- Configuration
- Open the application you created in the previous step.
- Find the Attribute Mappings card and click Edit.
- Add a claim mapping for each attribute your application needs:
- Click the Claim button to add additional rows for each claim you need to map.
emailfrom your IdP’semailfirstNamefrom your IdP’sgiven_namelastNamefrom your IdP’sfamily_name
- Click Save.
- Find the Protocol & Assertion Settings card and click Edit.
- Under NameID, set the Dynamic NameID Source to the identity provider connector that provides the NameID value, and set the Dynamic NameID Attribute to the attribute to use as the primary subject identifier (e.g.,
email). - Click Save.
6
Publish your configuration
After configuring your deployment, identity connector, application, and assertion attributes in the Console, you need to publish the configuration so the Orchestrator receives it and applies your changes.
- Console UI
- Configuration
- At the bottom of the deployment Settings page, click Publish Preview in the sticky footer bar.
- In the Deployment Manager dialog, review the configuration diff to verify your changes.
- Optionally add a revision note describing what changed (e.g., “Initial SAML federation setup”).
- Click Publish to deploy the configuration bundle to your storage provider.
- The Orchestrator detects the new bundle on its next poll cycle and applies the configuration automatically.
7
Verify federation
With your SAML identity source configured, your application registered as a relying party, and attribute mapping in place, you are ready to test the federated authentication flow.Start (or restart) the Orchestrator and verify it is healthy:Now test the SAML flow by visiting your application’s URL:
- Visit the application URL — The Orchestrator redirects you to your identity provider’s login page (SP-initiated flow)
- Authenticate — Log in with valid credentials at your IdP
- Verify redirect — After authentication, you should land on your application with a valid session
- Check attributes — If your application has a profile or debug page, verify that the SAML attributes match your mapping configuration
Success! Your Maverics Orchestrator is federating SAML authentication
between your identity provider and your enterprise application. Users
authenticate through your IdP, the Orchestrator translates the SAML
assertion, and your application receives the attributes it expects —
all without modifying the application.
Troubleshooting
Certificate mismatch or signature validation error
Certificate mismatch or signature validation error
SAML assertions are cryptographically signed, and the Orchestrator validates
these signatures using the certificate from your IdP’s metadata. If the
certificate has been rotated (updated) on the IdP side but the Orchestrator
still has the old certificate, validation fails. Re-fetch the IdP’s metadata
or manually update the signing certificate in your Orchestrator configuration.
If you are using a metadata URL, the Orchestrator can pick up certificate
changes automatically on the next metadata refresh.
Assertion Consumer Service URL mismatch
Assertion Consumer Service URL mismatch
Your identity provider rejects the SAML request because the ACS URL
(Assertion Consumer Service URL) does not match what is registered. This is
the URL where the IdP sends the SAML response after authentication. Verify
that the ACS URL configured in the Orchestrator exactly matches the one
registered in your IdP — including protocol, domain, port, and path. This
is similar to the redirect URI mismatch issue in OIDC.
Clock skew causes assertion rejection
Clock skew causes assertion rejection
SAML assertions include timestamps that the Orchestrator validates to prevent
replay attacks. If the clocks on your IdP server and the Orchestrator’s host
are not synchronized, the Orchestrator may reject valid assertions because
they appear to be from the future or already expired. Ensure both systems use
NTP (Network Time Protocol) to keep their clocks synchronized. Most SAML
implementations allow a small clock skew tolerance (typically 1-2 minutes) —
check your Orchestrator configuration for a skew tolerance setting.
What’s Next
Migrate Between Identity Providers
Move users from one identity provider to another with zero downtime and no application changes
SAML Provider Reference
Explore the complete SAML Provider configuration — assertions, attributes, signing, and advanced settings