SAML Attacks Explained: Risks and Defenses

📅 September 28, 2026  |  🏷 General  |  Cyber Security, Information Security, Threat Management

A single XML assertion — smaller than a typical email signature — can hand an attacker the keys to your entire enterprise identity infrastructure. That’s not a hypothetical: in 2021, researchers demonstrated that a misconfigured SAML implementation in a major cloud SSO provider allowed complete authentication bypass with no valid credentials whatsoever. Security Assertion Markup Language was designed to be the universal trust broker between identity providers and service providers, but every layer of that trust chain carries exploitable assumptions. Understanding exactly where those assumptions break — and how attackers weaponize them — is prerequisite knowledge for any security architect defending a federated identity ecosystem.

What SAML Is and Why It Became a High-Value Target

SAML 2.0, standardized by OASIS in 2005, enables single sign-on (SSO) across organizational and application boundaries by passing signed XML assertions between an Identity Provider (IdP) and a Service Provider (SP). When a user authenticates with their IdP — say, Azure AD, Okta, or ADFS — the IdP issues a digitally signed XML document asserting identity attributes and authorization decisions. The SP trusts that assertion without re-authenticating the user directly.

The attack surface is significant precisely because of that trust model. The SP blindly trusts whatever the IdP says — provided the cryptographic signature validates. Compromise the signature verification logic, inject malleable XML, or exploit configuration gaps, and you’ve bypassed the entire authentication layer. A 2023 Verizon Data Breach Investigations Report found that credential abuse and authentication bypass remain the leading initial access vectors in enterprise breaches, with federated identity infrastructure frequently implicated.

The Anatomy of a SAML Assertion

A SAML response consists of several critical components: the Issuer (identifies the IdP), the Conditions element (defines valid time windows and audience restrictions), the AuthnStatement (certifies the authentication event), and the AttributeStatement (carries user attributes like roles and group membership). The entire response or individual assertions within it may be signed using XMLDSig (XML Digital Signature). This structure matters because different attack classes target different components — XML signature wrapping attacks target the signing scope, while assertion replay attacks exploit the Conditions element’s time and audience validation.

Why Enterprises Are Particularly Exposed

SAML implementations sit at the intersection of multiple complex technologies: XML parsing, PKI, HTTP redirects, and base64 encoding. Enterprise deployments often involve legacy service providers with outdated SAML libraries, custom integrations with incomplete validation logic, or misconfigured certificate trust chains. A 2022 Duo Security analysis found that over 40% of enterprise SAML implementations they assessed had at least one significant misconfiguration — ranging from missing audience restriction validation to accepting assertions signed with deprecated SHA-1 algorithms.

XML Signature Wrapping (XSW) Attacks

XML Signature Wrapping is arguably the most technically sophisticated and historically impactful class of SAML attacks. The fundamental premise exploits a critical disconnect: the component that validates the XML signature and the component that processes the SAML assertion’s content may be referencing different parts of the XML document tree.

In a canonical XSW attack, the attacker intercepts a legitimate SAML response, then restructures the XML document by duplicating assertion elements. The original, legitimately signed assertion is relocated to an obscure position in the document tree (where the signature validation routine will find and verify it), while a forged assertion containing attacker-controlled identity attributes is placed where the business logic parsing routine will process it. The signature validates against the real data; the application acts on the fake data.

The Eight XSW Variants

Security researchers Andreas Mayer and Juraj Somorovsky documented eight distinct XSW variants in their landmark paper, each exploiting different XML tree positions and signing configurations. These variants cover scenarios involving signed responses with unsigned assertions, signed assertions with unsigned responses, and combinations thereof. The practical implication is that a defensive fix addressing one variant may leave an application vulnerable to another. In 2018, researchers demonstrated XSW vulnerabilities in Amazon Web Services’ SAML implementation, allowing role elevation within AWS accounts — a finding that prompted significant patches across multiple SAML libraries including python-saml and OneLogin’s SDK.

Effective defense requires that service providers use the Reference ID mechanism within XMLDSig to explicitly bind the signature to a specific assertion ID, and that they retrieve assertion content exclusively via that same ID after validation — never by positional XML tree traversal.

SAML Assertion Replay Attacks

Replay attacks represent a simpler but frequently underestimated threat vector. A SAML assertion is a time-bounded credential: the NotBefore and NotOnOrAfter attributes in the Conditions element define its validity window. If an attacker can intercept a valid, properly signed assertion during that window — through a man-in-the-middle position, network sniffing on non-TLS segments, or malware on an endpoint — they can re-present that assertion to the service provider and gain authenticated access as the victim user.

The attack window is often larger than administrators assume. SAML implementations frequently accept validity windows of 5 to 15 minutes to accommodate clock skew between IdP and SP servers. An attacker with access to a captured assertion has that entire window plus any clock skew tolerance to replay it. In high-value target environments, even a 5-minute window provides ample time for privilege escalation or data exfiltration.

Mitigating Replay Through Assertion ID Tracking

The primary technical defense is assertion ID caching: the SP maintains a short-term cache of all processed assertion IDs and rejects any assertion whose ID has already been seen. This is a SAML 2.0 specification requirement, yet many implementations omit it. Secondary controls include strict audience restriction validation (ensuring assertions issued for one SP cannot be replayed against another) and enforcing tight, synchronized validity windows using NTP across all federated parties. Any SP that accepts SAML responses over non-TLS channels — even in internal networks — dramatically expands the interception surface and should be treated as a critical misconfiguration.

SAML Response Forgery and Signature Bypass

Beyond structural XML manipulation, attackers pursue direct signature bypass through cryptographic and implementation vulnerabilities. Several classes of attack fall into this category, each exploiting different weaknesses in how SAML libraries handle signature verification.

Signature exclusion attacks exploit SPs configured to accept unsigned assertions. If the SP doesn’t enforce signature requirements — a misconfiguration that appears in surprising frequency in legacy integrations — an attacker can craft a completely forged assertion and submit it without any signature. The SP accepts it because it never checks. A 2019 survey of open-source SAML libraries found that several popular implementations did not enforce signature presence by default, placing the burden entirely on application developers to enable this check explicitly.

Algorithm Confusion and Weak Cryptography

Algorithm confusion attacks involve manipulating the SignatureMethod element within the XMLDSig structure to specify a weaker or attacker-controllable algorithm. Some vulnerable implementations will honor the algorithm specified in the assertion rather than enforcing an allowlist of approved algorithms on the SP side. If an attacker can downgrade the signature algorithm to HMAC-based verification with a key they control, or exploit a library that treats certain algorithm URIs as equivalent to no verification, signature validation becomes meaningless. The practical fix is server-side algorithm allowlisting: the SP must define and enforce exactly which signature algorithms it will accept, completely ignoring what the assertion specifies.

Additionally, SP implementations that use certificate fingerprint comparison rather than full PKI chain validation may be vulnerable to certificate substitution attacks, where an attacker provides a self-signed certificate whose fingerprint matches a stored value through collision engineering — a theoretical but credible threat against SHA-1 fingerprinting.

SAML IdP Impersonation and Phishing Vectors

Not all SAML attacks target cryptographic primitives. Social engineering and infrastructure attacks against the identity provider itself represent a devastating attack path that bypasses all SP-side defenses entirely. If the attacker controls the IdP — or successfully impersonates it — they can issue legitimately signed, cryptographically valid assertions for any user in the directory.

The SolarWinds supply chain compromise in 2020 demonstrated this at scale. Threat actors (identified as Cozy Bear / APT29) gained access to ADFS signing certificates, enabling them to forge SAML tokens and impersonate arbitrary users across federated Microsoft 365 and Azure environments belonging to victim organizations. Because the assertions were cryptographically legitimate — signed with the actual IdP’s private key — detection through signature validation was impossible. The attack persisted for months across multiple high-profile government and enterprise targets.

SAML Phishing and Open Redirect Exploitation

Attacker-controlled identity providers can also be weaponized in phishing campaigns targeting SAML flows. By registering a malicious SP with a legitimate IdP that permits open SP registration (as some federation hubs allow), attackers can initiate authentication flows that capture IdP session cookies or credential inputs from phished users. Separately, open redirect vulnerabilities in SAML relay state parameters — where the RelayState value is used to redirect users post-authentication — allow attackers to craft malicious SSO URLs that, after legitimate authentication, redirect users to attacker-controlled pages for credential harvesting or malware delivery. Organizations should validate RelayState values against a strict allowlist of internal URLs before performing post-authentication redirects.

Detecting and Responding to SAML-Based Attacks

Detection of SAML attacks requires instrumentation at multiple layers because the attacks often produce valid-looking traffic at the network level. The malicious payload is embedded in the authentication protocol itself, not in anomalous network signatures that traditional IDS/IPS systems recognize.

Effective detection strategies include logging and analyzing the raw SAML assertion content at the SP — specifically monitoring for assertions with unusual structural characteristics (multiple assertion elements, unexpected namespace prefixes, or assertion IDs that repeat), validity windows significantly shorter or longer than organizational norms, and authentication events for privileged accounts originating from unexpected IdP endpoints. SIEM correlation rules should flag any SAML authentication followed immediately by high-privilege operations, particularly lateral movement or bulk data access.

Incident Response Considerations for SAML Compromise

When a SAML compromise is suspected — particularly IdP key compromise analogous to the SolarWinds scenario — the incident response playbook must account for the fact that standard credential revocation (password resets, MFA enforcement) may be insufficient. If signing certificates are compromised, all federated trust must be reestablished: certificates rotated, all SPs updated with new certificate thumbprints, and historical authentication logs from the compromise window reviewed for unauthorized assertions. Organizations should maintain an offline backup of IdP signing certificate metadata and establish break-glass procedures for re-establishing federation without the potentially compromised IdP infrastructure. Microsoft’s post-SolarWinds guidance recommends treating the ADFS service account and signing certificate as tier-0 assets equivalent to domain controller credentials.

Key Takeaways

• XML Signature Wrapping is the most technically complex SAML attack class — defense requires that SPs validate content exclusively via the signed Reference ID, not by XML tree position, and that all eight documented XSW variants are considered in library assessments.
• Assertion replay is a specification-defined threat with a specification-defined defense — assertion ID caching at the SP is a SAML 2.0 requirement, not an optional hardening measure; treat any SP that doesn’t implement it as critically vulnerable.
• Signature absence and algorithm confusion attacks thrive on misconfiguration — every SP must enforce signature presence, maintain an approved algorithm allowlist server-side, and never defer cryptographic policy decisions to the assertion itself.
• IdP compromise renders all SP-side controls moot — the SolarWinds attack illustrates that federation security is only as strong as IdP key material protection; ADFS signing certificates and service accounts must receive tier-0 security treatment.
• Detection requires protocol-layer logging, not just network monitoring — SAML assertion content analysis in your SIEM, combined with behavioral correlation rules for post-authentication activity, is essential for catching attacks that are invisible at the packet level.

Conclusion: Hardening Your SAML Implementation Before the Next Assertion Is Forged

SAML’s architectural elegance — delegated trust through signed XML — is inseparable from its attack surface. Every trust delegation is an assumption an attacker will probe. The good news is that the majority of SAML attack classes documented above are preventable through a combination of correct implementation of the existing specification, rigorous library selection and patching, and operational security around IdP key material.

Start with a structured SAML security assessment this quarter. Audit every service provider integration against a checklist that covers: signature enforcement and algorithm allowlisting, assertion ID caching, audience and recipient validation, RelayState allowlisting, and TLS enforcement on all SAML endpoints. Evaluate your SAML library versions against the CVE database — libraries like python-saml, ruby-saml, and OneLogin SDKs have had significant vulnerabilities patched in recent years, and running outdated versions in production is a direct exposure. For organizations running ADFS, apply Microsoft’s specific hardening guidance for ADFS signing certificate protection and consider migrating to Azure AD’s cloud-managed federation where the signing key management risk transfers to Microsoft’s security infrastructure.

Finally, run a tabletop exercise specifically against the IdP compromise scenario. Define your detection tripwires, your certificate rotation runbook, and your communication chain before an incident forces those decisions under pressure. The federated identity stack is too critical — and too opaque to conventional monitoring — to leave unexercised. Schedule that assessment today.