SAML 2.0 has been an OASIS standard since 2005, and it still underpins federated single sign-on across enterprise, government, healthcare, and education. The specification is large, but the components that matter in practice are finite. Here are the nine you need to understand, ordered from most to least critical.
The assertion is the most important artifact in SAML. It's an XML document that carries claims about a user from one party to another. Everything else in the protocol exists to create, transport, or validate assertions.
An assertion contains an Authentication Statement declaring that the user was authenticated, when, and how (password, MFA, certificate). It contains an Attribute Statement that carries user properties such as email, roles, group memberships, and department. And it contains Conditions that constrain where and when the assertion is valid: NotBefore and NotOnOrAfter set a time window (typically minutes), and AudienceRestriction limits which recipients can accept it.
The Identity Provider (IdP) signs the assertion. The Service Provider (SP) validates the signature before trusting anything inside. If you understand one thing about SAML, understand assertions.
The Identity Provider is the system that authenticates users and issues assertions. It's the authority, the entity that knows who you are and can prove it to others.
When a user needs to access a protected application, they log in to the IdP. Username and password, multi-factor authentication, smart cards: the authentication mechanism is the IdP's concern. After successful authentication, the IdP constructs a signed assertion and delivers it to the requesting application.
Think of the IdP as a passport office. It verifies your identity and issues a credential that other parties can trust.
The Service Provider is the application the user wants to access. It protects resources and relies on the IdP to authenticate users rather than managing credentials itself.
When an unauthenticated user arrives, the SP redirects them to the IdP with an AuthnRequest. After the IdP responds with an assertion, the SP validates the signature, checks the conditions, extracts identity and attributes, and establishes a local session. The SP never sees the user's password. It trusts the IdP because the two parties have established a federation agreement backed by exchanged metadata and certificates.
If the IdP is the passport office, the SP is the border checkpoint. It doesn't issue passports, but it knows how to read one.
Metadata is an XML document that each party publishes describing its SAML capabilities: endpoints, supported bindings, and the certificates used for signing and encryption. Instead of manually exchanging configuration details, partners import each other's metadata to establish trust programmatically.
Metadata eliminates an entire class of misconfiguration errors. It's what makes federation scalable. Networks like InCommon (1,000+ organizations) and eduGAIN (10,000+ providers) would be impossible without machine-readable metadata. Non-negotiable for production.
Bindings define how SAML messages physically travel between parties. The two most common are HTTP Redirect (the message is encoded into the URL query string) and HTTP POST (the message is submitted via a browser form). A third option, HTTP Artifact, sends a short reference token through the browser and resolves the full assertion over a back-channel SOAP call.
Your binding choice affects payload size limits, security properties, and user experience. HTTP Redirect has URL length constraints, making it unsuitable for large assertions. HTTP POST handles larger payloads. Artifact binding adds a back-channel verification step favored in high-security government environments.
Profiles are the recipes that combine assertions, protocols, and bindings into specific use cases. They're the interoperability contracts that ensure your implementation works with everyone else's.
The Web Browser SSO Profile is the most important. It defines the exact sequence of redirects, requests, assertions, and validations for browser-based single sign-on. The Single Logout Profile coordinates logout across all SPs in a federation. The Enhanced Client or Proxy (ECP) Profile handles non-browser clients. Without following a profile, you can produce syntactically valid SAML that won't interoperate with anything.
The NameID is how the IdP identifies the user within an assertion. SAML defines several formats: persistent (a stable, opaque identifier unique to each IdP-SP pair, good for privacy), transient (session-scoped, zero linkability between sessions), and emailAddress (human-readable but exposes the user's email).
The format matters more than developers expect. Persistent identifiers let the SP maintain a stable account mapping without knowing the user's real identity at the IdP. Transient identifiers are useful for anonymous access. Mismatched NameID expectations between IdP and SP are a common source of SSO failures.
RelayState is an opaque parameter included in the AuthnRequest by the SP that survives the entire SSO round trip. It tells the SP where to redirect the user after authentication succeeds.
Without RelayState, users always land on the application's home page after SSO, rather than on the deep link they originally requested. It's a small mechanism — just a parameter bouncing through the redirect — but it's the difference between a frustrating experience and a seamless one. Every production SAML implementation uses it.
Single Logout coordinates session termination across an entire federation. When a user logs out of one SP, the IdP sends LogoutRequests to every other SP where that user has an active session and collects responses.
SLO ranks last not because it's unimportant, but because it's complex and often deferred. A reliable SLO requires the IdP to track every active session across all SPs, and partial failures (one SP is down, another times out) create ambiguous states. Many deployments launch with local-only logout and add SLO later when compliance or security policy demands coordinated session termination.
In practice, SLO's biggest challenge is partial failure. If one SP in the federation is temporarily unreachable, does the logout succeed or fail? Browser-dependent front-channel logout introduces additional fragility: cookie settings, network interruptions, pop-up blockers, and timeout variance all affect reliability. Back-channel logout (sending server-to-server notifications) mitigates some of these issues but requires each SP to expose a logout endpoint. Most mature deployments implement back-channel logout as the primary mechanism and treat front-channel logout as a best-effort supplement.
These nine components cover the surface area that matters. Assertions carry the data. IdP and SP are the parties. Metadata establishes trust. Bindings handle transport. Profiles enforce interoperability. NameID, RelayState, and SLO handle the details that distinguish a proof of concept from a production deployment.
SAML's fundamentals haven't changed since 2005, and they won't need to. That's the mark of a well-designed standard.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。