SAML learning guide

Learn SAML from the browser flow outward.

Follow the practical SAML 2.0 exchange from request to assertion. Start with what each message is for, then open the official specification when you need the exact rule.

SAML flow at a glance

AuthnRequestActor: SPDirection: SP to IdP through the browserChannel: front-channelPurpose: Requests authentication and identifies the SP, destination, and requested behavior.
User authenticationActor: IdPDirection: Browser and IdPChannel: front-channelPurpose: Authenticates the subject and evaluates the requested authentication context.
SAMLResponseActor: IdPDirection: IdP to SP through the browserChannel: front-channelPurpose: Returns status and an assertion to the SP Assertion Consumer Service.
ACS validationActor: SPDirection: At the SPChannel: front-channelPurpose: Validates signatures, subject confirmation, time, audience, and replay constraints before creating a session.

Current guide

SAML learning paths

Browse every chapter, or choose a goal to follow a shorter ordered route.

Learning modeGuided pathFull protocol reference

Guided paths

Start hereBuild a safe mental model from trust configuration through browser sign-on and response validation.Understand the flowTrace both browser SSO entry points, browser state, bindings, and response processing.Configure a requestChoose AuthnRequest controls deliberately and understand their interoperability impact.Validate a responseApply the checks needed before accepting a SAML authentication result.Debug a failureConnect common request, response, trust, time, and browser-state failures to their causes.Perform a security reviewReview trust, message integrity, recipient constraints, confidentiality, and replay resistance.

Start hereStep 1 of 9

Learn the SAML roles, metadata, and certificate trust that must be in place before a browser flow begins.

Follow SP-initiated and IdP-initiated sign-on through browser delivery and response correlation.

Understand the request controls an SP can send and how those choices affect authentication.

Check status, signatures, subject confirmation, conditions, statements, attributes, encryption, and replay defenses.

Diagnose production failures and manage session termination without weakening validation.

Explore artifact delivery, identifier management, discovery, non-browser clients, assurance, and later profiles.

Foundations and trustCore lesson2 min readStart here · 1 of 9

Reference only

SAML fundamentals

SAML browser SSO moves an authentication request and a security assertion between an SP and an IdP through the user agent.

What it is

SAML 2.0 is an XML-based framework for assertions and request/response protocols. In browser SSO, the service provider (SP) consumes a response from the identity provider (IdP).

Why it matters

Most integration failures become easier to isolate once you distinguish the protocol message, the browser binding that carries it, and the profile rules that connect the exchange.

How it works

The SP and IdP establish identifiers, endpoints, bindings, and verification keys, usually through metadata.
The browser carries an AuthnRequest to the IdP or begins an IdP-initiated flow without an SP request.
After authentication, the IdP returns a SAML Response message or an artifact through the browser; Artifact Resolution retrieves the response separately.
The SP validates the response and assertion before creating an application session.

Options available

SP-initiated and IdP-initiated browser SSO are distinct starting patterns.
HTTP-Redirect, HTTP-POST, and HTTP-Artifact are transport bindings with different message-handling rules.
Assertions can carry an authentication statement, attributes, and authorization information.

What the official specification says

Read the Core specification for message semantics, Bindings for transport rules, and Profiles Section 4 for the complete browser SSO composition.

Security and interoperability notes

A successful browser POST is not proof of identity; validate XML signatures, destination, audience, time limits, subject confirmation, and replay state.
All names and values shown by this guide are fictional fixtures. The workbench sends no SAML traffic and does not validate a live IdP.

Workbench support