Introduction
SAML (Security Assertion Markup Language) is a protocol that enables Web browser Single Sign-On (SSO) across multiple domains, allowing users to authenticate once and access multiple resources without having to re-enter credentials. SAML operates through the exchange of XML-based messages between an Identity Provider (IDP) and a Service Provider (SP).
SAML is widely used in enterprise environments to enable SSO between internal and external applications, as well as between cloud and on-premise systems. SAML is also used in government and healthcare organizations to ensure secure access to sensitive information.
One of the advantages of SAML is its flexibility in supporting various authentication methods, such as password, multi-factor authentication (MFA) and Kerberos. SAML also supports attribute-based access control (ABAC), which allows for fine-grained access control based on user attributes.
Overall, SAML is a robust and widely adopted protocol for enabling secure SSO across different domains and applications.
Who is a SAML provider?
A SAML provider is a system that enables users to gain access to a necessary service. There are two types of SAML provider:
An Identity Provider (IDP) is a system that performs user authentication and authorization and passes the user's identity and authorization level to the Service Provider (SP). The IDP verifies the identity of the user and generates a SAML assertion containing the user's identity and authorization information, which is then sent to the SP.
A Service Provider (SP) is a system that provides access to a specific application or resource and relies on the IDP to authenticate and authorize users. The SP trusts the IDP to provide accurate user identity and authorization information and uses this information to grant or deny access to the requested resource.
What is a SAML assertion?
A SAML assertion is a digitally signed XML document that contains information about a user, such as their identity, authentication time, and authorization level. The IDP sends this assertion to the SP to provide information about the user's authorization status. SAML assertions can be classified into three types:
Authentication assertion: This type of assertion is used to verify the identity of the user and provide details about the authentication method used, such as username/password or multifactor authentication and detail about when the authentication has happened.
Attribute assertion: This type of assertion provides additional information about the user, such as their email address, role, group membership or role.
Authorization decision assertion: This type of assertion indicates whether the user is authorized to access the requested resource or not based on their identity and attributes. By authorizing the user for multiple privileges, SAML provides an added layer of protection for your application, going beyond just authentication.
SAML assertions are a critical component of SAML-based SSO, as they provide a secure mechanism for transferring user information between the IDP and the SP.
The exchange of SAML assertions between an IDP and an SP can take place through two main methods: SP-initiated flow and IDP-initiated flow.
How does SP-initiated SSO work?
In an SP-initiated SAML flow, the user begins by accessing a protected resource on the SP's website, such as an application or a service.
The SP then sends a SAML request to the IDP, asking for the user to be authenticated.
Once the user logs in, the IDP generates a SAML assertion containing the user's identity and attributes, and sends it back to the SP.
Next the user is redirected back to the original resource, where they can access it without having to log in again.
Here are the steps involved in an SP-initiated SAML flow:
The user accesses a protected resource on the SP's website, such as an application or a service. The SP may request additional identity information, such as the user's email address, to determine the appropriate IDP to use from multiple configured IDPs. For example, the domain of the email address, such as john.doe@example.org, can be used to identify the correct IDP.
The SP generates a SAML request and sends it to the IDP using an HTTP Redirect or HTTP POST binding. The SAML request contains information about the requested service and a unique identifier for the request. The SAML Request could also be digitally signed.
The IDP receives the SAML request and validate it.
If the user is not already logged in, he is prompted to enter his credentials.
Once the user is authenticated, the IDP generates a SAML assertion containing the user's identity and attributes, signs it, and sends it back to the SP using an HTTP POST binding.
The SP receives the SAML assertion and validates it, checking the digital signature and verifying that it came from a trusted IDP. Once the SAML assertion is validated, the SP sets a session cookie or token and allows the user to access the requested resource.
SP-initiated SAML flows are often used in scenarios where the user is expected to access a specific service, and the SP wants to provide a seamless login experience without the user having to navigate to the IDP's website first. For example, an organization may use an SP-initiated SAML flow to allow their employees to access a cloud-based HR system directly from the company's intranet.
How does IDP-initiated SSO work?
In an IDP-initiated SAML flow, the user begins by accessing the IDP's login page directly or an IDP dashboard, which presents an application broker in which the user can choose the target SP.
Once the user logs in, the IDP generates a SAML assertion containing the user's identity and attributes, and sends it to the SP.
Next the user is redirected to the SP's service page, where they can access the service without having to log in again.
The IDP-initiated flow is the same of SP-initiated except for the initial SP SAML request that is absent, the steps involved are:
The user navigates to the IDP's login page.
If the user is not already logged in he is prompted to enter his credentials.
Once the user is authenticated the IDP generates a SAML assertion containing the user's identity and attributes. The IDP sends the SAML assertion to the SP's Assertion Consumer Service (ACS) URL using an HTTP POST binding.
The SP receives the SAML assertion and validates it, checking the digital signature and verifying that it came from a trusted IDP. Once the SAML assertion is validated, the SP sets a session cookie and allows the user to access the requested service.
IDP-initiated SAML flows are often used in scenarios where the user is expected to access a specific service, and the IDP wants to provide a seamless login experience. For example, an organization may use an IDP-initiated SAML flow to allow their employees to access a cloud-based HR system without having to navigate through the company's intranet to find the service.
Single Log Out support
SAML not only enables SSO, but it also offers a mechanism to implement a centralized logout that involves both the IDP and the SP, allowing for a more streamlined and secure logout process.
SAML Single Logout (SLO) is a functionality within the SAML standard that enables users to log out of multiple SPs in one go. SLO allows users to end their session across all the applications that were accessed during the current session, without the need to log out of each application separately.
This is especially useful in situations where a user has accessed multiple SPs and needs to log out quickly or in situations where a user logs out from a shared computer or device. SAML SLO defines a protocol for securely logging out of a federated session across multiple SPs and the Identity Provider (IDP) that authenticated the user.
SAML versions over the years
There have been several versions of the SAML over the years. The initial version of SAML, SAML 1.0, was released in 2002, followed by SAML 1.1 and then SAML 2.0 in 2005. SAML 2.0 is currently the most widely used version.
SAML 1.0 and 1.1 were focused on browser-based Single Sign-On (SSO) scenarios and provided basic authentication and authorization functionality. SAML 2.0 was a significant upgrade and included many new features and enhancements, such as:
- Support for more complex identity federation scenarios beyond just browser-based SSO.
- Better integration with web services and SOAP-based protocols.
- Improved support for digital signatures and encryption, making it more secure.
- Support for metadata, which enables easier configuration and management of SAML-based IDPs and SPs.
- Since the release of SAML 2.0, there have been several incremental updates, which address various issues and errata in the specification. Additionally, there have been profiles developed for specific use cases, such as the SAML V2.0 NameID Mapping Profile for the Liberty Alliance Project and the SAML 2.0 Enhanced Client or Proxy (ECP) Profile.