How does SAML use XML Signature and XML Encryption, and what is an XML signature wrapping attack?

XML Signature proves that an assertion or response comes from the IdP and was not changed; XML Encryption hides the assertion from the browser and intermediaries. Signature wrapping exploits code that verifies one signed element but then reads data from a different, unsigned one.

Signatures: the IdP signs the <Assertion> (and/or the whole <Response>) with its private key. The signature references the signed element by its ID, and the SP verifies it with the IdP's certificate from metadata.

Encryption: because the browser carries the assertion, attribute values (names, e-mail, roles) would be visible to the user agent and anything running in it. The IdP can therefore send an <EncryptedAssertion>, encrypted for the SP's public key from its metadata, or encrypt only the identifier (<EncryptedID>) or single attributes.

Signature wrapping (XSW): an attacker takes a genuine, signed response, moves the signed assertion somewhere the verifier still finds it (for example inside an extension element), and inserts a forged assertion where the application logic looks for "the" assertion. The signature check passes on the original; the login uses the forgery. A 2012 study found this in 11 of 14 SAML frameworks, and parser-differential variants still produced critical bypasses in widely used libraries in 2024 and 2025.

Mitigations: validate against the schema, process only the elements the signature actually covers, reject documents with unexpected multiple assertions, and use a maintained library.

Go deeper:

• On Breaking SAML: Be Whoever You Want to Be (USENIX Security 2012) — the study that systematised signature wrapping against SAML frameworks.
• GitHub: Sign in as anyone, bypassing SAML SSO with parser differentials — a 2025 signature wrapping bypass in ruby-saml, explained step by step.
• On Breaking SAML (29C3) — the conference talk demonstrating the attacks live.