“Security Assertion Markup Language” (SAML) is a type of single sign-on (SSO) standard. It defines a set of rules/protocols that allow users to access systems and applications with a single login, especially for cloud-based resources. This is possible because those resources all trust the systems that verify users’ identities. Within SSO protocols, the resources are referred to as “service providers” (SP), and the systems that verify a user’s identity are referred to as “identity providers” (IdP).
SAML is one of the dominant standards in the world of federated identity management (FIM), offering single sign-on capabilities across the web. Other standards include OpenID, OAuth, and JWT (JSON Web Tokens). Each standard was created and maintained, by separate organizations. SAML was created by OASIS, for example.i Those organizations have different ideas on how to best implement SSO, which technologies and languages to use, and so on. Despite their technical differences, all of these standards share at least two common goals:
- Provide a pleasant user experience by granting quick and easy access to applications with a single login.
- Enhance security by eliminating the need for applications to store copies of user credentials in their own databases.
Both of these are straightforward and worthy goals for the current age of business and technology. Continue reading to find out how SAML achieves these goals, and how it can play a role in your organization’s federated identity management strategy.
SAML Providers
In order to fully understand how SAML works, we’ll start by exploring the concept of a “SAML provider”. A SAML provider is any server that is involved in the authentication and authorization of a user during a SAML request. More specifically, the two types of SAML providers mirror those in any other SSO exchange: service providers (SP) and identity providers (IdP).
Service Providers (SP)
SPs are the systems and applications that users access throughout the day. Before SSO, each of them would maintain their own database of usernames and passwords. The more applications a person used, the more usernames and passwords they would need to remember and manage. This increase in the number of credentials per user incentivized undesirable password management practices, from using the same password across multiple websites and services to even writing passwords down on sticky notes.
With the advent of SSO standards like SAML, users don’t need to remember numerous passwords. They only need to log into their IdP a single time, and are immediately granted access to their connected applications. Authentication from that point on is automatic and transparent to the user.
Identity Provider (IdP)
An IdP is the system that performs user authentication. This is the central location where user credentials are actually stored and validated. Once a user logs into their identity provider, they have access to their SSO-enabled applications. When a user opens an application, the IdP and the SP work together to authenticate and authorize the user, granting them access if appropriate.
SAML Assertions
The conversation that happens between an IdP and SP is done through a message called an “assertion”. A SAML assertion is the message that the identity provider sends to the service provider. This is an XML (i.e., extensible markup language) document that is created by the IdP, verified by the SP, and contains all of the user’s identity details relevant for authentication. This includes their unique identifier, their name, and any additional attributes that may be required by the SP. Assertions are sometimes referred to as “claims” and both terms can be used interchangeably.
An assertion is constructed according to the SAML standards laid out in 2005 when the SAML2 standard was finalized by the OASIS consortium.ii Assertions are signed with an X.509 certificate by the identity provider. The service provider has a copy of the certificate’s “fingerprint”, which it uses to verify the authenticity of the assertion. This prevents malicious attackers, who do not have the certificate, from forging assertions and gaining unauthorized access.
SAML Authentication Example
Let’s follow a fictional employee, Bob Johnson, from his arrival at work to the launch of his first SSO-enabled application. This will give us a good idea of how SAML, and SSO in general, functions on a day-to-day basis.
After getting his morning cup of coffee, Bob sits down at his desk and logs into his SSO portal. Bob’s SSO portal serves as the identity provider in this simplified example. On the portal, Bob is presented with the numerous applications that he needs to perform his job.
Bob opens Salesforce by clicking on its icon in the portal. This is where the SAML authentication process begins.
First, Bob’s request is routed to Salesforce, the service provider. Salesforce responds, requesting authentication from the identity provider (Bob’s SSO portal). The IdP then builds a SAML Assertion that contains Bob’s user information, such as his email address and name. The IdP then signs it with a certificate that it has on file and sends the assertion to the SP.
Once it receives the SAML assertion, the service provider (Salesforce) uses its copy of the certificate’s fingerprint to verify that the assertion is valid. If it’s valid, and Bob has an active account, he will be logged into Salesforce.
This exchange that authenticates Bob’s identity to Salesforce happens in the background in a matter of milliseconds. All Bob experiences is the ease of gaining access to his applications with a single click, and the joy of not needing to remember many different usernames and passwords.
What can SAML do for You?
SAML (and any other federated identity technology) serves to make the lives of users easier and more secure. Without it, users are forced to manage different credentials for every system, application, and website that they use. Such a massive collection of credentials remains difficult to manage—at best leading to forgotten passwords and halting productivity, at worst opening users and their organizations up to malicious attackers and identity theft.iii
By introducing a comprehensive single sign-on solution to your organization, its end users will have streamlined access to the applications they need on a daily basis. This reduces downtime caused by forgotten passwords and locked accounts, which translates directly into higher productivity and increased morale. All of this can contribute to a positive effect on a company’s bottom line, making an investment in single sign-on solutions a clear winner in terms of ROI.
i. https://www.oasis-open.org/
ii. https://www.oasis-open.org/standards#samlv2.0
iii. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.465.1633&rep=rep1&type=pdf