In our blog, we often touch issues of data protection and authorization. For example, we talked about the new WebAuthn passwordless authorization standard and even interviewed one of its developers. Also was discussed DANE technology for DNS domain name authentication. Today we’ll talk about the SAML 2.0 protocol and those who use it.
What is SAML
SAML is an XML-based markup language that is a base of Single Sign-On (SSO) technology. It gives users the ability to switch between applications (for example, corporate) with a single login / password pair.
Using the SAML protocol, account providers (IdP, or identity provider) and service providers (SP) interact with each other to securely transfer the identity of application users. The role of an account provider can make the Active Directory and even a simple SQL database with logins and passwords. A service provider can be any web application in which a user wants to log in (of course, supporting SAML).
In general, the authentication process consists of the following steps:
- The user asks to authorize it in the application from SP.
- The service provider requests a login confirmation from IdP.
- The account provider sends a special SAML message in which it says that the credentials are correct or incorrect.
If the data is correct, the provider will authorize the user.
Who implements it
The latest major update to SAML, SAML 2.0, was published in 2005. And since then, the protocol has become quite widespread. It is supported by services such as Salesforce, Slack, and GitHub. It is even used by the ESIA information system for authorization on State services.
It would seem that in such a long time the protocol should have become something usual, but recently it has been raising interest again – a large number of articles have been published about this topic, and there is an active discussion on social networks. SAML was also launched by IaaS providers.
For example, not long ago, SAML introduced the Azure Active Directory Proxy Service, a tool for gaining remote access to web applications. According to some experts, the service development company decided to use this protocol, since it provides more reliable SSO login protection for large companies than alternatives like OAuth.
In July, it also became known that SAML appeared in the AWS cloud. The company hopes that by this way customers will spend less time on authorization and will be able to focus on solving critical business problems.
Not only cloud providers, but also non-profit organizations pay attention to the protocol. A couple of weeks ago, the Public Safety Technology Alliance (PSTA), which promotes technology for public safety, recommended for its partners to implement authorization based on SAML 2.0 and OpenID. Among the reasons were highlighted: the maturity of technologies, their prevalence and reliability.
Opinions about protocol
First of all, SAML-based solution integrators note that the protocol simplifies the work of system administrators in large companies. They don’t have to keep track of dozens of passwords for different corporate applications for each employee. It is enough for the administrator to assign each employee only one unique username / password pair for single sign-on to all services. This approach provides another advantage: if an employee leaves the company, it is enough to cancel his identification data for single sign-on. But there are also negative sides.
For example, among the shortcomings highlight excessive complexity. SAML is built on the basis of XML, so it is syntax-intensive. Plus, the protocol has a large number of optional components, which greatly complicates the configuration of SSO.
Although security experts consider the SAML protocol to be fairly reliable, there are concerns about vulnerabilities in hotel libraries for SSO operations. Last year, security engineers at Duo Labs found an XML comment processing bug. By modifying the username field in a SAML message, an attacker can impersonate another user. However, an important condition for carrying out an attack is having an account on the victim’s network.
In any case, this vulnerability can be mitigated (for example, by using of a white list of mail addresses and domains for registration on the network), so it should not affect the further spread of technology among IT companies and cloud providers.