(2 votes, average: 5.00 out of 5)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

January 19, 2024 Comments closed

Demystifying SAML Authentication: A Look at the Role of SAML in SSO-Based Access Management 

in Hashing Out Cyber Security

We’ll break down XML- and PKI-rooted SAML authentication and its role in Single Sign-On technologies (used by authentication tools like Okta, Duo, etc.) in layman’s terms 

SAML, or Security Assertion Markup Language, is a foundational element of single sign-on (SSO) tools. SSO technology is convenient and easy to use; it serves as a centralized point of authentication that users authenticate to (typically in the form of a user portal). Once a user is authenticated, they’ll have access to all the apps and tools they’re authorized to use via a centralized dashboard.  

For example, Login.gov is the SSO service used by U.S. government agencies that enables users to create one single account that gives them access to services from multiple partner agencies. It allows application developers to choose between using SAML or the OpenID Connect (OIDC) as the implementation protocol. 

From a user’s perspective, SSO is almost akin to magic. For them, it means no more mucking about with multiple usernames and passwords. Users no longer must log in to separate services. From an admin’s perspective, it’s more secure than having users juggle multiple login credentials and log in through separate third-party web apps that may not be secure.  

All of this brings us back to our original question: where does SAML authentication fit in? What makes SAML a secure underlayment for SSO? And how can you integrate SAML and SSO within your business?  

Let’s hash it out.

SAML = Security Assertion Markup Language 

In short, SAML is a widely adopted open standard and authentication protocol that enables two parties to securely exchange digital identity and authentication-related data. It is used to facilitate secure authentication as a primary focus.  

SAML authentication aims to provide a secure, user-friendly experience by:  

• Securely transmitting sensitive user data via public key cryptography, and  
• Eliminating multiple login credentials and sign-in processes in exchange for a single sign-on functionality. 

SAML was created by the OASIS Open standards consortium’s Security Services Technical Committee. (OASIS stands for Organization for the Advancement of Structured Information Standards.) This framework is based upon Extensible Markup Language (XML) and relies on public key cryptography (and its underlying public key infrastructure [PKI]) to securely communicate that sensitive data. (More on that in just a moment.) 

A few versions of the SAML standard have been around since November 2002. (SAML 1.0 in 2002, SAML 1.1 in 2003, etc.) The most recent version, SAML 2.0, came out a few years later in 2005; it’s been in use ever since.  

Check out this video from VMWare. It takes a closer look under the hood at how SAML authentication initiates and delves more into the nitty-gritty of how it works:  

PKI and SAML Play Nicely Together 

SSO and SAML help to provide a single point of authentication via a trusted identity provider. The security of SAML 2.0 authentication is founded on public key infrastructure (PKI), the bedrock that internet security itself is built upon.  

SAML is a standard that uses PKI digital certificates for the purpose of authenticating users’ digital identities. (This helps systems verify that a user signing into their service really is the legitimate user and not someone impersonating him or her.)  

SAML uses PKI-based XML digital signatures for assertions, which are created using the signer’s private key and verified using their public key, and attribute encryption using XML encryption.  

Although some SSO vendors allow you to get away with using self-signed client authentication certificates, many require you to use publicly trusted certificates instead. 

Is SAML perfect? Nah. No protocol or standard is perfect; there’s always the potential for vulnerabilities, particularly if something isn’t implemented properly. (Some systems and processes also just happen to be buggier than others!) As such, there’s always room for improvements to be made.  

SAML vs OIDC: What’s the Difference? 

If you’ve at least heard of SAML, then it’s likely that you’ve also heard of OpenID Connect. OIDC is a less complex protocol that’s based on the OAuth 2.0 Framework.  

In some aspects, OpenID Connect was intended to be the successor to SAML because its standards are used by many commercial organizations. However, many larger enterprises still prefer to rely on SAML. While both are considered identity protocols, there are differences in terms of their uses and underlying mechanisms. For example, SAML uses XML assertions (more on those in a bit), whereas OIDC uses JSON web tokens (JWTs).    

What Does SAML Do? 

In a nutshell, SAML lays the technical groundwork that enables users (called Subjects or Principals) to authenticate using SSO tools. The SAML open standard provides the foundation for the communications that take place primarily between two main parties:  

1. A trust store (also known as an identity provider [IDP]). Examples of such IDPs would be Okta (although, technically, this can also be used as a service provider), Duo, JumpCloud, etc.  

2. The service provider (SP) whose app or service the user wants to access. Examples of a couple of service providers could be your company’s HR app, a communication tool like Zoom, a project management tool like JIRA, and your email client.  

A third party involved is the user’s browser — this is called a web client or user agent. Many of the metadata exchanges that take place between the IDP and SP go through this third party. 

There are two key transactions that take place between multiple systems and entities when engaging SSO with SAML: 

1. SAML Requests 

When the SP sends a communication to the IDP, it’s called a SAML Request. This occurs when an authenticated user tries to sign in to authenticate and access a service provider’s dashboard, service or app. This message generally contains information about the user (in the form of a character-string ID), specifies how the data should be formatted, and provides additional information. 

2. SAML Responses 

Now, let’s consider what happens when the IDP responds to the SP. This message is called a SAML Response. These messages are sent to the SP’s Assertion Consumer Service, whose job it is to process them.  

SAML Responses contain several important pieces of data: 

• Several digitally signed and encrypted statements about the user’s identity, which are called Assertions,  
• Other key user identification values that are contained within assertions are called Attributes (first name, last name, username, etc.). These also can be digitally signed and encrypted.  
• Conditions that specify a validity period for the SAML Response (i.e., specific “NotBefore” and “NotOnOrAfter” date and time constraints). 

Both SAML assertions and COID tokens must be secure. In this case, they use different forms of encryption. According to NIST: 

“When personally-identifiable information is included in the assertion and the assertion is handled by intermediaries such as a browser, the federation protocol SHALL encrypt assertions to protect the sensitive information in the assertion from leaking to unintended parties. For example, a SAML assertion can be encrypted using XML-Encryption, or an OpenID Connect ID Token can be encrypted using JSON Web Encryption (JWE).”  

Check out Signicat’s page to learn more about the formatting and to see examples of SAML Request and SAML Response examples. 

How SAML Authentication Works in Single-Sign On 

To better understand how this works, let’s consider a couple of example scenarios of SAML authentication, using your organization as an example. Imagine that one of your employees wants to use one of the apps that’s available in their employee portal.  

One option is to go to the service provider’s website directly and login there by setting up yet another unique username and password (one of about 100 passwords NordPass says the average user has to continually manage). This non-SAML process involves a user entering those credentials, which involves the web app looking up their individual usernames in a database, hashing their password, and seeing if it matches what’s stored for that user. 

Then, if the user wants to use another authorized application, they’ll have to rinse and repeat the process with that separate vendor or application.   

Alternatively, they can attempt to initiate SAML authentication once, in one of two ways, using SSO:  

	Scenario #1: Service Provider Initiated (Also Called SP Initialized) SSO	Scenario #2: Identity Provider Initiated (Also Called IDP Initialized) SSO
What the User Wants to Achieve	An authorized user wants to connect to their company’s HR app to put in a leave request.	An authorized user wants to connect to the trust store directly to streamline the authentication process.
How the User Accesses the App	The user initiates communication with the Service Provider (SP) directly via their browser.   The user signs into the service provider’s system or application using a traditional username-password combination.	The user authenticates directly with the Identity Provider (IDP) using their login credentials via their browser.   (NOTE: This SAML Request step doesn’t exist in this scenario.)
A Look at What Happens Behind the Scenes (1 or 2 Steps)	Step One: The browser’s action triggers the SP to send an unauthenticated SAML Request to the Identity Provider (IDP) via the web client.   Step Two: IDP sends a login URL to the browser and has the user sign in via their login credentials. The IDP parses the request and authenticates the user.   Step Three: The IDP then creates a session and sends a message (SAML Response) to the SP via their browser.	Step One: In response to the browser’s prompt, the IDP sends a SAML Response message to the Service Provider (SP) or App the User Is Trying to Access.   The IDP informs the SP that the user’s credentials are valid.
The Final Result	If the user’s digital identity is successfully verified, they’ll be logged in and can access the authorized digital resources.	The user, once authenticated, will be logged in and can access the authorized digital resources.

Here’s a basic overview at how both of these scenarios play out: 

In SP-initiated SSO, the user will try to access the app directly using their browser. That app will reach out to the IDP to ensure the user is who they say they are. Once their identity has been verified and they’ve been authenticated, their browser will be directed to the app.  

With IDP-initiated SSO, as far as they user is concerned, they’ll simply enter their login credentials, and something (unseen) will happen in the background that gives them access to the company’s email client, JIRA, or whatever other digital tools and services they’re authorized to use.  

To the user, it’s practically magic, but after reading this article, you now know better.  

Which Approach to SAML Authentication Should You Use? 

The answer to that question is the dreaded response everyone hates to get: “it depends.” But the reason we say that is that there are pros and cons to both methods for SSO, and it also varies based on how you have systems set up within your organization.  

What we will say is that commercial applications often use SP-initiated SSO. However, it’s also common in SaaS scenarios to use IDP-initiated SSO because it streamlines the process by removing a step.  

As such, the answer of whether to use SP-initiated or IDP-initiated varies depending on your organization. So, do your research to figure out what works best for your specific needs. 

TL;DR: The Highlights of SAML Authentication in 20 Seconds 

Security Assertion Markup Language (SAML) authentication is both the framework and protocol that has served as the foundation for most single sign-on (SSO) technologies for the past ~20 years. SAML authentication:  

• Facilitates secure user authentication.  
• Streamlines the authentication process in SSO (i.e., enables users to authenticate once at a central point and enjoy the benefits of being able to access all of the tools or services they’re authorized to use). 
• Relies on public key cryptography (and its roots in PKI) to digitally sign and encrypt SAML assertions.  
• Provides greater security by having users authenticate using a trusted identity provider.  

Final Takeaways on SAML Authentication  

As we’ve learned, SAML is a trusted framework that many businesses the world over rely on for transmitting sensitive and private user data for SSO. Using public key cryptography, it lays the groundwork for securely communicating attributes and personal identifying data between service providers and identity providers.  

We hope you’ve found this information informative and useful. If you have additional thoughts or insights to share, we invite you to do so in the comments below.   

• #SAML Authentication