Cybersecurity research podcast
On Breaking SAML: Be Whoever You Want to Be
Using systematically generated structural SAML message variants, the researchers examined how signature verification and claim processing may select different XML nodes. SAML integrations should preserve signed-element provenance and pass only content established as signed to application logic. Because the evaluation covered particular systems and generated variants, its findings do not establish exposure beyond the evaluated setting.
Episode 25 Aug 2026 · Paper 9 Aug 2012 · 21st USENIX Security Symposium · VERSION of RECORD
Research summary
A technical explanation of the paper's research question, method, reported findings and limitations. The researchers found that most systems in the evaluated sample were vulnerable. Most accepted refined wrapping attacks, and a smaller group accepted signature-exclusion variants. A minority resisted every tested variant. Vulnerability was common in this…
Be sceptical of the phrase ‘valid SAML signature.’ The 2012 study found 11 of 14 tested implementations vulnerable because verifiers and applications could consume different XML. Later patches reduced specific attacks, but advisories through 2026 show equivalent parsing, provenance, and tenant-binding failures. The strongest successor is differential end-to-end testing with validation receipts that bind signed content to issuer, tenant, and authorization.
Paper details
Authors: Juraj Somorovsky , Andreas Mayer , Jörg Schwenk , Marco Kampmann , Meiko Jensen
Transcript
Highlighting follows the podcast. Select any word to seek.
On Breaking SAML: Be Whoever You Want to Be. SAML stands for Security Assertion Markup Language. Juraj Somorovsky and colleagues presented this research at the USENIX Security Symposium in 2012. They examined a subtle failure at the boundary between XML signature verification and application processing: a verifier can authenticate one part of a message while the application consumes another. By the end, you should understand how those components can disagree about the effective message and why their choice of XML nodes forms a security-critical interface.
SAML and XML Signature processing both allow flexibility in how structured messages are handled. That flexibility can cause different components to observe different effective messages. The security problem appears when the signature verifier selects one XML node while the claim-processing code selects another. The two components can then disagree about which content matters.
The security question is whether the signature verifier and the claim-processing code select the same XML node. The attack does not require breaking the signature algorithm. Even without a cryptographic forgery, the two components may select different nodes and therefore disagree about what was authenticated. Their interface is security-critical: application logic should consume only the content established as signed.
The attacker model starts with one legitimately signed SAML message. It does not assume control of the network, compromise of the identity provider, or a cryptographic forgery. The researchers built an attack generator that systematically varied XML schema extension points and the placement of signatures, identifiers, and wrapper elements. The study used generated attack variants to evaluate the systems for vulnerabilities.
The researchers found that most systems in the evaluated sample were vulnerable. Most accepted refined wrapping attacks, and a smaller group accepted signature-exclusion variants. A minority resisted every tested variant. Vulnerability was common in this sample, but the attack was not inevitable across the tested implementations.
Two implementation cases make the failure concrete. In OpenSAML, the attack combined XML schema extension behavior with differences in how Java and C++ code resolved XML identifiers. In Salesforce, a repair focused on the Assertion element, but a wrapping variant targeting the Audience element remained until a later mitigation. The researchers disclosed every vulnerability they identified and collaborated on multiple repairs.
These measurements have clear boundaries. The finding that most evaluated systems were vulnerable applies only to the systems and study period examined; it does not establish that every SAML implementation is vulnerable. Likewise, the systems that resisted all generated variants were not proven completely secure. They resisted what the researchers attempted. That distinction matters because successful testing can demonstrate a defect, while unsuccessful attacks provide narrower evidence about the cases covered by the test set.
For identity teams and security architects, the safer design is to make application logic consume only the exact content established as signed. The signature verifier and claim processor should not be allowed to select different XML nodes. Randomly marking signed elements can preserve their authenticated origin into claim processing. Defensive testing can vary schema extension points and the placement of signatures, identifiers, and wrapper structures. This can expose disagreements between signature verifiers and claim-processing code.
Somorovsky and colleagues examined the verifier-to-claim-processing boundary, systematically generated attack variants, and found most tested systems vulnerable. Teams responsible for SAML integrations should trace which exact XML content reaches authorization logic and test whether structural changes alter that selection. They should not infer that every implementation is affected, or that resistance to the generated variants proves complete security. The useful takeaway is narrower: signed content and consumed content must remain explicitly connected.