Understanding SAML Binding Methods
A SAML configuration may use Redirect for the login request and POST for the response. Why does one login use two different methods? A binding defines how a SAML message reaches the other party. Understanding message delivery, signature coverage, and RelayState makes the settings at the IdP and SP easier to follow.
🔗 What is a Binding?
A binding in SAML refers to the transport mechanism used to send SAML messages like requests and responses between parties, typically over HTTP.
Common Types
- 📌 HTTP-Redirect: Encodes the message in the URL query string via a GET request.
- 📌 HTTP-POST: Sends the message in a form field via POST.
- 📌 HTTP-Artifact: Sends only a reference ID, then retrieves the actual message via a separate back-channel request.
🚀 HTTP-Redirect Binding
This binding carries requests such as AuthnRequest and LogoutRequest through a URL. SAMLRequest is the query parameter name; LogoutRequest is a type of XML message inside it. Long messages can exceed URL limits imposed by browsers or servers.
Features & Considerations
- ⚠️ Sends data as a GET request in the URL query string.
- ⚠️ The standard encoding applies raw DEFLATE, then Base64, then URL encoding.
- ⚠️ URL length limitations can cause issues with large messages.
- ⚠️ Digital signatures are included as query parameters.
📮 HTTP-POST Binding
The most common method, used for larger messages and SAML Responses. Relies on HTML form submissions.
Features & Considerations
- ✅ Message is sent in an HTML form via POST.
- ✅ Base64-encoded SAML data goes in a hidden form field.
- ✅ The standard HTTP-POST binding Base64-encodes the XML; do not apply the raw DEFLATE step used by Redirect.
- ✅ Suitable for larger signed messages, subject to server POST size limits.
- ✅ JavaScript can auto-submit the form; a manual submit button also works.
🧩 HTTP-Artifact Binding
The Artifact method only sends a reference (artifact) via the browser, and the full message is retrieved later using back-channel communication.
Features & Usage
- 🔍 Browser sends a short “artifact” ID to the SP.
- 🔍 SP uses SOAP-based ArtifactResolve to get the full assertion from the IdP.
- 🔍 Protect artifact resolution with authentication, integrity and confidentiality as required by the applicable profile.
- 🔍 Offers better control over message delivery but is more complex.
- 🔍 Check support at both ends and secure the artifact resolution endpoint.
📊 Comparison & Use Cases
Requests and responses can use different bindings, such as Redirect requests and POST responses.
Summary Table
- 📋 Redirect: Lightweight and simple; good for SAMLRequest.
- 📋 POST: Most commonly used for SAMLResponse and signed data.
- 📋 Artifact: Retrieves the message through a back channel and requires SOAP support; the binding alone does not ensure security.
Practical binding choices
Check support and security requirements at both ends before choosing a binding.
Security and interoperability
- Redirect signatures depend on the prescribed encoding and signed input; decoding and re-encoding values can break verification.
- POST still needs signature, destination, and time checks, together with TLS.
- Artifact separates message retrieval from the browser path, but its name alone does not guarantee safety.
- Redirect requests and POST responses are a common combination; confirm the advertised endpoints and supported bindings.
🛡️ Signature Requirements by Binding
The signature representation and validation steps depend on the binding.
Key points
- HTTP-Redirect: Reconstruct signed input in the order SAMLRequest or SAMLResponse, RelayState if present, then SigAlg. URL parameter order is arbitrary; preserve the received URL-encoded values.
- HTTP-POST: XML signatures protect the Assertion or Response as required by the profile. The SAMLRequest or SAMLResponse form field contains Base64-encoded XML; RelayState is a separate field.
- Artifact: SOAP resolves the message. Apply authentication, integrity and confidentiality protection required by the profile.
- AuthnRequest signing depends on metadata and policy; when required, the SP signs and the IdP verifies.
RelayState and its limits
RelayState is an optional value for carrying state across a SAML exchange. It can identify a page to return to after login, but it is separate from the SAML XML message.
Keep the value within 80 bytes and protect it
In HTTP-Redirect and HTTP-POST, RelayState must not exceed 80 bytes. This is not an 80-character limit or a limit on the entire URL-encoded query string. If a request carries RelayState, the responder returns the exact received value in the corresponding RelayState parameter.
| Situation | Binding behavior | Implementation point |
|---|---|---|
| Signed Redirect | RelayState, when present, is part of the URL signature input | Preserve received encoded values when verifying the signature. |
| Standard POST with XML signatures | RelayState is a form field outside the SAML XML | A valid XML signature does not necessarily protect RelayState. |
| Restoring state or a return destination | Integrity protection is recommended | One approach is to map a short, hard-to-guess identifier to server-side state. |
Validate the return destination
An implementation that treats RelayState as a return URL can send users to an unintended external site if it redirects without validation. The recipient needs to restrict destinations, for example to paths within its own service or explicitly allowed URLs. Detecting tampering through a signature and deciding whether a destination is allowed are separate checks.
Specifications and related guides
OASIS SAML bindings (sections 3.4.3, 3.4.4.1, 3.5.3, and 3.5.4); OWASP SAML Security Cheat Sheet. For the overall login flow, see SAML basics; for signature validation, see SAML signature basics; for endpoint settings, see metadata operations.