SAML 2.0

What is SAML 2.0?

SAML 2.0 is a standard for exchanging authentication and authorization data between domains. It enables Single Sign-On (SSO) across different services and applications, allowing users to authenticate once and access multiple resources without re-entering their credentials. SAML 2.0 is widely used in enterprise environments, cloud services, and federated identity systems to establish trust between identity providers and service providers.

SAML uses XML-based messages to communicate authentication and authorization information between the identity provider (IdP) and the service provider (SP). The protocol specifications are defined by the OASIS Security Services Technical Committee, ensuring interoperability and security across different implementations, and it consists in a series of PDF documents that defines the protocol:

• Core specification: Defines the basic concepts and elements of SAML.
• Bindings: Describes how SAML assertions and protocols are mapped to standard messaging or communication protocols.
• Profiles: Defines specific use cases and requirements for SAML implementations.
• Metadata: Specifies the metadata format for SAML entities.
• Conformance: Outlines the requirements for SAML 2.0 conformance.

Having the specifications in PDF formats means that it is not always easy to find the appropriate information in multiple PDF files. A list of all the main specification PDFs can be found in this index page and here.

How does SAML 2.0 work?

Stablishing Trust between Identity Provider and Service Provider

Both the identity provider (IdP) and the service provider (SP) must establish trust before exchanging authentication and authorization data. This trust is established through metadata exchange. SAML Metadata which contains information about the IdP and SP, such as X.509 certificates, endpoints, and supported protocols. The metadata is exchanged between the IdP and SP, allowing them to verify each other’s identity and capabilities.

When configuring SAML 2.0, the IdP and SP typically exchange metadata files that contain information about each other. The metadata will contain the necessary information about the identity provider and service provider, such as:

• EntityID: A unique identifier for the IdP or SP.
• Endpoints: URLs for different services, such as authentication and logout.
• Public keys: Used for signing and encrypting messages.
• Supported protocols: Describes the SAML profiles and bindings supported by the entity.
• Certificates: Public keys used for verifying signatures and encrypting data. Typically, X.509 certificates are used.
• etc…

Authentication Flow

SAML 2.0 supports two main authentication flows: SP-initiated and IdP-initiated.

SP-Initiated Flow

In the SP-initiated flow, the user attempts to access a service provided by the SP. The following steps outline the SP-initiated flow:

sequenceDiagram
    participant User
    participant SP as Service Provider
    participant IDP as Identity Provider
    
    User->>SP: Request access to resource
    SP->>User: Generate SAML Request with RelayState, redirect to IDP
    User->>IDP: Forward SAML Request
    IDP->>IDP: Verify SAML Request
    IDP->>User: Authenticate and generate SAML Response with RelayState
    User->>SP: Forward SAML Response
    SP->>SP: Verify SAML Response
    SP->>User: Grant access to resource

1. User requests access to a resource on the SP.
2. SP generates a SAML authentication request (AuthnRequest) and includes a RelayState for maintaining application state. The SP redirects the user’s browser to the IDP with the SAML request.
3. IDP receives the AuthnRequest and verifies its authenticity and integrity. This typically involves checking the request’s signature and ensuring it’s from a trusted SP.
4. IDP authenticates the user. This step may involve presenting a login form where the user enters credentials.
5. IDP generates a SAML response (Assertion) indicating the authentication result. This response includes an assertion about the user’s identity and possibly attributes.
6. IDP includes the original RelayState in the response to preserve application state.
7. SP receives the SAML Response and verifies its authenticity and integrity. This involves checking the response’s signature and ensuring it’s from a trusted IDP.
8. SP grants access to the user based on the SAML Assertion. The SP may initiate a session for the user.

IdP-Initiated Flow

In the IdP-initiated flow, the user is authenticated by the IdP and then redirected to the SP. The following steps outline the IdP-initiated flow:

sequenceDiagram
    participant User
    participant IDP as Identity Provider
    participant SP as Service Provider

    User->>IDP: Access IDP portal and authenticate
    IDP->>User: User selects SP
    IDP->>User: Generate SAML Response with RelayState for SP
    User->>SP: Forward SAML Response
    SP->>SP: Verify SAML Response
    SP->>User: Grant access to resource

1. User accesses IDP portal and is authenticated.
2. User selects a service (SP) from the IDP portal.
3. IDP generates a SAML Response (Assertion) for the selected SP. This response is unsolicited, meaning it was not preceded by an AuthnRequest from the SP.
4. The SAML Response includes an assertion about the user’s identity and possibly attributes. The IDP also includes a RelayState if necessary to maintain application state.
5. SP receives the SAML Response and verifies its authenticity and integrity. The SP ensures the response is from a trusted IDP and checks the signature.
6. SP grants access to the user based on the SAML Assertion. The SP may initiate a session for the user.

Useful tools and resources

• SAML Tool: SAML Tool: An online tool for encoding and decoding SAML messages.
• SAML Tracer - Firefox Extension: SAML Tracer: A Firefox add-on for viewing and debugging SAML messages.
• SAML Tracer - Chrome Extension: SAML Chrome Extension: A Chrome extension for viewing and debugging SAML messages.
• SAML Schema Navigation: SAML Schema Navigation: A list of SAML schema elements and their definitions.

SAML 2.0 vs. OIDC

SAML 2.0 and OpenID Connect (OIDC) are both protocols used for authentication and authorization, but they have different use cases and design philosophies.

Feature	SAML 2.0	OIDC (OpenID Connect)
Message Format	Uses XML-based messages for communication.	Uses JSON-based messages, which are more lightweight and easier to parse, suitable for modern web applications.
Complexity	More complex and heavyweight, requiring extensive configuration and setup.	Simpler and more streamlined, making it suitable for a wide range of applications, including lightweight ones.
Use Cases	Predominantly used in enterprise environments and federated identity systems.	Widely adopted in consumer-facing applications, including mobile and web apps.
Profiles	Offers multiple profiles for various use cases, including Web Browser SSO and Single Logout.	Primarily focuses on a single profile that encompasses both authentication and authorization.
Security	Provides strong security features suitable for enterprise applications.	Integrates modern security practices by leveraging OAuth 2.0 and JWT tokens, enhancing overall security.
Adoption	Remains prevalent in legacy systems and enterprises with complex federated identities.	Increasingly popular in modern web development due to its simplicity and ease of integration with web services.
Extensibility	Offers a degree of extensibility but can be cumbersome due to its complexity.	Highly extensible and flexible, allowing for customization to meet specific application requirements.
Mobile Support	Capable of supporting mobile applications but may require additional setup.	Offers superior support for mobile and native applications, making it ideal for mobile authentication scenarios.
Token Format	Utilizes XML-based assertions to convey information about the user.	Uses JWT tokens, which are compact and efficient for transmitting user identity information.