Home Supported Standards Terms & Conditions Privacy Policy Documentation Contact About

← Return to SAML Test Tools

Take a SAML AuthnRequest off the wire and read it. Paste a full redirect URL, a query string, an HTTP-POST form body, a bare SAMLRequest parameter, an artifact, or the XML itself — the binding is worked out from the blob. Everything runs in your browser: nothing is sent anywhere, and no key you paste is written to storage. Signature validation and decryption are both optional and each is switched on separately, because a message that is neither signed nor encrypted still decodes.

Tip: click a pane's title to collapse/expand it.

Message
Binding parameters

What the blob carried beside the message itself. Redirect signs these, POST does not — which is why the pane below asks for different things on each.

 
Digital Signature (optional)

A signed request carries its signature in one of two completely different places, and which one it is follows from the binding. HTTP-POST puts an enveloped <ds:Signature> inside the document, KeyInfo and all, so it can be checked from the XML alone. HTTP-Redirect signs the query string itself (saml-bindings-2.0-os §3.4.4.1) — a detached signature with nowhere to put a KeyInfo, so the signer's certificate has to be supplied below.

View certificate details →
Decryption (optional)

The recipient's key pair. Only the private key decrypts; the certificate is optional and is used to say whether this is the key the sender actually wrapped to — a mismatch there is the ordinary reason a decryption fails, and it is invisible otherwise. Prefilled from the SP key on the SAML Test Tools page when that page is keeping one. Nothing pasted here is stored.

Decoded Message

The blob exactly as it was pasted, and the encoded message parameter pulled out of it.

The <xenc:EncryptedData> found in the decoded message, with the wrapped session key beside it when the sender put it there. This is exactly what the Decryption pane operates on.

The base64-decoded (and, on the Redirect binding, inflated) message, pretty-printed. The indentation is display only — a signature is computed over the bytes as sent, so verification uses the original serialization rather than what is shown here.

The values worth reading, in whichever protocol version the message is written in. An optional attribute that is absent is shown as absent where its default matters — ForceAuthn unset and ForceAuthn="false" mean the same thing to the specification and very different things to somebody who thought they had set it.

 
Tools

Standalone utilities for working with SAML and its XML security layers.

SAML Response Decoder — take a SAML response off the wire and read it, in SAML 2.0 or SAML 1.1: paste a POST form body, a redirect URL, a bare SAMLResponse, an artifact, a bare <saml:Assertion> or the XML, and get the status, every assertion and its attributes, a check of every signature it carries (message, assertion and query-string, reported separately) and optional decryption.
SAML Assertion Tool — compose a spec-compliant SAML 1.0/1.1/2.0 assertion (optional elements, NameID, custom attributes), sign it with XML Signature, and encrypt it with XML Encryption.
Certificate Details — parse an X.509 certificate (PEM or bare base64 DER) and inspect its subject, issuer, validity, key, extensions, and fingerprints.
Certificate Authority & X.509 Tools — build a Root, Intermediate and Issuing certificate authority, issue TLS server/client, code-signing, S/MIME and other certificates with every X.509v3 extension, and test a real TLS or mutual-TLS handshake with what you issued.