Learn SAML: The Language You Don't Know You're Already Speaking

Security Assertion Markup Language (SAML): You may have heard of it. You've likely used it at least once today to log into a website portal or enterprise application. But what is SAML? How does it work? And why do you need to know about it?

Figure 1: (Source: Mykyta via Adobe Stock)

What Is SAML?
SAML is an XML-based standard used to authenticate into Web applications like Box, Microsoft 365, Salesforce, and Gmail for Business. The protocol handles federation, identity management, and single sign-on (SSO). Identity federation enables user identities to be stored across apps and businesses; with SAML, these apps and businesses can trust each other's users.

What Problem Does It Solve?
Most apps have a database or Lightweight Directory Access Protocol (LDAP) to hold users' profile data and credentials, along with any additional data needed to verify a user. When someone signs in, this data store validates the credentials and logs them in. However, when a person has to log into multiple apps and each requires different credentials, it becomes an issue – for users who have to remember all their credentials, and for the admins who maintain and revoke them. Enter SAML.

SAML streamlines the authentication process for signing into SAML-supported websites and applications, and it's the most popular underlying protocol for Web-based SSO. An organization has one login page and can configure any Web app, or service provider (SP), supporting SAML so its users only have to authenticate once to log into all its Web apps (more on this process later).

The protocol has recently made headlines due to the "Golden SAML" attack vector, which was leveraged in the SolarWinds security incident. This technique enables the attacker to gain access to any service or asset that uses the SAML authentication standard. Its use in the wild underscores the importance of following best practices for privileged access management.

A need for a standard like SAML emerged in the late 1990s with the proliferation of merchant websites, says Thomas Hardjono, CTO of Connection Science and Engineering at the Massachusetts Institute of Technology and chair of OASIS Security Services, where the SAML protocol was developed. Each merchant wanted to own the authentication of each customer, which led to the issue of people maintaining usernames and passwords for dozens of accounts. 

"The whole password problem is a 30-year-old problem," Hardjono says. "The idea of SAML was, could we create a special entity, called the identity provider, that would essentially be the authentication entity?" 

Who Are These Identity Providers?
An identity provider (IdP) is tasked with verifying users' identities and communicating with the SP to log them in so they can access more resources with fewer logins. There are several IdPs in today's market: Okta, OneLogin, Microsoft Active Directory Federation Services, Duo Access Gateway, and Ping Identity are a few popular ones. SAML was needed to express that the IdP authenticated a user.

Hardjono calls the interaction among SP, IdP, and user "a triangular flow or relationship." Read on for more details on how this relationship works.

How Does SAML Work?
SAML works by allowing SPs, or applications, to delegate their authentication to a separate, dedicated service, or IdP.

SPs are configured to trust specific IdPs in the federation process. It doesn't matter to the AP how the IdP checks a user's identity; it only cares that the user is verified. The user only needs one username and password, which is managed by the identity provider.

John Maguire, senior software engineer at Duo Security, puts this into the context of logging into a conference call. An employee clicks the link to log into a Webex meeting. When they land on the Webex page, they're going to look up which IdP is used to authenticate — something the business has preconfigured, he adds.

Webex then redirects the user to their IdP, along with a message asking to authenticate them. The IdP has several methods for doing this: It could check a user's credentials and account status, the device used to access the application, or the network a user is on. It could invoke multifactor authentication. The user's employer configures the steps taken to verify their identity.

"Those all go into determination of either what level of authentication it should use — just first factor, first factor and second factor, [and] whether it should let you authenticate at all," Maguire adds. If an IdP notices the location is off, for example, it may deny a user's authentication. 

The IdP verifies this data and creates a message, or SAML assertion, which validates a user's identity and attributes, and uses cryptographic signing to prove their authenticity. The IdP then sends this data via browser redirects to Webex, which validates the signature and checks the user's identifying data before authenticating them into the application.

"All of this communication is actually passed back and forth using the user's browser," adds Jamie Pringle, also a senior software engineer with Duo Security. "The two sides never directly talk to each other." 

Oftentimes there will be multiple SPs configured to one IdP. In these cases, an authenticated user may see a dashboard with other service providers they can access for the following six hours — or however long the session is configured to last.

There are two types of workflows for SAML-based authentication. In an SP-initiated process, a user tries to log into a service provider's Web portal. Instead of requesting credentials, the site will redirect to its IdP with a SAML request for authentication. In an IdP-initiated process, the user logs into the IdP and is authenticated and then sent to the SP with a SAML assertion. Some SPs don't support an SP-initiated process. In this case, an IdP-initiated workflow is the only option.

How Do Businesses and Admins Benefit from SAML?
Since it was first developed, SAML has become the standard for Web-based single sign-on. It quickly caught on among businesses, who internally began to use the protocol for employees.

"As access management started gaining more relevance, because more and more companies were accessing applications outside their network … SAML became very important to the corporation and to the people who need to provide SSO," says Michael Kelley, senior research director in Gartner's Secure Business Enablement Group.

The benefits are clear for both users and admins. Individuals don't have to enter credentials into the application itself and undergo a more secure login process overall, explains Aaron Parecki, senior security strategist at Okta. Once they're authenticated, they can transfer back and forth between apps without the hurdle of logging in several times.

"This is a great way to have a more secure experience as a user because you only ever enter your credentials into the server that has your credentials — the place where the account lives," he says. "If you want to log into an application, you don't have to trust that the application is going to handle your credentials properly."

(Continued on page 2 of 2)

SAML also gives power to admins, who benefit from a single access point to implement security controls across apps, adds Duo's Maguire. Instead of worrying about 20 different apps and their authentication measures, admins configure the IdP to verify all employees' identities. This lets admins add policies to services which don't already support them, such as MFA, he points out. It also gives them a single point to audit or to investigate a potential account compromise.

While SAML has proved simple and straightforward to implement and secure for both users and businesses, it also has drawbacks that become more prominent as new tech emerges. 

"It does have some gaps; it lacks some features and functionality that other newer, modern protocols have," Kelley adds. "But it's straightforward, it's secure … as long as you have a Web-based app that can natively support it, then you're in great shape." 

What to Know About 'Golden SAML' and SolarWinds 
You may have recently heard about SAML in relation to the SolarWinds security incident, which drew attention to the "Golden SAML" attack vector. In this type of attack, when a user attempts to access a service and their request is redirected to Active Directory Federated Services, the attacker forges a signed SAML response using a stolen key to gain unauthorized access.

Golden SAML lets adversaries gain persistent access to any application that supports SAML authentication. While experts emphasize the attack does not rely on a flaw in SAML, Gartner's Kelley notes this could inspire other attackers to seek the sensitive information for a similar attack. 

"It wasn't SAML that was breached, it was privileged credentials," he explains. "Capturing those privileged credentials allowed these hackers to issue valid SAML certificates. When you think about it that way … if you don't have a good handle on privileges in the environment … bad actors could potentially follow [this] approach." 

SAML itself is pretty secure. Many issues related to SAML can be traced to misuse or misconfiguration of the protocol, Hardjono points out. A new developer may forget to implement a feature, for example, or a SAML working group hasn't fully implemented the spec.

"The hardest part of SAML is configuring it," says Maguire, noting this is targeted at admins. "Every application that you want to log into wants just a little bit different information about the user." Maybe it wants a username, maybe an email address, or perhaps both, but named in a specific way.

An issue with SAML is its spec is pretty big and not very strict, leading to implementation differences among different service providers, adds Pringle. Some SPs provide vague documentation for how to configure SAML, making it difficult to properly implement. There are key pieces of information that must be filled out to send the proper SAML message, he says.

"Being an identity provider, we've seen that different service providers take different interpretations to some of these loosely defined areas, and so that can sometimes cause interoperability headaches," he explains, noting that IdPs can make a similar mistake. 

The consequences of misconfiguration range depending on the SP's implementation. Users could be logged out, fail to authenticate, or log in to see incorrect information. In some cases, users could be locked out of their accounts and need to contact the SP if something breaks.

New Tech, New Standards: SAML vs. OAuth and OIDC
SAML was one of the early standards to solve the problem of Web-based authentication, and, as such, it has become very widely used. Most cloud services that sell to businesses will allow them to federate with SAML; most IdPs have catalogs of apps that are already integrated. 

SAML is part of a larger family of modern identity protocol, which also includes standards such as OAuth and Open ID Connect (OIDC). OAuth is for authorization; this lets apps take actions or access resources on a user's behalf without needing their credentials. OIDC, built on top of Oauth, is an open standard that businesses use to verify users' identities. Okta's Parecki calls it "the modern version of SAML." 

"There's been a lot of fundamental changes in technology that SAML hasn't evolved to address," he says, noting that OpenID Connect, for example, has been designed to adapt to mobile phones and is built on JSON instead of SAML's XML. "I think you'll very quickly hit the limits of what SAML is useful for when trying to apply it in a modern technology stack."

SAML may have addressed SSO, says Parecki, but it wasn't built for the API-driven world we live in today. Modern apps not only need to know who just logged in; they will also need to access an API – something he notes OIDC and OAuth already do more efficiently. 

"Everything is driven with APIs," Kelley adds. "That's how developers like to develop things ... API-driven interactions. They prefer to head down that path of developing an application to communicate with APIs for authentication … as opposed to just through the browser." 

The added features and functionality of OAuth and OIDC increase its complexity, he notes. SAML, in comparison, is simpler but lacks the additional capabilities of API-driven processes. While he thinks adoption of OAuth and OIDC will increase, Kelley anticipates it'll be another eight to 10 years before they become more common than SAML. 

Further Reading
These links contain more handy information on SAML and the details of how it works: