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.
One AAM gateway terminates SAML correctly at the edge; the rest of the access engine composes on top.
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.
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.
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.
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.
Standards-correct SAML 2.0 SP plus the operational features that make federation safe and manageable at scale.
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.
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.
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.
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.
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.
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.
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.
Back-channel SOAP-based Single Logout, the SAML ECP (Enhanced Client/Proxy) profile for non-browser clients, and holder-of-key subject confirmation for high-assurance integrations are on the roadmap. The configuration object and the rest of the SP pipeline already accommodate them; the protocol-specific code is the remaining work.
The mechanics that keep a SAML federation safe, current, and observable.
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.
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.
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.
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.
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.
Automated periodic refresh of IdP metadata from the configured URL, with diff detection and operator alerting on signing-certificate changes, is on the roadmap. Rotation telemetry — metrics on key age, days-until-expiry alerting, automated rollover scheduling — is also planned.
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.
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.
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.
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.
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.