What Is SAML and How It Uses XML for SSO

Security Assertion Markup Language (SAML) is an open-standard framework that enables Single Sign-On (SSO) by passing authentication and authorization data between an identity provider and a service provider. This article explains the fundamentals of SAML, details how it utilizes XML-formatted assertions to securely transmit digital identities, and outlines the standard workflow of SAML-based authentication.

Understanding SAML and Its Core Roles

SAML is an XML-based protocol designed to facilitate federated identity management. Instead of requiring users to maintain separate credentials for every application, SAML delegates authentication to a centralized system.

The SAML ecosystem relies on three primary entities:

• Principal (User): The end user attempting to access a secure application or resource.
• Identity Provider (IdP): The central authority that authenticates the user’s identity (e.g., Okta, Microsoft Entra ID, Ping Identity) and issues cryptographic tokens.
• Service Provider (SP): The target application or service (e.g., Salesforce, Google Workspace, AWS) that relies on the IdP to verify user identities.

How SAML Leverages XML

SAML relies on eXtensible Markup Language (XML) as its message exchange format. XML provides a strictly structured, human-readable, and machine-parsable schema that allows disparate systems to communicate securely over standard internet protocols like HTTP.

XML is fundamental to SAML in three major ways:

1. Standardized Data Modeling: XML schemas define strict rules for how user identities, attributes, and session data must be represented, ensuring interoperability between different vendors.
2. XML Signatures (XMLDSig): To guarantee message integrity and authenticity, SAML messages and assertions are digitally signed using standard XML digital signatures. This ensures that assertions cannot be tampered with in transit and confirms they originated from a trusted IdP.
3. XML Encryption (XMLEnc): If sensitive user attributes must be protected from intermediaries (such as the user’s browser), SAML uses XML encryption to obscure specific elements or entire assertions.

The Structure of SAML Assertions

A SAML Assertion is an XML document generated by an IdP that asserts specific facts about a user. These assertions typically contain three types of statements:

• Authentication Statements: Confirm that the user successfully authenticated with the IdP, including the timestamp of authentication and the method used (e.g., password, multi-factor authentication).
• Attribute Statements: Provide specific metadata about the user, such as their email address, first name, last name, group memberships, or organizational role.
• Authorization Decision Statements: State whether the user is permitted to access a specific resource or execute a particular action.

Example Structure of an XML SAML Assertion

In an actual SAML exchange, an assertion includes standardized XML tags such as:

• <saml:Issuer>: Identifies the IdP that generated the assertion.
• <ds:Signature>: Contains the cryptographic signature verifying message integrity.
• <saml:Subject>: Identifies the principal (user), usually via a <saml:NameID> element.
• <saml:Conditions>: Specifies validity constraints, including the NotBefore and NotOnOrAfter time windows to prevent replay attacks.
• <saml:AttributeStatement>: Holds individual <saml:Attribute> key-value pairs defining user properties.

The SAML SSO Authentication Workflow

The standard SP-initiated SAML flow operates through the user’s browser using HTTP redirects and POST requests:

1. Request for Access: The user attempts to access a protected application at the Service Provider.
2. Authentication Request: The SP generates an XML-formatted AuthnRequest and redirects the user’s browser to the Identity Provider.
3. User Verification: The IdP checks if the user has an active session. If not, it prompts the user for credentials (and MFA).
4. Assertion Generation: Once verified, the IdP constructs a SAML Response containing the signed XML assertion with the user’s identity and attributes.
5. Assertion Delivery: The IdP sends the SAML Response back through the user’s browser, which automatically submits an HTTP POST request containing the XML payload to the SP’s Assertion Consumer Service (ACS) URL.
6. Validation and Access: The SP verifies the XML signature using the IdP’s public certificate, parses the assertion conditions and attributes, establishes an application session, and grants access to the user.