This is a series blog posts that deep dives into the world of SAML:
SAML 2.0 Explained in Simple Words - Part I: Intro and Overview
SAML 2.0 Explained in Simple Words - Part II: SAML Flows
SAML 2.0 Explained in Simple Words - Part III: SAML Model and Best Practices
In SAML 2.0 Explained in Simple Words - Part II, we look at the SAML operation at a detailed level to understand how the operation is done.
In this post, we will go through some more content.
SAML Concept abstracts what we have seen from SAML so far into four different layers, so that we can better visualize its concept model
Privacy part mentions some of the mechanisms that SAML supports for privacy control
Best practices tips are present for SAML deployment and operations
1. 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
1.1 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
1.2 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.
1.3 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 and 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
1.4 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 (details in SAML 2.0 Explained in Simple Words - Part II).
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
2. 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 mechanism that support deployment in privacy.
Identity Pseudonym - SAML supports pseudonym 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
3. Some Best Practices
3.1 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 time 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 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:
Assertion is included in the Response Message and signing the entire response message will guarantee the integrity of Assertion as well.
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.
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.
3.2 Encryption
SAML supports encryption for the messages as well. Since SAML Request usually doesn't have sensitive information, it's rare to encrypt SAML request.
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 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.
3.3 SAML Request Signature
In general, it is good practice to include signature in the SAML Request, so that the integrity of the request can be verified.
Sometimes, SP might have limitation generating signed SAML request. 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 scenario where ACS URL is dynamic or difficult to predict.
3.4 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 receiver to 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 identify 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.
4. Sum Up
In this post, we summarized the SAML Concept into a Profile, Bindings, Protocols, Assertions model, which will help to better understand the SAML mechanism. We also look at some privacy means that SAML can support. After that, we checked out some tips on SAML best practices.