SAML 查看器

What you can paste

SAML 2.0 moves XML messages between an identity provider (IdP) and a service provider (SP) through the browser. The inspector reads them in every form they travel in:

• raw XML — a samlp:Response, a bare saml:Assertion, an AuthnRequest, LogoutRequest or LogoutResponse, or md:EntityDescriptor metadata;
• the HTTP-POST binding — the base64 of the XML, as the browser posts it in the SAMLResponse form field, alone or as the whole form body with RelayState;
• the HTTP-Redirect binding — a URL whose SAMLRequest or SAMLResponse parameter is DEFLATE-compressed and base64-encoded, signed in the query string with SigAlg and Signature (SAML Bindings §3.4.4.1): the inspector inflates it with your browser's own DecompressionStream and checks that signature over the parameters exactly as they appear.

Documents with a DOCTYPE are refused before parsing, as the SAML specifications require.

What a signature actually covers

XML signatures (XML-DSig) do not sign a document; they sign the elements their Reference URIs point to, after canonicalisation and transforms. A SAML signature is supposed to sit inside the element it signs and point at its ID. The inspector shows, for every ds:Signature, the element each reference resolves to, recomputes each digest, checks the signature value over the canonical SignedInfo, and then says what the signature protects — a Response, an Assertion, or nothing it can be proven to protect.

That last line is where real-world SAML breaks. A service provider does not consume "the signed element"; it consumes the first assertion of the Response. Signature wrapping attacks insert a second, unsigned assertion where the SP looks, or move the signed one where the signature still verifies but nothing reads it; others exploit comments that truncate a NameID during canonicalisation, duplicated IDs, references to an outer element, or a signature that verifies only with a certificate the attacker put into KeyInfo. The inspector compares what is signed with what an SP consumes and reports every gap: the consumed assertion unsigned, several assertions, nested assertions in Advice, duplicate IDs, a reference that is not the signature's parent, extra transforms, comment-split text, a signature made with the embedded certificate instead of the IdP's.

The conditions of an assertion

With your SP settings it also checks what SAML Core §2.5 and §2.4.1 and the Web Browser SSO profile require: the Issuer, the Audience against your entityID, Destination and the bearer SubjectConfirmationData Recipient against your ACS URL, InResponseTo against your request, NotBefore and NotOnOrAfter against the check time, and the Response status. It lists the NameID, the authentication context and every attribute. For metadata, it shows the roles, endpoints and keys and flags endpoints that do not use TLS.

The examples come from the signature test corpus of node-saml, the SAML library behind Passport: a correctly signed Response, a wrapped one, one re-signed by an attacker with their own certificate in KeyInfo, a signed LogoutRequest in XML and over the Redirect binding, and signed SP metadata. They were signed years ago, so each sets the check time its tests use. For the signatures of European e-signature documents, which use the same XML-DSig with ETSI extensions, see the XAdES inspector; for the protocol that replaces SAML in most new deployments, the OIDC ID token validator. What a service provider must check, and why, is set out in SAML signature validation: what to check and why.