Single Sign-On: OAUTH vs OIDC vs SAML — Part 2

Photo by Adetunji Paul on Unsplash

Welcome to Part 2 of our series on Single Sign-On (SSO) technologies. In the previous blog post, we went through SSO, OAuth, and OpenID Connect (OIDC). In this blog post, we will explore another important SSO technology: Security Assertion Markup Language (SAML). SAML is a widely-used standard for exchanging authentication and authorization data between parties, and plays a key role in many enterprise SSO implementations. In this blog post, we’ll dive into what SAML is, how it works, and how it differs from other SSO technologies we’ve discussed.

SAML 2.0

SAML, which stands for Security Assertion Markup Language, is a widely used open standard that utilizes XML to enable secure and seamless transfer of identity data between two parties, namely the identity provider (IdP) and the service provider (SP).

In the SAML workflow, a user who wants to access a service provider from user agent (i.e. the software that acts on behalf of the user) must first authenticate with the Identity Provider (IdP). If the user’s authentication is successful, the IdP generates a SAML assertion that contains information about the user’s identity and attributes. The SAML assertion is signed by the IdP to ensure its authenticity and integrity. This assertion is then sent to the Service Provider (SP). If the SP trusts the IdP, it accepts the SAML assertion as proof of the user’s identity and authorization. As a result, the user is granted access to the requested resource without needing to provide additional credentials or undergo another round of authentication.

SAML allows users to authenticate once with an IdP and then access multiple services from different SPs without having to provide their credentials repeatedly, thereby enhancing user experience and security.

SAML protocol can also be used for authorization. SAML enables authorization by including authorization attributes in the SAML assertions issued by the IdP. These assertions can contain information about the user’s roles, group memberships, or other attributes that can be used by the SP to determine what resources the user is authorized to access.

The IdP knows about the users, including their login credentials and any additional attributes that are associated with their identity, such as their name, email address, or group membership. The SP, on the other hand, may have its own user database or directory, where it stores additional information about the user that is not included in the SAML assertion. After SP validate the assertion, it reads the user identifier and tries to map it to an user in its own user store.

Trust Relationship Establishment

Before the SAML workflow, trust relationship should be established between IDP and SP. The trust relationship between the IdP and SP is established through a process called federation. Federation involves the exchange of metadata between the IdP and SP, which describes their respective endpoints, certificates, and other configuration details. The metadata typically includes the following elements:

1. Entity ID: A unique identifier for the IdP or SP, which is used to differentiate between multiple providers in a federation. It is typically expressed as a Uniform Resource Identifier (URI) such as https://idp.example.com or Uniform Resource Name (URN) urn:example:idp.
2. Single Sign-On Service (SSO) URL: This is the URL where the IDP provides authentication and sends the SAML assertion.
3. Single Logout Service (SLO) URL: This is the URL where the IDP sends logout requests to the SP.
4. Certificate: The public key certificate used to sign and verify SAML assertions and other messages exchanged between the IdP and SP.
5. Assertion Consumer Service (ACS) URL: The URL for the SP’s endpoint where SAML assertions are sent by the IdP.
6. NameID Format: The format used to represent the user’s identity in SAML assertions, such as an email address or a persistent identifier.

Once the metadata is exchanged and validated by both parties, the trust relationship is established, and the IdP can begin issuing SAML assertions to the SP for user authentication and authorization.

SAML Assertion

SAML assertion is a security token that contains statements about a user’s identity and attributes, as well as other information related to a SAML transaction. When a user authenticates to an IdP using SAML, the IdP creates a SAML assertion and sends it to a SP to establish the user’s identity and grant access to resources.

SAML assertion is typically composed of the following components:

1. IssuerID : This identifies the entity that issued the SAML assertion. In the case of SAML authentication, this would be the identity provider.
2. Subject: This identifies the user or entity that the SAML assertion is about. It includes the user’s name, ID, and other information that uniquely identifies them.
3. Conditions: This specifies the conditions under which the SAML assertion is valid, such as a time limit like NotBefore/NotOnOrAfter element or the intended audience for the assertion specified with AudienceRestriction element.
4. Authentication Statement: This uses SAML context classes to provide important information about the level of assurance associated with the user’s identity. For example, if the identity provider used a strong authentication method, such as multi-factor authentication, this could be conveyed in the assertion to indicate a higher level of assurance in the user’s identity.
5. Attribute Statement(s): These are the claims or attributes about the user’s identity and associated information, such as authorization information or session data.
6. Signature: This is a digital signature that ensures the integrity and authenticity of the SAML assertion.

In a SAML transaction, the SP relies on the SAML assertion to establish the user’s identity and grant access to resources. The SP may also use the SAML assertion to make authorization decisions based on the attributes contained within it.

SAML context classes in SAML assertion

In a Authentication Statement of SAML assertion, SAML context classes are used to define the level of assurance or trust associated with a SAML assertion. A context class can be thought of as a set of security-related characteristics that describe the authentication context or environment in which a user is authenticated.

SAML context classes provide a standardized way of communicating the level of assurance associated with a SAML assertion, which is important in situations where different levels of assurance are required based on the sensitivity of the data being accessed or the importance of the transaction being performed.

The SAML V2.0 specification defines four standard context classes that can be used to communicate the level of assurance associated with a SAML assertion. These context classes are:

• Internet Protocol (IP) network address: This context class is the lowest level of assurance and is used when the user’s identity is based solely on the IP address from which the request originated.
• Password: This context class is used when the user’s identity is verified through the use of a password or other shared secret.
• Kerberos: This context class is used when the user’s identity is verified using the Kerberos authentication protocol.
• X.509: This context class is used when the user’s identity is verified using an X.509 certificate.

There are also other non-standardized context classes that can be used to communicate different levels of assurance or trust, depending on the needs of the deployment.

By using SAML context classes, service providers can make informed decisions about how to handle SAML assertions and whether to grant access to resources or perform sensitive transactions, based on the level of assurance associated with the user’s identity.

SAML context classes can be customized to meet the specific needs of a deployment.

SAML Workflows: IDP-initiated Flow and SP-initiated Flow

There are two common workflows in the SAML technology: IDP-initiated flow and SP-initiated flow.

In an IDP-initiated flow, the user doesn’t have to first navigate to the SP’s application or resource. Instead, the IDP takes care of initiating the SSO process and redirecting the user to the SP. This can be useful in situations where the IDP is the primary entry point for users, or when the SP is not accessible from the public internet.

In an SP-initiated flow, the user starts by attempting to access a resource on the SP’s application or website. The SP then initiates the SSO process by generating a SAML request and sending it to the IDP. This can be useful in situations where the user already knows the resource they want to access and wants to initiate the SSO process from the SP’s application.

At a high-level, the authentication flow of SAML can be summarized as follows:

source: https://developer.okta.com/img/saml/saml_guidance_saml_flow.png

In the authentication flow, SAML Request is an authentication request, it typically includes information about the user’s identity, such as their username or email address, as well as a digital signature to ensure the message’s authenticity and integrity. Once the IdP receives the SAML request, it verifies the signature and authenticates the user based on their credentials. If the user is successfully authenticated, the IdP generates a SAML response that includes SAML assertion.

SAML 2.0 Bindings

Now that we understand the high-level SAML authentication workflow, let’s talk about how the messages exchanged in this process are transmitted between the SP and IdP. This is where SAML bindings come into play.

SAML 2.0 bindings refer to the mechanisms or protocols used to transport SAML 2.0 messages and assertions between SAML entities, such as IDPs, SPs, and other SAML-compliant systems.

Some of the common SAML 2.0 bindings include:

• HTTP Redirect Binding: This binding is used to transport SAML messages by encoding them as URL parameters in an HTTP redirect message. This binding is typically used for short messages or in situations where there are restrictions on the size of the message that can be sent, such as in some web browsers.
• HTTP POST Binding: This binding is used to transport SAML messages by encoding them as form parameters in an HTTP POST message. This binding is typically used for longer messages or in situations where the message size is not restricted, such as when exchanging SAML assertions.
• Artifact Binding: It is a SAML mechanism for transferring large messages between entities by splitting the message into two parts: a small, signed and encrypted artifact message containing a reference to the actual message, and a larger, unsigned and unencrypted SAML message containing the actual data. When a relying party, such as an SP, receives the artifact message from the IDP, it follows the reference contained in the message to retrieve the actual SAML message from a repository where it has been previously stored. The retrieved SAML message is then processed by the SP. This binding is typically used in situations where the SAML message is too large to be transported using the HTTP Redirect or HTTP POST bindings.
• SOAP Binding: This binding is used to transport SAML messages over SOAP-based web services. This binding is typically used in situations where the SAML message needs to be integrated with other web services or systems that use SOAP.

These different bindings provide flexibility and allow SAML messages to be transported using different protocols and mechanisms, depending on the needs of the deployment.

Final Thoughts

We have covered several important aspects of SAML 2.0, a widely used protocol for enabling secure single sign-on (SSO) in enterprise environments. SAML 2.0 is a powerful and flexible protocol that can help organizations streamline their authentication and access control processes, while also enhancing security and usability for end users. However, implementing SAML 2.0 requires careful planning and consideration, including establishing trust relationships between identity providers and service providers, defining authentication workflows, and selecting appropriate SAML bindings. By understanding the key concepts and components of SAML 2.0, organizations can make informed decisions about how to implement and leverage this technology to meet their specific needs and requirements.

It is the end of the topic, thank you for reading!