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, timestamps, replay), and extracts the user's identity and attributes
9. The SP creates a local session and grants the user access to the requested resource

IdP-Initiated SSO is also supported, where the user starts at the IdP (e.g., an enterprise portal) and selects the application to access. The IdP sends an unsolicited SAML Response directly to the SP. While simpler, IdP-initiated SSO is more vulnerable to certain attacks because the SP cannot correlate the response to a request it generated.

SAML Assertion Structure

A SAML assertion is an XML document with a well-defined structure. Key elements include:

• Issuer: The entity ID of the IdP that created the assertion
• Subject: The user identified by the assertion (NameID), along with subject confirmation data
• Conditions: Validity constraints including NotBefore/NotOnOrAfter timestamps and AudienceRestriction (which SPs may accept this assertion)
• AuthnStatement: When and how the user authenticated (AuthnInstant, SessionIndex, AuthnContext)
• AttributeStatement: Key-value pairs of user attributes
• Signature: XML Digital Signature over the assertion or response

The NameID is the identifier for the user. Common formats include:

Security Considerations

SAML's XML-based design introduces several attack vectors that implementers must carefully address:

XML Signature Wrapping (XSW): One of the most critical SAML vulnerabilities. An attacker manipulates the XML structure to move the signed element within the document and inject a malicious unsigned element that the SP processes instead of the signed one. Multiple variants of this attack have been demonstrated against major SAML implementations. Defense requires strict schema validation, ensuring the SP processes only the signed element, and using libraries that specifically handle signature wrapping attacks.

Assertion Replay: An attacker captures a valid SAML assertion and replays it to gain access. Defenses include enforcing short validity windows (NotBefore/NotOnOrAfter), tracking assertion IDs to detect duplicates (one-time use), and using TLS to prevent interception.

Man-in-the-Browser: Since SAML assertions pass through the user's browser (in the POST binding), a compromised browser or browser extension could extract and exfiltrate the assertion. The Artifact binding mitigates this by passing only a reference through the browser.

"The complexity of XML processing combined with the security sensitivity of authentication creates a dangerous attack surface. Every SAML implementation must be tested for signature wrapping, XXE, and assertion manipulation." -- Juraj Somorovsky, researcher who discovered multiple SAML vulnerabilities

XML External Entity (XXE): SAML messages are XML documents, and XML parsers that process external entities can be exploited to read server files, perform SSRF, or cause denial of service. SAML processors must disable external entity resolution entirely.

SAML vs. OAuth 2.0 vs. OpenID Connect

SAML, OAuth 2.0, and OpenID Connect (OIDC) are often mentioned together but serve different purposes:

When to use SAML: Enterprise SSO for web applications, integrating with existing SAML infrastructure, government and regulated environments that require SAML, legacy enterprise SaaS applications.

When to use OIDC: Modern web and mobile applications, API authorization combined with authentication, consumer-facing applications, new implementations without existing SAML infrastructure.

Many organizations use both: SAML for legacy enterprise applications and OIDC for newer services. Identity platforms like Okta and Azure AD support both protocols simultaneously, allowing organizations to choose per application.

Implementation and Deployment

Deploying SAML SSO involves configuring both the Identity Provider and Service Provider:

IdP Configuration:

• Create an application entry for the SP
• Configure the SP's Assertion Consumer Service (ACS) URL -- where the IdP sends the SAML Response
• Set the Entity ID (unique identifier for the SP)
• Define attribute mappings -- which user attributes to include in the assertion
• Configure NameID format and source attribute
• Assign users or groups who should have access

SP Configuration:

• Import the IdP's SAML metadata (or manually configure the IdP's SSO URL, Entity ID, and signing certificate)
• Configure attribute mapping from SAML attributes to local user properties
• Set up user provisioning (Just-in-Time creation, SCIM, or manual)
• Configure session management and logout

Popular SAML libraries include OneLogin's SAML toolkits (available for PHP, Python, Ruby, Java, .NET), Spring Security SAML (Java), python-saml, and passport-saml (Node.js).

Best Practices

• Always validate XML signatures rigorously; use well-maintained SAML libraries rather than custom XML processing
• Enforce short assertion validity windows (5 minutes or less) and implement assertion ID tracking for replay prevention
• Validate AudienceRestriction to ensure the assertion was intended for your SP
• Use HTTPS for all SAML endpoints; never accept assertions over plaintext HTTP
• Require assertions to be signed by the IdP; prefer signed assertions over signed responses alone
• Disable XML external entity (XXE) processing in your XML parser
• Prefer SP-initiated SSO over IdP-initiated to prevent unsolicited response attacks
• Implement Single Logout (SLO) to ensure sessions are terminated across all SPs when a user logs out
• Rotate IdP signing certificates regularly and support certificate rollover (dual-certificate validation)
• Test your implementation against known SAML attacks, including XML Signature Wrapping variants

For related authentication topics, see OAuth, JWT, Kerberos (for on-premises SSO), and two-factor authentication.

References

• Cantor, S., et al. (2005). "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0." OASIS Standard.
• Hughes, J., & Maler, E. (2005). "Security Assertion Markup Language (SAML) V2.0 Technical Overview." OASIS Committee Draft.
• Somorovsky, J., et al. (2012). "On Breaking SAML: Be Whoever You Want to Be." USENIX Security Symposium 2012.
• Grosse, E., & Upadhyay, M. (2013). "Authentication at Scale." IEEE Security & Privacy, 11(1), 15-22.
• OASIS. (2005). "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0." OASIS Standard.
• OASIS. (2005). "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0." OASIS Standard.
• Hardt, D. (2012). RFC 6749: The OAuth 2.0 Authorization Framework. IETF.
• Sakimura, N., et al. (2014). "OpenID Connect Core 1.0." OpenID Foundation.
• Morgan, R. L., et al. (2004). "Federated Security: The Shibboleth Approach." EDUCAUSE Quarterly, 27(4).
• NIST. (2017). SP 800-63C: Digital Identity Guidelines -- Federation and Assertions. NIST.