SAML SSO Flows

Establishing the Circle of Trust

SAML SSO Flows are the specific sequences of interactions that allow an enterprise user to move seamlessly between independent corporate domains. Unlike standard web logins, these flows are designed for high-assurance environments where the application (The Service Provider) does not store the user’s password. Instead, the “Flow” establishes a secure, browser-mediated tunnel between the application and the central authority (The Identity Provider). Choosing between SP-Initiated and IdP-Initiated flows is a critical architectural decision that determines the user experience, deep-linking capabilities, and security posture of the federation.

Core Mission

Universal Credential Isolation. Ensuring that identity assertions are delivered securely from the authority to the resource, decoupling the user's credentials from the application service.

Like a Sovereign Handshake: Imagine you are a diplomat visiting a protected city (The SP). You don't have to explain yourself to the gate guard. Instead, your home government (The IdP) sends a pre-registered messenger (The SAML Assertion) to meet you at the gate. The guard doesn't need to know your history; they only need to see the official seal of the messenger to allow you in. The "Flow" is the specific protocol that the diplomat and the messenger follow to meet at the right gate at the right time.

Corporate Portals / SaaS Onboarding / B2B Partner Access

The SSO Strategy Matrix

Selecting the correct flow depends on where the user starts their journey and how the application handles session state.

Strategic Selection Grid

Flow	Initiation Point	Strategic Goal	Security Profile
SP-Initiated	The Application URL.	Deep-linking & User Context.	Recommended (Modern).
IdP-Initiated	Corporate Dashboard.	Centralized App Launching.	Risk of “Unsolicited” Replay.
SLO (Logout)	Any participating app.	Global Security termination.	High (Critical Cleanup).
ECP (Enhanced)	Thick Clients / Mobile.	Non-browser authentication.	Specialized (Desktop/App).

The Federation Lifecycle

Regardless of the initiation point, every SAML flow follows a rigorous sequence of XML generation and signature verification.

graph TD
    Start[User Interaction] --> Request[Generate <AuthnRequest>]
    Request --> Redirect[IdP Authentication]
    Redirect --> Assert[Issue Signed <Assertion>]
    Assert --> Consume[Verify at ACS Endpoint]
    Consume --> Establish[Local Session Creation]

Identify & Request

In an SP-initiated flow, the application detects an unauthenticated user and generates a ``. This XML block specifies the requested security profile and the ACS URL where the user should be returned after a successful login.

Authenticate & Assert

The IdP authenticates the user (e.g., via Kerberos or MFA). Once identity is proven, the IdP generates a `` containing a signed ``. This assertion is the legal tender of the federation, carrying the proof of identity and user attributes.

Validate & Consume

The user's browser "Blows" the SAML assertion back to the SP via an HTTP POST. The SP performs a rigorous cryptographic check of the signature against the IdP's metadata. If valid, the SP maps the XML attributes to a local session, granting access.

Technical Flow Implementation

Managing the HTTP bindings is critical for ensuring the secure delivery of SAML messages.

SP-Initiated Redirect (Technical Example)

# Simplified SAML Redirect Request (GET)
https://idp.example.com/sso?SAMLRequest=fVLLasMwELz7...
&RelayState=https://app.example.com/deep-link/dashboard
&SigAlg=http://www.w3.org/2000/09/xmldsig#rsa-sha256
&Signature=MIIB...

SAML Implementation Guides

Master the technical details of the various enterprise authentication patterns.

Next Steps

Explore IdP-Initiated Security Concerns for mitigating unsolicited response vulnerabilities.
Review HTTP-POST vs. HTTP-Redirect Binding for choosing the right transport.
Check SAML Single Logout (SLO) for coordinating cross-app session termination.