Introduction to SAML

What is SAML?

SAML, which stands for Security Assertion Markup Language, is an XML-based open standard for exchanging authentication and authorization data between different parties. Primarily, it facilitates communication between an Identity Provider (IdP) and a Service Provider (SP) . Imagine you have one key (your login credentials) that unlocks multiple doors (different web applications) – SAML is the technology that makes this possible, enabling Single Sign-On (SSO).

The core purpose of SAML is to allow users to authenticate once with an IdP and then access multiple independent web applications or services without needing to log in separately to each one. This centralized approach simplifies the user experience and enhances security by reducing the number of credentials a user needs to manage.

Why is SAML Important?

• Single Sign-On (SSO): The most prominent use case. Users log in once to access many services.
• Federated Identity: Allows organizations to securely share identity information across different security domains, enabling collaborations and access to external services using existing corporate identities.
• Standardization: Provides a standardized, XML-based way for IdPs and SPs to communicate authentication and authorization information.
• Decoupling Authentication: Service Providers don't need to manage user credentials directly; they rely on the trusted Identity Provider for authentication.

Core Concepts: Components

Understanding SAML requires familiarity with its key players and elements.

Key Roles (SAML Providers):

• Identity Provider (IdP): This entity is responsible for authenticating the user (verifying their identity) and issuing SAML Assertions containing identity and authorization information to Service Providers. Examples include Okta, Azure AD, FortiAuthenticator, or a custom corporate authentication service. The IdP manages user credentials and authentication methods (like passwords or MFA).
• Service Provider (SP): This is the application or service that the user wants to access. The SP relies on the IdP to authenticate the user. It receives and validates SAML Assertions from the IdP to grant access. Examples include Salesforce, VPN gateways, firewalls, or custom web applications.
• Principal (User Agent): Typically, this is the end-user's web browser. The browser acts as an intermediary, facilitating redirects and transmitting SAML messages (Requests and Responses) between the SP and the IdP. The SP and IdP usually do not communicate directly in standard web SSO flows.

Basic relationship between SAML components.

Core Concepts: Assertions

A SAML Assertion is the core piece of information exchanged in SAML. It's an XML document generated and signed by the IdP that "asserts" claims about the authenticated user (the subject) to the SP. Think of it as a digitally signed statement from the IdP vouching for the user's identity and potentially other attributes.

Assertions typically contain:

• Issuer: Identifies the IdP that created the assertion.
• Subject: Identifies the user (principal) the assertion is about (e.g., using a NameID).
• Conditions: Specifies the validity period (NotBefore, NotOnOrAfter) and intended audience (AudienceRestriction) for the assertion.
• Statements: These convey specific information about the subject.
• Signature: A digital signature from the IdP ensures the assertion's authenticity and integrity.

Types of Assertion Statements:

1. Authentication Statement: Asserts that the user was authenticated by a specific method at a particular time.
2. Attribute Statement: Contains specific attributes (pieces of information) about the user, such as email address, name, roles, or group memberships. The SP uses these attributes for authorization or personalization.
3. Authorization Decision Statement: Indicates whether the user is permitted to access a specific resource (though less commonly used in basic SSO, more for specific authorization scenarios).

An assertion might contain multiple statement types. For example, a typical SSO assertion includes both an Authentication Statement and an Attribute Statement.

Core Concepts: Bindings

SAML Bindings define how SAML protocol messages (like Authentication Requests and Responses containing Assertions) are transported over underlying communication protocols, most commonly HTTP. They specify the mechanism for transferring these XML-based messages between the SP, IdP, and the user agent (browser).

Common SAML 2.0 Bindings include:

• HTTP Redirect Binding:
  • Transmits SAML messages within URL parameters during an HTTP redirect (GET request).
  • Often used for sending SAML Authentication Requests from the SP to the IdP because requests are typically small.
  • Messages are usually deflated (compressed) and base64-encoded.
  • Limitation: URLs have length limits (around 2048 characters depending on the browser), making this binding unsuitable for large messages like SAML Responses which contain assertions and signatures.
• HTTP POST Binding:
  • Transmits SAML messages within an HTML form that is automatically submitted using JavaScript or a meta tag (POST request).
  • The SAML message is base64-encoded and placed in a hidden form field (e.g., `SAMLRequest` or `SAMLResponse`).
  • Suitable for larger messages, making it the common choice for sending SAML Responses (containing assertions) from the IdP back to the SP.
• HTTP Artifact Binding:
  • Transmits a small reference, called an "artifact," via the browser (using Redirect or POST).
  • The receiving party then uses this artifact to fetch the actual SAML message directly from the issuer via a back-channel connection (typically using SOAP over HTTP).
  • Benefit: Keeps the potentially large and sensitive SAML message content out of the browser, enhancing security by reducing the attack surface.
  • Requirement: Requires direct network connectivity between the SP and IdP for the back-channel artifact resolution.
  • Can be used for Requests, Responses, or both (Double Artifact Binding).
• SOAP Binding: Uses SOAP (Simple Object Access Protocol) for direct server-to-server communication, often used in back-channel scenarios like artifact resolution or specific web services profiles.

Core Concepts: Protocols & Profiles

SAML defines specific request/response protocols and profiles that combine protocols, bindings, and assertions to achieve specific use cases.

SAML Protocols

These define the structure of the XML messages exchanged:

• Authentication Request Protocol: Used by an SP to request an assertion from an IdP. The message is typically ` `.
• Single Logout Protocol (SLO): Allows a user to log out from all SP sessions initiated via the IdP with a single action. Involves ` ` and ` ` messages.
• Assertion Query and Request Protocol: Allows an SP to request assertions directly from an IdP under certain conditions.
• Artifact Resolution Protocol: Used with the HTTP Artifact binding, where the recipient of an artifact sends an ` ` request to the issuer to retrieve the actual SAML message.

SAML Profiles

Profiles describe how to use SAML components together for a specific scenario:

• Web Browser SSO Profile: This is the most common profile, defining how SAML enables SSO for browser-based applications. It details how Authentication Requests and Responses are exchanged using bindings like HTTP Redirect and HTTP POST, involving the user's browser as an intermediary. Both SP-initiated and IdP-initiated flows fall under this profile.
• Enhanced Client or Proxy (ECP) Profile: Designed for clients other than standard web browsers, allowing them to interact with SPs and IdPs.
• Identity Provider Discovery Profile: Defines how an SP can discover the user's appropriate IdP when multiple IdPs are available.
• Single Logout Profile: Defines how the Single Logout Protocol is used to terminate sessions across the IdP and multiple SPs.
• Assertion Query/Request Profile: Defines how the Assertion Query and Request Protocol is used.

Core Concepts: Metadata

SAML Metadata is an XML document that describes a SAML entity (either an IdP or an SP). Its purpose is to facilitate the establishment of trust and interoperability between SAML entities by exchanging configuration information in a standardized format. Before metadata, configuration was often manual and proprietary.

Metadata typically includes details such as:

• EntityID: A unique identifier for the SP or IdP (often a URL).
• Role Descriptors: Specify whether the entity acts as an IdP (`IDPSSODescriptor`) or SP (`SPSSODescriptor`).
• Endpoints (URLs): Locations where SAML messages should be sent for specific bindings, such as:
  • Assertion Consumer Service (ACS) URL (for SPs): Where the IdP sends SAML Responses.
  • Single Sign-On (SSO) Service URL (for IdPs): Where the SP sends SAML Requests.
  • Single Logout Service (SLO) URL (for both).
  • Artifact Resolution Service (ARS) URL (for Artifact binding).
• Binding Support: Indicates which SAML bindings (e.g., HTTP-POST, HTTP-Redirect, Artifact) are supported at each endpoint.
• Keys and Certificates: Public keys used for signing SAML messages or encrypting assertions. The SP needs the IdP's public certificate to validate signatures on assertions.
• NameID Formats Supported: Specifies the formats the entity supports for identifying the user (e.g., transient, persistent, email address).
• Attribute Information: May list attributes the IdP can provide or the SP requires (` `).
• Contact Information: Technical and support contacts for the entity.
• UI Information: Optional display names, logos, descriptions for user interfaces (like IdP selection screens).

By exchanging metadata files, an IdP and SP can configure their systems to communicate securely and correctly without extensive manual configuration. Identity Providers often allow SPs to be configured by importing the SP's metadata file, and vice-versa. Tools exist to generate metadata based on configuration.

SAML Flows: SP-Initiated SSO

Service Provider (SP)-initiated Single Sign-On is the most common SAML flow. It begins when a user tries to access a resource or log in directly at the Service Provider's application.

The typical steps are as follows:

1. User Accesses SP: The user navigates their browser to the SP application (e.g., clicks a "Login" button or accesses a protected page).
2. SP Generates SAML Request: The SP determines the user is not authenticated and needs authentication via SAML. It creates a SAML Authentication Request (` `) message. This request identifies the SP (Issuer) and specifies where the IdP should send the response (AssertionConsumerServiceURL).
3. SP Redirects to IdP: The SP redirects the user's browser to the IdP's Single Sign-On (SSO) endpoint, sending the SAML Request (usually via HTTP Redirect binding).
4. IdP Authenticates User: The IdP receives the SAML Request. If the user doesn't already have an active session with the IdP, the IdP prompts the user to authenticate (e.g., enter username/password, use MFA).
5. IdP Generates SAML Response: After successful authentication, the IdP generates a SAML Response (` `) containing a signed SAML Assertion. The assertion includes information about the authenticated user (like NameID and attributes) and confirms the authentication event.
6. IdP Sends Response to SP (via Browser): The IdP sends the SAML Response back to the user's browser. The browser is then typically instructed (via HTTP POST binding) to forward this response to the SP's Assertion Consumer Service (ACS) URL (which was specified in the original request or configured via metadata).
7. SP Validates Response: The SP receives the SAML Response at its ACS endpoint. It verifies the IdP's digital signature on the assertion using the IdP's public key, checks the assertion's validity conditions (timestamps, audience), and extracts the user's identity and attributes.
8. SP Grants Access: If the validation is successful, the SP creates a local session for the user and grants them access to the requested resource or application dashboard.

SP-Initiated SAML SSO Flow (using Redirect/POST bindings).

SAML Flows: IdP-Initiated SSO

Identity Provider (IdP)-initiated Single Sign-On starts when the user is already authenticated with the IdP, typically through a central dashboard or portal provided by the IdP. The user then clicks a link or icon representing the Service Provider they wish to access.

The flow generally proceeds as follows:

1. User Authenticates with IdP: The user logs into the IdP's portal or system.
2. User Selects SP: From the IdP's interface, the user clicks a link or button corresponding to the target SP application.
3. IdP Generates SAML Response: The IdP generates a SAML Response containing a signed assertion for the user, specific to the selected SP. Unlike the SP-initiated flow, there is no preceding SAML Request from the SP.
4. IdP Sends Response to SP (via Browser): The IdP sends this unsolicited SAML Response to the user's browser, typically instructing the browser (via HTTP POST) to deliver it to the SP's Assertion Consumer Service (ACS) URL. A `RelayState` parameter might be included to direct the user to a specific page within the SP.
5. SP Validates Response: The SP receives the SAML Response at its ACS endpoint. It validates the signature and assertion just like in the SP-initiated flow.
6. SP Grants Access: If the validation is successful, the SP creates a session for the user and grants access, potentially redirecting them based on the `RelayState` value.

IdP-Initiated SAML SSO Flow.

Security Considerations

While SAML provides a robust framework for federated identity, improper implementation or configuration can lead to vulnerabilities.

Common Vulnerabilities and Defenses:

• Missing Signature Verification: The SP might receive a signed assertion but fail to validate the signature, allowing attackers to forge assertions. This is often a configuration error.
  • Defense: Always configure the SP to validate the signature on assertions (and potentially the entire response) using the IdP's trusted public key.
• Signature Exclusion / XML Signature Wrapping (XSW): Attackers manipulate the XML structure to trick the parser into validating the signature against different content than intended, potentially injecting malicious data or changing user identity/permissions.
  • Defense: Use robust XML parsing libraries that are resistant to XSW. Validate that the signature covers the intended parts of the assertion. Ensure all assertions are signed.
• Replay Attacks: An attacker intercepts a valid SAML assertion and resends it later to gain unauthorized access.
  • Defense: SPs must strictly enforce the validity period specified in the assertion's `Conditions` element (`NotBefore`, `NotOnOrAfter`). Use short assertion lifetimes. Maintain a cache of recently processed assertion IDs (`ID` attribute) to prevent reuse within their validity window.
• XML External Entity (XXE) Injection: If the SP's XML parser is misconfigured, an attacker might inject malicious external entities into the SAML XML, potentially leading to information disclosure or server-side request forgery (SSRF).
  • Defense: Configure XML parsers securely to disable external entity processing. Use up-to-date libraries.
• Weak Encryption / Missing Encryption: Sensitive user attributes within an assertion might be sent unencrypted, exposing them if intercepted.
  • Defense: Encrypt assertions or specific attributes containing sensitive data using the SP's public key. Ensure strong encryption algorithms are used.
• Insecure Bindings: Using HTTP instead of HTTPS allows eavesdropping. Passing sensitive data via Redirect binding might expose it in logs or browser history.
• Defense: Always use HTTPS for all communication. Prefer POST or Artifact binding for transmitting assertions.
• Open Redirect / RelayState Manipulation: If the `RelayState` parameter is not properly validated by the SP, an attacker might craft a malicious link that, after successful authentication, redirects the user to a phishing site.
  • Defense: Validate the `RelayState` value against a list of allowed URLs or ensure it's a relative path before redirecting the user.
• IdP-Initiated SSO Risks: As mentioned, IdP-initiated flows are inherently more susceptible to assertion replay as the SP doesn't have an initial request context.
  • Defense: Prefer SP-initiated flows where possible. If using IdP-initiated, enforce strict timestamp validation and potentially disallow responses without an `InResponseTo` attribute matching a known request.
• Cross-Tenant Email Validation Flaw: In multi-tenant SPs, failing to validate that the email address in the assertion belongs to the correct tenant could allow an attacker from one tenant to impersonate a user in another.
  • Defense: The SP must verify that attributes like email belong to the expected tenant context during user provisioning or login.

Benefits of Using SAML

Implementing SAML offers several advantages for organizations, users, and administrators:

• Improved User Experience: Single Sign-On (SSO) is the most significant benefit. Users log in once and gain access to multiple applications without re-entering credentials, saving time and reducing frustration.
• Enhanced Security:
  • Centralizes authentication at the IdP, allowing for consistent application of strong authentication policies (like MFA).
  • Reduces the number of passwords users need to manage, decreasing the risk of weak or reused passwords.
  • Credentials are typically only shared with the IdP, not directly with each SP, limiting exposure.
• Simplified Administration:
  • User provisioning and de-provisioning are managed centrally at the IdP. Access changes or revocation can be applied once and propagate to all connected SPs.
  • Reduces IT helpdesk workload related to password resets.
• Interoperability and Standardization: As an open standard, SAML enables integration between systems from different vendors.
• Federation Support: Facilitates secure collaboration and access sharing between different organizations (e.g., business partners, academic institutions) by allowing users to use their home organization's credentials to access resources elsewhere.
• Cost Reduction: Can lower costs associated with managing multiple user directories and handling password-related support requests.

SAML Diagrams

Visualizing SAML flows and component interactions can greatly aid understanding. Here are various diagrams representing SAML concepts using Mermaid syntax.

Sequence Diagram: SP-Initiated Flow (Detailed)

Detailed SP-Initiated SSO Flow using HTTP Redirect for Request and HTTP POST for Response.

Flowchart: Basic Authentication Decision

Simplified flowchart of the SAML authentication decision process.

Graph Diagram: Component Relationships

Relationships between core SAML components and metadata exchange.

State Diagram: User Session State (Simplified)

Simplified view of a user's authentication state during a SAML interaction.

Sequence Diagram: HTTP Artifact Binding Flow (Response Only)

SP-Initiated flow using HTTP Artifact Binding for the SAML Response. Note the back-channel communication (steps 10-11).

SAML Knowledge Quiz

Test your understanding of SAML concepts.