SAML is an XML-based.open standard markup language that was introduced in 2001, followed by version 2.0 which was released in 2005. SAML is often used to provide single sign-on to web-based applications and it can be used for both authentication and authorization. The SAML protocol has three entities: the user agent, which typically is the user’s web browser; the service provider or SP, which is the application you try to access; and lastly, the identity provider or IDP.
When configuring SAML Federation, you establish a trust relationship between the service provider and the identity provider. A user who wants to access a service provider must first authenticate into the IDP. If the user manages to successfully authenticate and is authorized, the IDP generates a SAML assertion. The assertion is sent to the application, and since the application trusts the IDP, the user is allowed access. Additionally, since the user is already authenticated into the IDP, the user can single sign-on to other applications
Now let’s delve one step deeper into the SAML flow. The identity provider knows about your users and their attributes, and your service provider has its own knowledge about the users. When the identity provider generates an assertion, it populates Service Provider with a user identifier and sends it over to the SP. However, the SP cannot just receive it in clear text or completely unprotected. Therefore, the IDP must first sign the assertion. This way, the SP can validate the issuer of the assertion and trust it.
Next, the SP reads the user identifier and tries to map it to a user in its own user store. In some cases, it may fail to find the user attribute. To make Federation work, integration rules need to be established. For example, the SP might dictate that the user identifier, and format should be the email address, and the IDP must agree and be configured to match this.
Once both sides have the same configuration, the SAML assertion can be mapped to a user object at the service provider, allowing access. The configurations or rules for integration are critical to successfully establish a SAML Federation. These configurations, requirements, and capabilities are compiled into an XML metadata file. This file contains the settings and the certificate of the system, which can be exchanged to configure the Federation. This metadata exchange is what establishes the trust.
The metadata file contains the format for the user identifier called the NameID formats. The names of the NameID formats are standardized and look like the ones shown in the picture below
The most common NameID formats are ‘unspecified’ or ’email.’ It is not super critical to use the ’email’ format when sending an email address as the user identifier; the most important thing is that both sides are configured the same. The metadata often contains the sender’s certificate as well. Using the certificate, the receiving end can validate the signing of the assertion and know that it came from a trusted party. The entity identifier is also included in the file, which will uniquely identify the sender or receiver.
First, let’s have a look at how a user can initiate the authentication flow. We have two main ways of initiating the flow of authentication. The first is called the IDP-initiated flow. In this flow, the user starts by accessing the identity provider. The user is prompted for authentication, and once done, the user can request a service. If the user is authorized, the IDP generates a SAML assertion using the user agent. The assertion is sent to the Service Provider (SP) using a POST message. It is the user agent that acts as the transport mechanism for the assertion. The SP verifies the assertion, maps it to a local user, and then the session can start.
The second method of initiating the authentication flow is referred to as the SP-initiated flow. Here, the user starts by reaching out to the service provider. Since the user is not authenticated, the SP redirects the user to the identity provider using a request for authentication message. Once the user is validated, the IDP generates the SAML assertion. The assertion is sent to the SP via the user agent, and the session can start
In SAML, the assertion can be sent between the SP and the identity provider (IDP) using various methods known as bindings. Bindings define how SAML messages and assertions are technically transmitted between the SP and the IDP. Here are some common bindings used in SAML:
- HTTP Redirect Binding: This binding is used for requests for authentication messages sent from an SP to an IDP. It involves redirecting the user’s browser to the IDP with the SAML message or assertion included in the URL as query parameters.
- HTTP POST Binding: This is the most common binding and can be used for both transporting the assertion and request messages. The SAML message or assertion is embedded in an HTTP POST request sent from the user agent to the IDP or SP.
- SAML Artifact Binding: When using the SAML artifact binding, the IDP generates two messages: one is the SAML artifact, and the second is the assertion itself. The artifact is a lightweight message containing a unique identifier. The IDP sends this artifact to the SP via the user agent. Then, the service provider sends an artifact resolve message back to the IDP to retrieve the actual assertion. This way, with the SAML artifact binding, the SP and the IDP need to communicate with each other to complete the transaction.
Once the user has been authenticated, and authorization has been verified, the IDP generates the SAML assertion. It includes the NameID with the correct NameID format for user identification. However, the method used for authenticating into the IDP is of great importance as it determines our confidence level in identifying the user. Therefore, this information needs to be added to the SAML assertion.
When the SP receives the assertion, it can decide to accept the level of authentication used, deny access, or request the user to go back to the IDP for a stronger authentication method. The identification of an authentication method is referred to as the SAML context classes. There are several common context classes, with “password-protected transport” being the most commonly used one. However, you are not restricted to a fixed list of context classes; anyone can define their own, as long as both the SP and the IDP are in agreement, the Federation will work.
A typical user object has attributes associated with it. Therefore, it makes sense to include attributes in the SAML assertion to provide more details about the user. As with other aspects of SAML, the format of the attributes needs to be specified, and both the SP and the IDP must be configured with the same formats.
Additionally, specific conditions for the SAML assertion need to be defined, such as the valid time for the assertion (to protect it from replay attacks) and the intended audience to whom the assertion is sent.
Furthermore, the issuer of the assertion needs to be identified, so the SP knows who generated the assertion. Lastly, the entire assertion needs to be hashed and signed to provide protection from tampering.
These steps collectively ensure the security and integrity of the SAML authentication and authorization process.
