Reloading SAML : SAML Basics
During the last post, I discussed some of the practical use cases of SAML, within this post I will try to discuss a few basic concepts related to SAML.
Generally, we refer SAML as a one stranded but it has been evolved into a complex ecosystem with a number of technical specifications, however in the current post I limit to discuss some core specifications, we mainly focus on SAML Core ( Assertions and Protocols ) and SAML Bindings.
Following diagram illustrate the relationship among these specifications.
SAML technical overview document use following diagram to illustrate associations between the above specifications.
Before we further discuss these concepts we need to understand various actors participate in SAML based interactions. Basically SAML assumes two main actors.
Note that some of the SAML profiles re-define above roles and provide different names within the scope of a specific profile.
SAML Assertion
An Assertion is a set of security statements about a subject created by an Asserting Party (AP), in most common use cases it is about an individual.
There are 3 types of assertions are defined in SAML depends on their purposes.
1. Authentication statements
The asserting party use authentication statements to describe the approach used to authenticate the user (Subject) and authenticated time.
2. Attribute statements
Used to describe attributes above the authenticated user (Subject).
3. Authorization decision statements
Used to express something that the user entitled to perform, such as access a particular page etc.
Following diagrams further illustrate assertions supported in SAML core with their purposes.
SAML Protocols
These are the message formats that can be generated and can be used to exchange SAML assertions. There are 6 such protocols are defined in the SAML Core specification.
SAML Bindings
SAML does not define its own transport protocols instead of existing transport such as HTTP transport can be used to transmit SAML messages, SAML Binding specifies exact semantics to transmit SAML messages via other protocols. For an example a encode SAML message within HTTP POST request body or encode SAML message within the body of SOAP message etc.
Most of these bindings assume two roles called Requester and Responder, Requester is the entity requesting some services by sending a SAML request message and Responder is the entity that supply required information as a SAML response. Most of the cases Requester is identical to the Service Provider (SP) concept and Responder is identical to Identity Provider (IdP) but there are few exceptional cases as well.
Understanding RelayState
RelayState is a very important aspect of SAML standard, technically SAML requester can send a random string value to the SAML responder as RelayState and SAML responder must send this original RelayState value back to the SAML requester together with SAML response. Generally, this is an opaque reference value and used to keep some application-level context during the SAML invocation. As an example, assume a user requested a protected video content from an application, after successful authentication the application is supposed to return the requested video, in this case, opaque reference for requested video can be kept within RelayState parameter.
Each SAML binding specifically mentions whether it support for RelayState or not if supported binding also specify how to encode the RelayState value using underlying transport protocol and message format.
In the following section, we will look at each SAML binding in detail.
1. HTTP Redirect Binding
This approach uses HTTP Redirect ( 301, 302) as the transport mechanism and SAML messages are encoded as HTTP URL parameters. Generally, this binding assumes the presence of a user agent such as a web browser which can handle HTTP Redirects. It’s hard to use these messages with large SAML messages.
- A user tries to access a protected resource in an application, the application realized the user is not authenticated.
- The application sends HTTP redirect (302) back to the user’s browser. The Location HTTP header contains the endpoint URL for the SAML service and SAML request also encoded as with the URL.
- User’s browser follows the received HTTP redirect message and send HTTP GET message to the SAML service endpoint with the received SAML message.
- SAML responder receives the HTTP message at the service endpoint, process the received SAML message and respond accordingly.
Here are some of the important points about HTTP Redirect binding.
- RelayState is supported but should be limited to 80 bytes and it should be appended to the URL with “RelayState=value” format.
- The SAML request is first compressed using DEFLATE compression mechanism and then encoded using Base64 finally it again need to be URL encoded.
- For the request signing, it should use DSAWithSHA or RSAWithSHA algorithms ( we will discuss why we need to sign here).
- HTTP Cache should not be used with this binding.
- SAML processors should not use HTTP error codes instead SAML error coded need to be used.
Following are the URL parameter names supported in this binding.
- SAMLRequest — SAML request message
- RealyState — RealyState value
- SAMLEncoding — indicate the SAML encoding mechanism
- SigAlg — Signature algorithm identifier
- Signature — Base64 encoded signature value
Example of SAML redirect binding
2. HTTP POST Binding
Facilitates to transmit SAML messages as Base64 encoded HTML form parameters. Generally, this binding assumes the presence of a user agent such as a web browser which can handle HTTP Redirects. It’s hard to use these messages with large SAML messages.
- A user tries to access a protected resource in an application, the application realized the user is not authenticated.
- The application sends HTTP OK (200) back to the user’s browser with HTML form, SAML request is embedded within the HTML form as hidden input control. Generally, this response HTML form consists of JavaScript or similar scripting logic to auto-submit the form.
- User’s browser renders the HTML content received and auto-submission logic submits the HTML form with SAML request to the SAML service using HTTP POST.
- SAML responder receives the HTTP message at the service endpoint, process the received SAML message and respond accordingly.
Here are some of the important points about HTTP Redirect binding.
- RelayState is supported but should be limited to 80 bytes and it should be mentioned as hidden HTML form input with ‘RelayState’ name.
- The SAML request needs to be encoded using Base64 before transmit as HTML form input.
- HTTP Cache should not be used with this binding.
- SAML processors should not use HTTP error codes instead SAML error coded need to be used.
Following the support URL parameter names
- SAMLRequest — SAML request message in case of sending a request
- SAMLResponse — SAML response message in case of request of sending a response.
- RealyState — RealyState value
Example for SAML POST binding
3. HTTP Artifact Binding
In this binding SAML messages are transmitted via a user agent as an opaque reference value called ‘SAML Artifact. Any successful SAML message exchange consists of 2 steps as follows.
- The requestor sends SAML Artifact to the responder through a user agent, usually via HTTP POST or HTTP GET call, this is a front-channel invocation.
- The responder directly calls the requestor with the received SAML Artifact, the responder returns the SAML message related to the provided SAML Artifact to the responder within the response message. SOAP over HTTP is the widely used approach to perform this back-channel invocation.
According to SAML terminology this binding use request-response protocol and Artifact resolve protocol.
This binding is relatively slow because each SAML transmission is required to have multiple network calls but this is highly secure approach because original SAML messages are directly passed from the requestor to the requestor, only SAML message reference (Artifact) is exposed to the user agent.
Message interaction when HTTP POST is used
- A user tries to access a protected resource in an application, the application realized the user is not authenticated.
- The application sends HTTP OK (200) back to the user’s browser with HTML form, SAML Artifact is embedded within the HTML form as hidden input control. Generally, this response HTML form consists of JavaScript or similar scripting logic to auto-submit the form.
- User’s browser renders the HTML content received and auto-submission logic submits the HTML form with SAML Artifact to the SAML responder using HTTP POST.
- SAML responder process the SAML Artifact, validate and identify the issuer. Once the Artifact resolver endpoint of the requester is known to the responder, it sends a SAML ArtifactResolve message to the requester within a SOAP message body (SOAP over HTTP ).
- The requester process the ArtifactResolve message and return an ArtifactResponse message within the body section of the SOAP response message. The SAML request is embedded within ArtifactResolve message.
Message interaction when HTTP POST is used
- A user tries to access a protected resource in an application, the application realized the user is not authenticated.
- The application sends HTTP redirect (302) message back to the user’s browser. The Location HTTP header contains the endpoint URL for the SAML service and SAML Artifact also encoded as with the URL.
- User’s browser follows the received HTTP redirect message and send HTTP GET message to the SAML service endpoint with the received SAML Artifact.
- SAML responder process the SAML Artifact, validate and identify the issuer. Once the Artifact resolver endpoint of the requester is known to the responder, it sends a SAML ArtifactResolve message to the requester within a SOAP message body (SOAP over HTTP ).
- The requester process the ArtifactResolve message and return an ArtifactResponse message within the body section of the SOAP response message. The SAML request is embedded within ArtifactResolve message.
Following parameters are used for front-channel SAML Artifact transmission via HTTP.
For HTTP GET
- SAMLart URL parameter
- RelayState URL parameter
For HTTP POST
- SAMLart HTML form parameter
- RelayState HTML form parameter
Format of the SAML Artifact
SAML Artifact should have issuer identification, resistance to tampering and forgery, uniqueness, and compactness characteristics. Following diagram graphically illustrate the structure and purpose of SAML Artifact.
4. HTTP SOAP Binding
In this binding body section of the SOAP message is used to carry the SAML message, generally, HTTP is used as the transport level protocol for these SOAP messages. SOAP encoding, SOAP or HTTP headers are not used in this binding.
Message interactions
- The requestor generates a SAML message and place it inside the body of a SOAP message and transmit this SOAP message to the responder using HTTP.
- The responder process and generate a SAML response message and place it inside the body of a SOAP message and transmit the SOAP message back to the requestor using HTTP.
5. HTTP PAOS Binding
PAOS binding also known as reverse-SOAP binding. Unlike other SOAP binding specifications PAOS or more accurately ‘Reversed HTTP binding for SOAP’ is not a specification developed by W3C instead it was developed by Liberty Alliance Project, you can read more details about this specification from here.
Usually, SOAP request is carried by a HTTP request message and SOAP response message is carried by HTTP response message and utilize single HTTP request-response cycle, but in PAOS binding SOAP request message is carried by HTTP response message and SOAP response message is carried by HTTP response message and as you can imagine PAOS use two HTTP request-response cycles. SAML ECP profile uses this PAOS binding. Also, note that by default this binding does not support RealyState.
Message interactions
- SAML Responder ( This is the user’s client device, not any kind of IdP or SAML asserting party) advertises its ability to handle PAOS binding by sending HTTP GET/POST message to the requester ( usually the service provider) by using following two HTTP headers.
2. As the response to the received HTTP message, the requester sends a SOAP message with a SAML request to the responder within the body of HTTP response.
3. Once the responder in a position to respond with a SAML response, it creates a SOAP message and place SAML response within the SOAP body and use new HTTP request to send this payload to the requester.
4. Requester process receives SAML response and returns the requested business data to the client.
NOTE: Once the SAML request is received by the client device in step-2, the client device is responsible to validate it and somehow generate SAML response by contacting an IdP or using some other mean, that part is out of the context of this binding.
SAML Profiles
SAML profiles are based on practical business use cases, profiles define ruleset on how to SAML assertions, protocols and binding need to be used to achieve each of the practical scenarios. We will discuss some of the important SAML profiles during this series with a great amount of details, just to complete this post I have given a list of SAML profiles below.
SSO Profiles
- Web Browser SSO Profile
- Single Logout Profile
- Enhanced Client or Proxy (ECP) Profile
- Identity Provider Discovery Profile
- Name Identifier Management Profile
- Artifact Resolution Profile
Other Profiles
- Assertion Query/Request Profile
- Name Identifier Mapping Profile
SAML Attribute Profiles
- Basic Attribute Profile.
- X.500/LDAP Attribute Profile
- UUID Attribute Profile
- DCE PAC Attribute Profile
- XACML Attribute Profile
Learning SAML
If you have read this series up to this point, you should have a fair understanding of the SAML standard. In case if you want to explore more about SAML by reading specifications by yourself, following roadmap may help to you.
