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.
These links contain more handy information on SAML and the details of how it works: