SAML: Security Assertion Markup Language

Introduction

SAML (Security Assertion Markup Language) is an open standard for exchanging authentication and authorization data between parties, specifically between an Identity Provider (IdP) and a Service Provider (SP). SAML uses XML-based messages to convey security assertions -- statements about a user's identity, attributes, and permissions -- enabling Single Sign-On (SSO) across different web applications and organizational boundaries.

Before SAML, users in enterprise environments had to maintain separate credentials for each application. An employee might need different usernames and passwords for email, HR systems, project management tools, and cloud applications. This created password fatigue, increased help desk calls, and multiplied the attack surface. SAML solves this by allowing users to authenticate once with their organization's Identity Provider and then access multiple Service Providers without re-entering credentials.

SAML is primarily used in enterprise and government environments for workforce identity. It is the dominant SSO protocol for applications like Salesforce, Workday, ServiceNow, AWS, Google Workspace, and thousands of other SaaS products. SAML 2.0, released in 2005, remains the current version and is supported by virtually every enterprise identity platform.

"SAML is the duct tape of enterprise identity. It is not elegant, but it works, it is everywhere, and it has been battle-tested for twenty years." -- Vittorio Bertocci, former Principal Architect at Auth0

History and Versions

SAML was developed by the OASIS (Organization for the Advancement of Structured Information Standards) Security Services Technical Committee. It was the first widely adopted standard for federated identity on the web.

SAML 2.0 was a major revision that unified three competing federation specifications: SAML 1.1, the Shibboleth project (from the academic/research community), and the Liberty Alliance ID-FF (from the telecommunications industry). This convergence established SAML 2.0 as the universal enterprise SSO standard.

Core Concepts

Identity Provider vs. Service Provider

SAML defines two primary roles in the authentication process:

The IdP and SP establish a trust relationship before SSO can function. This involves exchanging SAML metadata -- XML documents containing each party's entity ID, endpoints, certificates, and supported bindings. The SP trusts the IdP to properly authenticate users, and the IdP trusts the SP to be a legitimate relying party.

SAML Assertions

A SAML assertion is an XML document issued by the IdP that contains statements about a subject (typically a user). There are three types of statements:

• Authentication Statement: Declares that the subject was authenticated by the IdP at a specific time using a specific method (e.g., password, multi-factor, certificate). This is the core of SSO.
• Attribute Statement: Provides attributes about the subject -- email address, name, group memberships, role, department, or any custom attribute the SP needs for authorization or personalization.
• Authorization Decision Statement: Declares whether the subject is permitted or denied access to a specific resource. Rarely used in practice; authorization is typically handled by the SP based on attributes.

Protocols and Bindings

SAML separates the logical protocol (what messages are exchanged) from the bindings (how messages are transported):

SAML Protocols define request-response message pairs:

• Authentication Request Protocol: SP requests the IdP to authenticate a user (AuthnRequest)
• Single Logout Protocol: Coordinated logout across all SPs
• Artifact Resolution Protocol: Resolve small tokens (artifacts) into full SAML messages
• Name Identifier Management Protocol: Change the identifier used for a user

SAML Bindings define transport mechanisms:

SSO Authentication Flow

The most common SAML SSO flow is the SP-Initiated SSO with HTTP POST binding:

1. The user attempts to access a protected resource on the Service Provider
2. The SP determines the user is not authenticated and generates a SAML AuthnRequest
3. The SP redirects the user's browser to the Identity Provider's SSO endpoint, carrying the AuthnRequest (typically via HTTP Redirect binding)
4. The IdP receives the AuthnRequest and authenticates the user (login page, MFA, or existing session)
5. The IdP constructs a SAML Response containing one or more assertions with authentication and attribute statements
6. The IdP digitally signs the response and/or assertion using its private key
7. The IdP sends the SAML Response to the user's browser via an auto-submitting HTML form (HTTP POST binding) targeting the SP's Assertion Consumer Service (ACS) URL
8. The SP receives the response, validates the XML signature using the IdP's certificate, checks conditions (audience, timestam