Geek Speak: Should you choose SAML?

Have you ever wondered how SAML works, why it’s sometimes referred to as coming with a ‘tax’ and can cost double, or when you should choose it over alternatives? If so, you’re in the right place! In this deep dive into Security Assertion Markup Language, more commonly known as SAML, we’ll unpack its key components, explore its benefits and challenges, and compare it with other popular identity management protocols. So, whether you’re a seasoned IT professional or simply curious about SAML, there’s something in this guide for you!

Key Terminology

To make the most of this article, it’s helpful to familiarize yourself with some common terms related to SAML.

1. Security Assertion Markup Language (SAML): A protocol that uses XML to exchange authentication and authorization data between an identity provider (IdP) and a service provider (SP).
2. Single Sign-On (SSO): A technology that allows users to log in just once and gain access to multiple applications, without having to authenticate again for each application.
3. Assertion: This is the core unit of identity information in SAML. It contains statements from a SAML authority about a subject, typically a user.
4. Service Provider (SP): In SAML, the service provider is the entity that provides services or data to the user. The service provider relies on the identity provider to authenticate users.
5. Identity Provider (IdP): This is the system that authenticates users in the SAML process. It provides the service provider with assurance that users are who they claim to be.
6. SAML Request/Response: A SAML request is generated by the SP and sent to the IdP requesting the authentication of a user. In response, the IdP generates a SAML response that contains an assertion about the user’s identity.
7. Binding: This refers to the method by which SAML requests and responses are transported.
8. Attribute Assertion: This type of assertion carries specific pieces of data about the user, which may be required by the SP for making authorization decisions.

Understanding these terms will make it easier to grasp the more complex aspects of SAML explained later in the blog post.

SAML: A High-Level Overview

SAML is an XML-based open standard for exchanging authentication and authorization data between parties. It’s a product of the Organization for the Advancement of Structured Information Standards (OASIS). SAML is crucial in enabling Single Sign-On (SSO), a technology that allows you to log in once and gain access to various applications without needing to authenticate again. This means less stress about managing various usernames and passwords, and a smoother, more secure user experience.

Demystifying SAML Assertions

The core unit of identity information in SAML is known as the Assertion. It’s a package of information that supplies zero or more statements made by a SAML authority about a subject.There are three types of assertions that the SAML specification defines:

1. Authentication Assertion: This is a statement that an authentication event occurred at a specific time by a specified method. It includes technical details about the method used for authentication (e.g., password, digital certificate), the time of authentication, and the entity that authenticated the user.
2. Attribute Assertion: This statement carries particular pieces of data about the subject. In a typical scenario, this could include the user’s name, email, department, role, or any other user attribute that the service provider needs to know for making authorization decisions or for personalizing the user’s experience.
3. Authorization Decision Assertion: This type of assertion indicates whether the subject is permitted or denied access to a particular resource. This is the least used type of assertion because the decision of whether to allow access is usually made by the service provider, not the identity provider.

Each SAML Assertion is wrapped in a <saml:Assertion> element in the SAML XML message and is digitally signed by the issuing identity provider, ensuring its authenticity and integrity.

Dissecting the SAML Workflow

To understand SAML, it helps to follow the flow of messages through a typical SAML-based Single Sign-On (SSO) process. Let’s take the same example of an employee at Tech Corp trying to access the HR system, PeoplePro.

1. The user accesses PeoplePro, which acts as the Service Provider (SP). PeoplePro determines the user’s identity isn’t authenticated yet and creates a <samlp:AuthnRequest> which is sent to Tech Corp’s Identity Provider (IdP) through the user’s browser. This message is asking the IdP to authenticate the user.
2. The Identity Provider at Tech Corp, having previously authenticated the user (usually via a login form when the user started their session), creates a SAML Assertion containing the user’s identity and, if requested, user attributes.
3. The SAML Assertion is placed inside a <samlp:Response> and is sent back to the Service Provider (PeoplePro) via the user’s browser. The <samlp:Response> also contains a status code indicating the success or failure of the authentication request, and if a failure, the reason why.
4. PeoplePro, upon receiving the <samlp:Response>, extracts and validates the Assertion - ensuring it’s from a trusted IdP, hasn’t been tampered with, and is targeted at the correct recipient. If all checks pass, PeoplePro logs the user in and creates a session for the user to request vacation days.

In this workflow, the SAML messages (<samlp:AuthnRequest> and <samlp:Response>) and the SAML Assertion serve as the critical tokens of trust, being passed between the Identity Provider and the Service Provider. They enable the seamless and secure exchange of user identity information that SAML is known for.Do note that the above-described flow is for the SAML Web Browser SSO profile using HTTP Redirect and POST bindings, which is the most commonly used profile. There are other profiles and bindings defined in the SAML specification that can cater to different scenarios and use-cases.

SAML Use Cases and Benefits

SAML provides unique advantages, particularly when dealing with enterprise-level and internally developed applications. Here are some noteworthy use cases:

1. Enterprise Single Sign-On (SSO): SAML is a primary choice for enterprise SSO, which often involves integrating various internal and external applications. Its ability to seamlessly interoperate across different domains provides a robust and secure environment for SSO, enhancing user experience and improving productivity.
2. Internal and Legacy Application Access: SAML is a great fit for providing secure access to internal and legacy applications, which might not support modern protocols such as OpenID Connect (OIDC). By enabling such applications to integrate with the organization’s existing Identity Provider (IdP), SAML mitigates the need for multiple login credentials, improving security and reducing administrative overhead.
3. In-house Identity Provider: SAML enables organizations to set up their own in-house IdP. This means companies like Tech Corp can have full control over the user authentication process without depending on third-party IdPs like Google or Microsoft. This provides more control over user data.
4. Single Logout (SLO): A key feature of SAML is the Single Logout (SLO). This functionality allows users to end sessions with all service providers simultaneously when they log out from one of them. In an environment where a user might be authenticated into multiple applications, SLO ensures that user sessions are securely closed across all applications, providing a more seamless user experience and enhancing overall system security.

SAML provides various benefits such as enhanced security, better compliance, reduced administrative overhead, and improved user experience. However, it’s essential to understand its complexity and the challenges involved.

Addressing the Challenges of SAML

While SAML provides an excellent foundation for secure Single Sign-On (SSO) between service providers and identity providers, implementing and maintaining it isn’t without its challenges.

SAML Implementation

Implementing SAML can be a significant undertaking. The SAML specification is complex and requires a deep understanding of XML and certificate management. For instance, preparing SAML requests/responses requires generating and parsing XML documents that adhere to the SAML schema, handling XML signatures, and managing X.509 certificates for signing and encryption.Service providers like PeoplePro must implement and test SAML endpoints for authentication requests and responses. They also need to create administrative interfaces to manage SAML settings for each customer (like Tech Corp) that wants to enable SSO. In turn, customers like Tech Corp need to set up their Identity Providers (IdPs) to support SAML, which involves configuring SAML settings and certificates and possibly user attributes for each and every service provider they want to integrate with.

SAML Integration and Interoperability

Each SAML deployment must be individually configured for each pair of service provider and identity provider, and the SAML standard allows for many optional features. This flexibility means there can and are differences in how SAML is implemented by different vendors, leading to interoperability issues.For instance, one vendor might use a different attribute name for the user’s email than another. While the SAML specification recommends using the “email” attribute name, it does not enforce it, and thus, one vendor might use “emailAddress,” another uses “mail,” and another uses “userEmail.” Each of these discrepancies adds more complexity and can lead to potential problems when integrating systems.

Maintaining SAML Deployments

Once SAML SSO has been established, it needs to be maintained. This includes managing and rotating digital certificates used for signing and encryption, troubleshooting SAML assertion errors, updating user attributes as business requirements change, and keeping up with changes in the SAML specification and updates from the service provider or identity provider vendors.Furthermore, given that SAML runs on the HTTP protocol, organizations must monitor and secure their SAML SSO infrastructure to prevent security vulnerabilities, such as XML Signature Wrapping attacks or potential data leaks.In summary, while SAML is an extremely powerful and flexible protocol for identity federation, it can be challenging to implement, integrate, and maintain. To ease these challenges, organizations may choose to use commercial SAML software or cloud-based identity services, use open-source SAML libraries that handle much of the heavy lifting. Most likely the service provider will adopt and have better support for a simpler, JSON-based protocol like OpenID Connect or OAuth 2.0, before adopting SAML.

SAML vs. OIDC and OAuth 2.0: Factors to Consider

Now that we’ve thoroughly discussed SAML, it’s important to note that it’s not the only protocol in town for handling identity and access management. Two other significant players in this domain are OpenID Connect (OIDC) and OAuth 2.0.When deciding whether to implement SAML or to shift to OIDC and OAuth 2.0, it’s essential to consider several key factors:

1. Existing IT Stack: If a company like Tech Corp already has numerous SAML integrations and its infrastructure is well-equipped to handle SAML, it might be less time-consuming and cost-effective to continue using SAML. Conversely, if Tech Corp is already heavily leveraging OIDC with OAuth 2.0 for external SaaS apps, such as “Sign in with Google,” migrating fully to OIDC might make more sense.
2. Service Provider Compatibility: A critical question to ask is whether a service like PeoplePro supports both SAML and OIDC with OAuth 2.0. If it only supports one of these, the decision is practically made. If it supports both, the other factors listed here will weigh more heavily in the decision. Notably, services can have vastly different support for SAML features, and it’s important to verify what exactly a service like PeoplePro supports.
3. User Attributes and RBAC: SAML supports complex user attributes, which makes it easier to synchronize role-based access control (RBAC) between services. If an organization like Tech Corp requires complex user attribute synchronization, SAML might be the preferred choice.
4. Security Requirements: Both SAML and OIDC offer secure authentication but in slightly different ways. OIDC uses JSON Web Tokens (JWT), which are more flexible and can carry more information than SAML assertions. However, SAML is generally considered to be slightly more secure because it signs the entire XML document, as opposed to just the header and payload as with JWTs.
5. Future Proofing: OIDC, being a newer protocol, is more future-proof. It’s better equipped to handle modern web applications and single-page applications. If Tech Corp plans to modernize their applications or create new ones, OIDC could be a better long-term choice.
6. Mobile Application Support: If Tech Corp has or is planning to develop mobile applications, OIDC and OAuth 2.0 could be a better choice. They are better suited for mobile applications due to their lighter requirements and less reliance on redirects, which can be cumbersome on mobile.

These factors are not exhaustive, and decisions about which protocol to use should be made carefully, considering the specific needs and circumstances of your organization. Remember, the goal is to strike a balance between security and user experience.In the end, whether you choose SAML or OIDC and OAuth 2.0, it’s essential to understand the implications of your decision, the complexity involved, and the potential impact on your IT infrastructure and end users.

Concluding Notes

That’s a wrap on SAML for now. Of course, there are more intricate details and technical jargon involved when implementing SAML, but this should serve as a good starting point for understanding its core concept. Remember, the digital world doesn’t need to be a spooky place as long as you know what’s happening behind the scenes.