SAML decoder

How SAML messages are encoded

SAML 2.0 messages are XML, but they travel through the browser, so each binding wraps them differently:

To capture a message, open your browser's developer tools on the Network tab, sign in, and copy the SAMLResponse form value from the POST to the service provider (or the redirect URL to the IdP). The value may contain attributes about a real person: an expired message from a test account is the better thing to paste.

The fields a service provider must check

The Web Browser SSO profile (SAML profiles §4.1.4.3) lists what the service provider verifies. The decoder pulls each one out:

• Signature coverage: with the HTTP-POST binding each assertion MUST be protected by a signature, on the assertion itself or on the whole Response (Errata 05, E26). The signature's Reference URI MUST point to the ID of the element it signs (SAML core §5.4.2).
• Recipient in the bearer SubjectConfirmationData matches the ACS URL that received it.
• NotOnOrAfter on the subject confirmation has not passed (allowing for clock skew), and the assertion's Conditions window is current.
• InResponseTo equals the ID of the AuthnRequest this SP sent; for an unsolicited (IdP-initiated) response it MUST NOT be present.
• Audience: the assertion's AudienceRestriction names this SP's entity ID.
• One-time use: the SP remembers assertion IDs until they expire, so a captured POST cannot be replayed (profiles §4.1.4.5).

Red flags the decoder looks for

XML Signature Wrapping attacks exploit the gap between the element a signature covers and the element the application reads. An attacker keeps a validly signed assertion in the document, adds a forged one where the application looks first, and relies on a verifier that only asks “is there a valid signature somewhere?”. The decoder flags the shapes that make this possible:

• a signature whose Reference points to an ID other than its parent element's;
• more than one assertion in a Response;
• neither the assertion nor the Response signed;
• XML comments inside NameID: in 2018 several SAML libraries were found to read only the text before a comment, so admin@example.com<!---->.attacker.test was signed as one identity and read as another (CERT VU#475445);
• a DOCTYPE, which SAML never needs and which enables entity-expansion and external-entity attacks;
• SHA-1 signature or digest algorithms.

Try the “suspicious response” example to see them all at once. The defence on the service-provider side is to verify the signature with a strict library, then process only the element that signature covered, selected by the ID the signature referenced, never by searching the document again.

What this decoder does not do

It does not verify XML signatures. Doing that correctly needs exclusive XML canonicalization, the IdP's signing certificate taken from metadata you trust, and the careful element selection described above; a web page that claimed “signature valid” without all of that would give false confidence. It also cannot decrypt an EncryptedAssertion, which needs the SP's private key. It shows you what the message says and where to look; your SAML library decides whether to believe it.

Sources

1. Assertions and Protocols for the OASIS SAML V2.0 (saml-core-2.0-os), OASIS. OASIS specification (cited, brief quotations).
2. Bindings for the OASIS SAML V2.0 (saml-bindings-2.0-os), OASIS. OASIS specification (cited, brief quotations).
3. Profiles for the OASIS SAML V2.0 (saml-profiles-2.0-os), OASIS. OASIS specification (cited, brief quotations).
4. SAML Version 2.0 Errata 05, OASIS. OASIS specification (cited, brief quotations).
5. VU#475445: Multiple SAML libraries may allow authentication bypass via incorrect XML canonicalization and DOM traversal, CERT Coordination Center. Cited for facts; not reproduced.