How To: SAML Flows: Overview

Version Affected: All 

 

Overview

The SecureAuth Identity Provider (IdP) supports SAML 2.0 Web Browser SSO through a few different flows, depending on where the flow starts and which HTTP binding carries the authentication request. This article explains what each flow is and the communication pattern between the browser, the Service Provider (SP), and the IdP, so you know which one you're looking at when reading a log or a customer's description of their setup.

In this article

• SP-Initiated by Redirect
• SP-Initiated by POST
• IdP-Initiated

SP-Initiated by Redirect

The user visits the SP, which redirects the browser to the IdP's SSO endpoint with the AuthnRequest compressed and included directly in the URL as the SAMLRequest query parameter. After authenticating the user, the IdP returns the SAMLResponse via an HTTP-POST binding (an auto-submitting form) to the SP's Assertion Consumer Service (ACS) URL — POST is used for the response even though Redirect was used for the request, since a full SAML response is usually too large to fit in a URL.

Use this when: the SP's SAML library defaults to, or is specifically configured for, the Redirect binding when sending its AuthnRequest.

Worth knowing: because the request travels in the URL, an unusually large AuthnRequest (heavy use of extensions, or a large embedded signature block) can exceed the URL length limit some browsers or intermediate proxies enforce. If that happens, switching the SP to send its request via POST instead resolves it.

SP-Initiated by POST

The user visits the SP, which returns an auto-submitting HTML form that POSTs the AuthnRequest (base64-encoded, not compressed — POST doesn't need the same URL-length optimization Redirect does) to the IdP's SSO endpoint. After authenticating the user, the IdP returns the SAMLResponse the same way, via POST to the SP's ACS URL.

Use this when: the SP's implementation defaults to POST for both directions of the exchange, or its AuthnRequest is too large to send comfortably via Redirect.

Worth knowing: because this relies on an auto-submitting form rather than a simple redirect, a locked-down browser or proxy configuration that blocks auto-submitting forms or cross-origin POSTs can interfere. If a customer reports a POST-initiated realm's login silently failing — no error, no redirect, just a blank or stuck page — this is one of the first things to check.

IdP-Initiated

Unlike the two SP-Initiated flows above, there is no AuthnRequest at all. The user starts directly at the IdP — for example, by clicking an application tile in an IdP-hosted portal, or a bookmarked deep link straight to the realm. Once the user is authenticated, the IdP sends an unsolicited SAMLResponse via POST directly to the SP's ACS URL, without the SP ever having asked for it.

Use this when: users are meant to start their session from a central portal or app launcher rather than by visiting the application directly, or the SP doesn't support initiating its own SAML request.

Worth knowing: because there's no preceding AuthnRequest, there's no InResponseTo value for the SP to validate the response against, and often no per-session RelayState either — which makes an unsolicited response inherently harder for an SP to fully validate compared to one it initiated itself. Many security-conscious SPs disable IdP-Initiated SSO entirely for this reason. If a customer reports IdP-Initiated login being rejected by the SP with no clear error on the IdP side, confirming the SP actually accepts unsolicited responses is a good first step.

 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.