Security Assertion Markup Language (SAML) is an open, XML-based framework for exchanging authentication and authorization data between security domains—most commonly, between an identity provider (IdP) and a service provider (SP). SAML is a protocol, not a product or feature, designed to address the challenge of federated authentication and enable Single Sign-On (SSO) across disparate systems and organizations. It emerged to provide a standardized way for one system to tell another, “This user has been authenticated and here are their attributes,” without sharing passwords or reimplementing low-level directory authentication.
Originally developed in response to the need for secure and interoperable cross-domain authentication, SAML found widespread adoption in the early 2000s and remains foundational in enterprise SSO and federated identity architectures. Its primary adopters include enterprises, SaaS vendors, directory administrators, and anyone needing to bridge identity silos or delegate user authentication at scale.
Core SAML Components: Actors and Messages
A SAML ecosystem involves several specialized actors and message types:
- Identity Provider (IdP): The authority responsible for authenticating users. It manages the user’s credentials and produces SAML assertions. Organizations typically use an IdP backed by a corporate directory—often LDAP-based, such as Active Directory.
- Service Provider (SP): The application or service the user wants to access. The SP trusts assertions from the IdP and uses these to make access decisions.
- Principal: The user (or application) seeking access.
- SAML Assertion: A signed XML document produced by the IdP and delivered to the SP. The assertion conveys information about the user, such as their identity (authentication), group membership, or authorizations.
A typical SAML interaction begins when the principal requests access to a protected resource (SP), which in turn seeks an assertion from the IdP confirming the principal’s authentication and relevant attributes.
How SAML Authentication and SSO Work
SAML’s most common implementation pattern is the Web Browser SSO Profile, which enables SSO across domains. The sequence flows as follows:
- Access Request: The user attempts to access a resource on the service provider (SP).
- Authentication Request: The SP generates a SAML authentication request and redirects the user's browser to the IdP.
- User Authentication: The IdP authenticates the user (using its own methods—often LDAP or Active Directory).
- Assertion Issue: Upon successful authentication, the IdP generates a signed SAML assertion, packaging claims about the user.
- Assertion Delivery: The SAML assertion is returned to the browser, which delivers it to the SP, typically via a HTTP POST form.
- Verification and Access: The SP validates the assertion’s signature and parameters, checks if it trusts the IdP, and if all checks pass, grants access to the user.
Throughout this flow, the browser acts as an agent transporting security tokens between IdP and SP, but does not interpret or modify the assertions.
Types of SAML Assertions and Their Purposes
SAML assertions are core protocol elements, encoded as XML and digitally signed. Assertions can contain several types of statements, each serving a distinct purpose:
- Authentication Assertion: Confirms that a specific principal was authenticated by the IdP at a particular time using a specified method. For example, it may declare, “Alice authenticated at 12:01 using password.”
- Attribute Assertion: Shares additional information about the user, such as group memberships, department, or roles. For example, “Alice’s email is alice@example.com; Alice is in the ‘admins’ group.”
- Authorization Decision Assertion: States whether the user is permitted to access a specific resource or perform an action. For example, “Alice is allowed to update record #42.”
Notably, while SAML transports attributes and potential authorization statements, enforcement of authorization is always the responsibility of the SP or downstream services.
SAML and Directory Integration (LDAP, Active Directory)
SAML does not replace LDAP or directory infrastructure—it complements them. Instead of directly performing authentication against LDAP or Active Directory, the service provider delegates trust to the IdP, which typically authenticates users against a local directory service.
In practice, a SAML IdP might authenticate users by querying an LDAP directory, such as Active Directory. Once authenticated, the IdP formulates a SAML assertion containing user identity and directory-sourced attributes. This assertion is submitted to the SP, which leverages it for access control and personalization, all without direct SP-to-directory connectivity.
This pattern enables the decoupling of enterprise user management (via LDAP or Active Directory) from application authentication, while supporting secure, cross-organization SSO and centralized identity governance.
SAML in the Context of Federated Identity and SSO
SAML was designed to enable federated identity: a setup where independent domains (companies, departments, or services) trust each other's authentication without requiring password synchronization or credential duplication.
By relying on assertions from a trusted IdP, different organizations or business units can federate their directories and provide SSO to shared services. For example, two companies working together on a SaaS platform may each run their own IdP, federate trust, and thus allow seamless user access while each IdP still authenticates its own users.
It’s critical to note that SAML is a protocol for implementing SSO—but it is not itself SSO. SSO is the user experience; SAML is one of several protocols (others include OAuth2 and OpenID Connect) that make SSO possible.
SAML vs. SSO, OAuth, and OpenID Connect
A common misconception is that SAML and SSO are synonymous. In reality, SAML is a standard protocol for exchanging authentication and attribute statements, while SSO is an authentication feature or user experience. SSO can be implemented in many ways—SAML is just one, though it remains the dominant protocol in enterprise web SSO.
Comparing SAML with OAuth 2.0 and OpenID Connect (OIDC):
- SAML vs SSO: SAML is a protocol for SSO; it is not the whole SSO experience.
- SAML vs OAuth 2.0: OAuth focuses on delegated authorization for APIs (“let this app access my data”), not authentication or identity. SAML is about exchanging identity and authentication information.
- SAML vs OpenID Connect (OIDC): OIDC, built atop OAuth 2.0, serves modern authentication use cases—especially for mobile and SPA (single-page application) clients—by issuing simpler JSON-based tokens. SAML remains widely used for browser-based enterprise SSO, while OIDC/OAuth are more common for APIs and cloud applications.
An organization may prefer SAML when integrating with legacy or enterprise-grade SaaS offerings, or when an existing directory can act as the IdP. OAuth and OIDC are well-suited for new, mobile-first, or API-driven architectures.
Security Considerations and Protocol Limitations
SAML was designed with robust security properties, but real-world deployments must account for several risks and protocol limitations:
- Message Signing: SAML assertions and requests are digitally signed, typically using X.509 certificates, ensuring message integrity and authenticity.
- Timeliness: Assertions include timestamps and validity intervals; SPs must reject expired or replayed assertions.
- Replay Protection: Assertion identifiers and security headers help SPs recognize and reject duplicate or replayed assertions.
- Trust Management: Trust between IdPs and SPs is established and maintained through out-of-band configuration of certificates and metadata; misconfiguration can lead to security gaps.
- Vulnerabilities: Common implementation mistakes—such as failure to validate signatures, mishandled redirects, or misapplied trust—can undermine the protocol’s security.
SAML was originally designed for web browser flows, and while extended for non-HTTP scenarios, it is more complex and less natural for modern, lightweight, or API-centric application stacks.
The Role of SAML in Modern Identity Architecture
SAML 2.0, though decades old, remains essential for enabling federated identity and SSO in enterprise environments, especially where cross-domain, multi-organizational, or legacy system integration is required. Its protocol-driven approach separates authentication from application logic, with the IdP acting as a “bridge” between directories like LDAP and application SPs.
SAML is not obsolete; thousands of organizations rely on it for secure SSO, regulatory compliance, and scalable identity federation. However, its XML-based structure and emphasis on browser-driven flows often make newer alternatives like OAuth 2.0 and OIDC more attractive for cloud-native, mobile, or modern web application use cases.
For developers and identity architects, SAML provides a standards-grounded mechanism to federate authentication, integrate with directories, and securely transport identity data. Understanding its architecture, strengths, and boundaries is key to designing and troubleshooting robust authentication and directory integrations.
Sources:
- RFC 7522: Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
- RFC 6595: A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML)
- draft-hodges-saml-lsso-01: SAMLv2 Lightweight Web Browser SSO Profile
- RFC 7773: Authentication Context Certificate Extension
- RFC 7832: Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases