Exploring SAML

[SAML - Security Assertion Markup Language]

SAML is a technology standard used and well documented in the IAM space.

The most popular use case of SAML is SSO (Single Sign-On).

In SSO, a particular user is authenticated into several applications via a single account. This makes life easier for users, who won’t have to remember multiple passwords, as one set of credentials will provide access to multiple applications.

In SAML SSO, a user’s identity and other details about the authenticated session are exchanged between an identity provider (IDP) to a service provider/application (SP) in the form of digitally signed XML message (SAML assertions).

What are some benefits of this standard?

• More secure authentication – Before SAML, authentication was achieved by typing a separate username and password to log into each application. More often than not, each app stored these credentials within them, paving the way for security breaches. With SAML, the user is authenticated via a trusted IDP, which stores the credentials, dispelling the need for different applications to store user credentials individually.
• SAML can be implemented over any system regardless of the underlying implementation.
• With SSO, one set of credentials can provide access to access many applications.
• A better user experience.

Is SAML powerful?

It is powerful, as it is one of the popular ways to implement SSO in a system. However, currently, OAuth2 is the frontrunner in the SSO domain, so SAML may be losing its charm. Since SAML uses XML as a message format, it is not very flexible, unlike Oauth2, which uses the JSON format. SAML also does not pair well with mobile applications, as opposed to OAuth2.

Key SAML terms

IDP

An IDP (identity provider) is the server that authenticates users and stores their credentials. Once an IDP authenticates a user, it provides an “authentication assertion” (authentication details) for each user.

SP

An SP (service provider) is an application that a user wants to access. An SP will not provide authentication, but delegates that task to an IDP.

Client

Users that send requests to an SP.

SSO Service

SSO is a service endpoint in an IDP. This service in an IDP handles SAML’s SSO requests and sends SSO responses.

SSO Service at IDP

SAML SSO

There are two types of SSO use in SAML:

1. SP-initiated SSO
2. IDP-initiated SSO

A high-level view of SP-initiated SSO and IDP-initiated SSO

An SP-initiated SSO flow

As depicted above, in the SP-initiated SSO flow, the SP sends an SAML request to an IDP and the IDP responds with an SAML response. In the IDP-initiated SSO flow, an SP does not send any request. Rather, the IDP initiates the flow by sending an SAML response to an SP.

In both scenarios, the IDP sends a digitally signed XML as an authentication response. Then, the SP verifies the signed XML for any tampering and provides access to the user. When signing digitally, a hash value of the XML response is encrypted using the private key of the sending party, which is the IDP in this case. When the receiving party (SP) receives the signed XML, it first decrypts it using the public key of sending party and then compares the hash value with the actual hash value of the received message. If they are the same, it means the message was not tampered by a third party.

SP-initiated SSO

In SP-initiated SSO, the following two scenarios may occur:

1. A user visits an SP; the user is not authenticated. Therefore, the user is redirected to an IDP for authentication. Here, the user needs to provide their credentials in the login screen.
2. A user is already authenticated by an IDP; the user visits an SP. The user gets access without needing to authenticate with an IDP once again. (Here, the SP contacts the IDP to check whether the user is already authenticated, and if so, a login page will not be displayed for the user.)

What is SAML metadata?

SAML metadata are information, endpoints, capabilities, and details of parties involved in SAML use cases. SP and IDP each have their own metadata.

SP and IDP can use each other's metadata to configure and communicate with each other. For example, an admin of an SP can import IDP SAML metadata and vice versa. IDP metadata contains endpoints for SSO service.

SPs and IDPs can contain each other’s metadata to gather relevant information about both parties.

How does an SP redirect an IDP to login in to SAML?

In SAML, an SP has prior knowledge/metadata on the IDP. Therefore, when sending a SAML request to an IDP, an SP will find the IDP SSO service endpoint URL via IDP metadata and re-direct to the correct IDP endpoint. So, when implementing an SP, we should think about configuring an IDP redirect URL in the SP side, as well as having an IDP public certificate.

In a case where the SP has more than one trusted IDP, there should be a way to identify which IDP to use when a client sends a request. Some ways to determine an IDP are:

• If the request URL has an IDP ex:spdomain/tenant/{IDP}
• Prompt a dialog box for users to enter their corporate email ID, which the SP can use to determine the IDP according to the email domain

SAML Token

• The SAML token issuer (IDP)
• The user’s email
• The SAML token’s expiry time/validity period
• The time the user got authenticated

Once the SP receives the SAML response with an SAML token, the SP uses that token to continuously verify the user’s session. It is the SP’s responsibility to save it in a browser cookie or some mechanism to track the user’s session. Then, until the SAML token validity period ends, the SP can use that cookie to keep the user continuously authenticated on the SP site. Once the SAML token becomes invalid, the SP can send a new SAML authentication request to the IDP to authenticate the user once again.

Cookies are name-value pairs that are set against host domains. Whenever a browser makes a request to a particular domain, all cookies belonging to that domain will go along with the request. In SAML, both the SP and the IDP can define cookies for their domains.

Let’s take a sample scenario of an IDP cookie.

If a user has enabled SSO with two apps/SPs with a trusted IDP, when the user opens his/her browser and tries to authenticate with SP1, that SP sends an authentication request to the trusted IDP. The IDP then authenticates the user and sets a browser cookie against the domain name of the IDP (e.g., commonAuthID cookie in WSO2 IS). The user uses that same browser and tries to visit SP2. SP2 also re-directs the user to the IDP as an authentication request. When this authenticate request goes to the IDP, the cookie set against the IDP domain is also sent along with the request. The IDP reads that cookie and determines that the user is already authenticated and lets the user log into SP2 without prompting any login pages.

Multiple SP behavior

A common misconception about the SSO between multiple SPs is that SPs talk to each other to have SSO between them. However, the correct approach is that each SP should talk to the trusted IDP to make sure a user is authenticated. There is no communication the SPs.

While SP-initiated SSO is a common use case, IDP-initiated SSO is not discussed as much. Let’s take a sample use case as follows:

1. You are logged into your corporate IDP
2. This IDP has a user portal of different external/internal partner SPs (e.g., an expense report app) that trust this IDP
3. If you want to create an expense report for your OPD claims, you click the link related to the expenses report service in the portal of your IDP. (When you click the link, it will call the SSO service at the IDP to send an SAML response to the corresponding partner SP)
4. Then, the IDP creates an SAML response and sends it to the partner expenses report service
5. Since that expenses report service has registered your corporate IDP as a trusted source, it will create a session for you and you will be already logged into that app, foregoing the need to authenticate separately

Is SAML IDP an “authorization authority”?

SAML is used for authentication, while authorization is about providing access control according to certain rules/policies/attributes. In an SAML response, there can be attributes that can be used to make authorization decisions. In this event, an SP can use those attributes in the SAML response and decide whether or not to provide access to the user.

In this post, I mainly explored SAML SSO. In my upcoming posts, I will discuss other aspects of SAML.