SAML is still one of the main standards for enterprise identity — and is easy to implement badly
Even as modern applications adopt OIDC more and more, SAML 2.0 remains a critical standard in enterprise and public-sector identity integration. Many organisations run AD FS, Entra ID, Okta, Ping, Auth0, or existing directories behind a federation gateway over SAML. On the public-sector side, national identity federations and the SaaS services that integrate with them are most often built on SAML 2.0.
For a new or modernising application, the right approach is therefore not to create a separate user database. The application should connect to the identity provider the organisation already trusts. That requires the access layer to behave as a SAML 2.0 service provider: redirect the user to the right IdP, validate the incoming SAML response, extract the identity safely, and translate it into a session the application can use.
But a SAML integration is not just "take the XML, read the user, sign them in." Implemented incorrectly, it produces real security holes. The signature on the SAML response has to be validated correctly; which element is actually signed has to be checked; signature stripping and forged-assertion injection attacks have to be defeated. Validity windows, audience restrictions, issuer information, NameID format, and attribute mappings cannot just be read — they have to be enforced.
The operational side matters just as much. Refreshing IdP metadata, rotating certificates and signing keys, routing per-tenant to different IdPs, applying different mapping rules for different applications, and running Single Logout cleanly are not small details to add later. They are the parts that determine whether a SAML federation runs safely and sustainably.
One of the most common mistakes is embedding a SAML library separately into every application. This scatters identity responsibility across each backend. A single IdP change becomes a coordinated update across many applications. MFA, conditional access, device trust, logout behaviour, and audit logging end up re-solved per application. The result is not centralised identity but a distributed identity mess.
The right place is the access edge. SAML should be terminated in one place; authentication, MFA, conditional access, device trust, and Backend SSO should be managed on the same layer. Then applications never carry the federation protocol's complexity — they only receive a validated, clean, trustworthy identity.
Managing SAML correctly is not just connecting to an IdP. It is validating the organisation's identity trust in one place, bringing it under audit, and safely carrying it to the applications.
How we approach it
One AAM gateway terminates SAML correctly at the edge; the rest of the access engine composes on top.
Standards-correct SAML 2.0 service provider
Signed AuthnRequest on the way out, full assertion validation on the way in — signature, audience, validity window, AudienceRestriction, NameID format. HTTP-Redirect and HTTP-POST bindings are both supported. Signature handling follows the SAML 2.0 conformance rules that exist precisely to defeat the well-known SAML attacks.
Per-application and per-tenant IdP routing
One AAM gateway can route different applications to different IdPs, and different tenants of the same application to different IdPs, at the same time. IdP selection happens per request from the application context — no separate gateway per IdP, no manual login-page chooser for the user.
NameID and attribute mapping into the AAM session identity
Per-IdP mapping rules translate the SAML assertion's NameID and attribute statements into the canonical fields used by the rest of AAM — username, email, groups, display name, custom attributes. The same mapping fuels MFA gating, conditional access predicates, audit logs, and Backend SSO injections.
Coordinated with MFA, conditional access, posture, and Backend SSO
A SAML authentication does not stand alone — it composes with edge MFA (if the IdP didn't enforce step-up itself), with conditional access predicates, with continuous trust evaluation, and with Backend SSO injection toward the downstream app. The SAML assertion becomes one input into the AAM session, not the whole session.
Capabilities
Standards-correct SAML 2.0 SP plus the operational features that make federation safe and manageable at scale.
SP-initiated SSO with signed AuthnRequest
The user hits the application, AAM redirects to the configured IdP with a signed SAML AuthnRequest, the user signs in at the IdP, and the IdP returns a signed assertion to AAM's Assertion Consumer Service endpoint. HTTP-Redirect binding for the outbound request and HTTP-POST binding for the inbound assertion are both supported.
IdP-initiated SSO with RelayState-aware landing
For deployments where the IdP is the user's starting point — a portal launchpad at the IdP, an application catalogue, a public-sector identity portal — IdP-initiated SSO is accepted. RelayState carries the intended application destination so the user lands on the right page after the assertion is consumed.
Full assertion validation — signature, audience, validity, restriction
The assertion's signature is validated against the configured IdP signing certificate; the audience matches the configured AAM SP identifier; NotBefore and NotOnOrAfter define the validity window; AudienceRestriction is enforced. The well-known SAML attacks (signature wrapping, signature stripping, NotBefore drift) are explicitly defeated rather than silently tolerated.
Optional assertion encryption with private-key handling
When the IdP encrypts the assertion (xmlenc), AAM decrypts it with the configured SP private key before validation. Encrypted assertions are common for public-sector identity federation and for IdPs that don't want assertion content to be readable at the binding layer. Encryption keys are stored encrypted in the configuration store and never logged.
NameID format selection and attribute mapping per IdP
Each IdP can be configured with a preferred NameID format (persistent, transient, email-address, unspecified) and a mapping from SAML attribute names to AAM session fields. Different IdPs can present identity differently — a national-ID claim, an email, a unique opaque identifier — and still produce the same canonical AAM session shape.
Per-tenant IdP binding for multi-tenant deployments
One AAM gateway fronting many tenants can route each tenant to its own IdP. Selection happens from the application or tenant context at request time — no separate gateway per IdP, no per-user chooser. The same gateway can simultaneously front public-sector identity federation for one tenant and a private enterprise IdP for another.
Single Logout (SLO) coordinated with AAM session cleanup
When the IdP initiates a logout, AAM accepts the SAML LogoutRequest, terminates the AAM session, and signals downstream backends that received Backend SSO injections. When the application initiates the logout, AAM signs a LogoutRequest toward the IdP and waits for the LogoutResponse before declaring the session gone. Front-channel SLO is supported.
Operational depth
The mechanics that keep a SAML federation safe, current, and observable.
IdP metadata exchange — upload, fetch URL, or manual configuration
IdP metadata can be loaded by uploading the IdP-provided metadata XML, by configuring a metadata URL that AAM fetches and caches, or by specifying the endpoints and certificates manually. Manual configuration is the realistic option for IdPs that don't publish standards-compliant metadata; the other two are preferred where they work.
SP metadata publishing for IdP onboarding
AAM exposes its own SP metadata document at a stable URL so the IdP operator can import it into the IdP's trust store rather than transcribing endpoints and certificates manually. The metadata reflects the live SP configuration — current ACS URL, current signing certificate, current SLO endpoint.
Signing key and certificate rotation without downtime
SP signing keys and certificates have lifetimes. AAM supports key rotation with overlap — both the old and the new key validate against the IdP's cached metadata during the rollover window. Operators schedule rotation in advance; the runtime accepts both during the overlap and the rotation cuts over cleanly.
Clock-skew tolerance with bounded drift window
Assertions carry NotBefore and NotOnOrAfter timestamps. Real clocks drift; AAM applies a configurable tolerance window so a small skew doesn't reject valid assertions, while large drifts (which indicate misconfiguration or replay) still reject. The tolerance is per-IdP, so a well-synchronised IdP gets a tight window and a problematic one gets a documented allowance.
Audit and correlation with the AAM session lifecycle
Every SAML event — outbound AuthnRequest, inbound assertion, signature validation outcome, SLO LogoutRequest, LogoutResponse — is recorded with a correlation ID that ties back to the AAM session, the downstream backend(s), and the user identity. Forensic reconstruction of "who signed in via which IdP and when" is a single-query operation.
Where teams use it
Public-sector identity federation
Applications that must accept a national identity-federation IdP — typical for public-sector deployments, regulated industries, and SaaS services contracted by public-sector buyers. AAM terminates the SAML federation at the edge and exposes a clean, validated identity to the application behind it.
Enterprise IdPs (AD FS, Entra ID, Okta, Ping, Auth0)
Existing enterprise IdPs already authoritative for the workforce. AAM plugs in as a SAML SP without asking the IdP team to change anything. New applications join the federation by adding an entry to AAM, not by adding a new SAML library to each codebase.
Multi-tenant deployments with per-tenant IdPs
SaaS applications where each customer brings their own IdP. One AAM gateway fronts all tenants; each tenant's traffic routes to that tenant's IdP. Adding a tenant means adding an IdP entry to the configuration store, not a deploy.
Edge MFA and conditional access on top of an IdP that doesn't enforce them
Some IdPs authenticate but don't enforce step-up MFA or conditional access — particularly older federation gateways. AAM accepts the IdP's authentication, then composes its own MFA, conditional access predicates, and continuous trust evaluation on top before granting access to the application.
Common questions
Which IdPs does AAM federate with?
How does AAM defend against the well-known SAML attacks?
Can one AAM gateway route different tenants or applications to different IdPs?
Does AAM support Single Logout (SLO)?
What happens to the identity after AAM consumes the assertion?
SAML done correctly, at the edge
We'll connect AAM to your IdP — enterprise or public-sector federation — and let the rest of the access engine compose MFA, conditional access, posture, and Backend SSO on top of the assertion.