Skip to content
Boston Identity
Contact

Chapter 12

SAML: A Further Look

Part II · IAM Core Concepts8 min read

In this chapter, we continue checking out SAML and concepts.

Key Points

  • SAML Core Components
    • Assertions: Security statements about a subject (e.g., user), issued by an entity like an IDP. These assertions convey authentication, attribute, and authorization information.
    • Protocols: Define the request/response interactions between SAML entities (e.g., Authentication Request Protocol, Single Logout Protocol).
    • Bindings: Specify how SAML messages are encoded and transmitted over communication channels (e.g., HTTP POST, HTTP Redirect).
    • Profiles: Combine assertions, protocols, and bindings to support specific use cases (e.g., Web Browser SSO Profile).
  • Important Profiles
    • Web Browser SSO Profile: The most common profile, enabling SSO within web browsers.
    • Single Logout Profile: Facilitates logging out of multiple applications through a single action.
    • Artifact Resolution Profile: (Rarely used) Allows retrieval of SAML messages using artifacts.
  • Common Bindings
    • HTTP POST Binding: The most widely used binding, transmitting SAML messages within HTTP POST requests.
    • HTTP Redirect Binding: Sends SAML messages as URL parameters in HTTP GET requests.
    • HTTP Artifact Binding: (Rarely used) Employs an artifact (an opaque identifier) to represent the SAML message, which is retrieved separately.
    • SOAP Binding: (Legacy) Uses the SOAP protocol for message exchange.
  • Key Protocols
    • Authentication Request Protocol: Used by SP to request user authentication from IDP.
    • Authentication Response Protocol: Used by IDP to respond to authentication requests with assertions.
    • Single Logout Protocol: Enables coordinated logout across multiple applications.
    • Metadata Exchange Protocol: Facilitates the exchange of metadata between SAML entities.
    • NameID Mapping Protocol: Defines how user identifiers are mapped between different SAML entities.
  • Assertions
    • Contain statements about a user's identity and security attributes.
    • Three types of statements:
      • Authentication Statements: Describe how the user was authenticated.
      • Attribute Statements: Provide specific attributes about the user.
      • Authorization Decision Statements: Specify what actions the user is authorized to perform.
  • Privacy and Security
    • Privacy Mechanisms:
      • Identity Pseudonyms: Allow the use of pseudonyms to protect user privacy.
      • Transient Identifiers: Generate unique identifiers for each session to prevent user tracking.
      • Assurance Levels: Define the level of confidence in user authentication.
    • Security Mechanisms:
      • TLS: Use TLS for all HTTP communication to ensure confidentiality and integrity.
      • Signatures: Mandate signing of SAML responses (and optionally assertions) to verify message integrity.
  • Best Practices
    • Assertion vs. Response Signing: Sign the entire SAML response for stronger security, even though signing only the assertion is permissible in some cases.
    • Encryption: Encrypt the SAML response to protect sensitive user data.
    • SAML Request Signature: Include signatures in SAML requests whenever possible to ensure request integrity.
    • Entity IDs and SAML IDs: Include entity IDs and unique SAML IDs in requests and responses to prevent message mix-ups and replay attacks.

SAML Concept

We can basically divide SAML into four different parts or layers.

  • Assertions - SAML Assertions are security information asserted by an entity party (e.g. IDP) in the form of statements about a subject
  • Protocols - SAML defines some request/response protocols
  • Bindings - SAML Bindings detail exactly how SAML messages can be sent/received underlying transport protocols
  • Profiles - SAML Profiles define how SAML assertions, protocols, and bindings are combined to provide interoperability in different usage scenarios
Diagram: SAML Concept

SAML Concepts

Profiles

SAML defines several Profiles and some of them are not actively being used today. The relevant ones are:

  • Web Browser SSO Profile - This is the most used Profile when SAML is present. It defines how SAML entities use the Authentication Request Protocol and SAML Response messages and assertions to achieve Single Sign-On with Browsers. It defines how messages are used in combination with HTTP Redirect, HTTP POST, and HTTP Artifact Bindings
  • Single Logout Profile - This is sometimes used. It defines how SAML Single Logout Protocol can be used with Browser SSO Profile and SOAP (legacy)
  • Artifact Resolution Profile - Rarely used. It defines how SAML entities can use the Artifact Resolution Protocol to retrieve the SAML message (e.g. IDP response) referred by an artifact

Bindings

SAML Bindings define how SAML messages are encoded, packaged, and transmitted over different communication channels. Some of the bindings are deprecated.

  • HTTP POST Binding - Most used. Transmit SAML messages through HTTP POST requests. SAML messages are encoded as XML documents and sent in the body of the POST request.
  • HTTP Redirect Binding - Transmit SAML messages through HTTP GET requests. SAML messages are encoded as URL parameters and sent in the query string of the redirect request.
  • HTTP Artifact Binding - Rarely used. Transmit SAML messages using a combination of HTTP and a separate messaging protocol. SAML messages are encoded as a small identifier called an artifact that is transmitted over HTTP, and the actual SAML message is retrieved by the recipient using a separate messaging protocol.
  • SOAP Binding - Legacy binding, not used today. This binding is used to transmit SAML messages over SOAP (Simple Object Access Protocol) using the SOAP message format.

Protocols

SAML defines some request/response protocols for operation.

  • Authentication Request Protocol - Used by a service provider (SP) to request authentication of a user from an identity provider (IdP)
  • Authentication Response Protocol - Used by an IdP to respond to a SAML authentication request with an assertion containing information about the user's identity
  • Single Logout Protocol - Allow logout of active sessions associated with a principal. The logout can be directly initiated by the user, or initiated by an IDP or SP on session timeout, administrator action, etc.
  • Metadata Exchange Protocol - Used to exchange metadata between SAML entities, including information about endpoints, certificates, and supported bindings
  • NameID Mapping Protocol - It defines how to map the identifier used by one SAML entity to the identifier used by another entity

Assertions

An assertion contains information about a user's identity and the security attributes associated with that identity, which is generated by an IDP in response to a SAML authentication request from a SP. SAML Assertions include several elements.

SAML defines three kinds of statements that it can carry:

  • Authentication Statements - Describe the means how the user is authenticated, e.g. authentication time
  • Attribute Statements - Specific attributes associated to a subject (user)
  • Authorization Decision Statements - Describe what the subject is entitled to do

Privacy and Security in SAML

With various regulations going-on, user privacy has become a determining factor for some organizations. SAML also supports a number of mechanisms that support deployment in privacy.

  • Identity Pseudonym - SAML supports pseudonyms for an identity between IDP and SP. This helps protect the user's privacy by preventing the service provider from collecting or storing their personal information
  • One-time Transient Identifier - A transient identifier (random opaque string) is generated as the subject identifier each time IDP sends response back to the SP, so that SP will NOT be able to recognize them as the same individual as might have previously visited
  • Assurance Level - Authentication Context mechanism allows a user to be authenticated at a sufficient assurance level for the resource requested

Just providing assertions may not be enough to ensure a secure system and some security mechanism is needed as well.

  • Use TLS for HTTP all the time
  • The IDP response is mandatory to be signed and signature verified by SP

Some Best Practices

Assertion Signing vs Response Signing

The signature for SAML Response can be at either Assertion level or the entire Message level or both.

OASIS's SAML Specification points out that TLS should be used at all times to maintain confidentiality and message integrity. The Assertion MUST be signed when HTTP POST binding is used, and MAY be signed if the HTTP-Artifact binding is used.

The reason that not the entire SAML Response message needs to be signed is because it is relying on TLS to maintain data integrity and prevent man-in-the-middle attack. When HTTP-Artifact is used, it is even safer as it is a back channel connection.

However, I would recommend always sign the entire SAML response message and optionally sign the Assertion part. The reasons are:

  1. Assertion is included in the Response Message and signing the entire response message will guarantee the integrity of Assertion as well.
  2. The OASIS standard was published in 2006 and Information Technology has evolved a lot since then. Signing Assertion plus HTTP with TLS could be good in the old days, but may not be sufficient in current time.
  3. Signing the entire message wouldn't put much overhead on the SAML flow

By signing the entire SAML Response message, it is guaranteed that the SAML message is not tampered.

Encryption

SAML supports encryption for the messages as well. Since SAML Requests usually don't have sensitive information, it's rare to encrypt SAML requests.

On the other hand, SAML Response could include some sensitive private information. In this case, it's better to encrypt the SAML response message so that even if the response message is intercepted, the information is not disclosed.

Note that encryption should be combined with other means like TLS for HTTP, Message Signature, and etc.

SAML Request Signature

In general, it is good practice to include signatures in the SAML Request, so that the integrity of the request can be verified.

Sometimes, SP might have limitations generating signed SAML requests. If no signature is present in SAML Request, in this case, the ACS URL presented in the SAML Request must have been pre-registered in the IDP. If the signature is present, depending on the IDP, the ACS URL in the request could be a new URL that is not pre-registered. This is helpful in some scenarios where ACS URL is dynamic or difficult to predict.

Include SAML ID in the Request and Response

It's common to include SP entityID and IDP entityID in the request and response. This will let the receiver verify the origin and target audience of the message and reject it if there is any mismatch.

Another important attribute is the ID which is a string uniquely identifying the SAML request. For example, ID="809707f0030a5d00620c9d9df97f627afe9dcc24" as below.

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="809707f0030a5d00620c9d9df97f627afe9dcc24" Version="2.0" ProviderName="SP test" IssueInstant="2014-07-16T23:52:45Z" Destination="http://idp.example.com/SSOService.php" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://sp.example.com/demo1/index.php?acs"\>

This ID should be included in the SAML response as well and the response should be rejected if there is any mismatch.