SAML (Security Assertion Markup Language) is an XML-based protocol used for exchanging authentication and authorization data between parties, specifically between an identity provider (IdP) and a service provider (SP).
It is used to enable Single Sign-On (SSO). Single Sign-On (SSO) is an authentication scheme that allows users to access multiple applications with a single set of login credentials. This article goes into depth about the SAML and it’s authentication flow for SSO.
(Related Article: To learn more about SSO and it’s benefits click here)
What Companies are using SAML for SSO?
SAML has become a widely adopted standard for enabling secure and efficient SSO, making it an important component of many modern IT environments. Many companies and organizations use SAML for their Single Sign-On (SSO) solutions. Some of the most well-known companies that use SAML include Google, Salesforce, Microsoft and many more.
(Related Article: To find out what all companies are using SAML for SSO, click here)
What is a Service Provider and an Identity Provider in SAML?
A typical SAML flow involves commuication between three entities:
1) Browser:
This is the browser the user uses to access the resources required.
2) Service Provider (SP) :
Service provider is simply the entity providing the service the user is looking for. So, for example the user wants to log into his workday profile, then workday is the service provider. If he wants to check his mail on Gmail, Gmail becomes the service providers.
In other words, a Service Provider in SAML terms is the entity with the protected resource the user wants to access.
Service Providers that support SAML SSO include popular web applications such as Salesforce, Google Apps, Dropbox and many other enterprise-level software. If you want to read more about the companies using SAML, click here.
3) Identity Provider (IdP) :
An Identity Provider is a trusted system responsible for authenticating users and generating a SAML Assertion.
When a user triess to access a Service Provider, he is redirected you to the Identity Provider. The Identity Provider asks the user for his credentials and authenticates the user. If the user is authenticated, a SAML Assertion is created and sent back to the Service Provider.
What is a SAML Assertion?
A SAML Assertion is a encrypted and digitally signed XML document that contains information about a user’s identity and authentication status. It contains sensitive user information such as their name, email address, membership, their authentication details ( for example: the time and method of their authentication).
It also contains the user autherisation information(what the user can and cannot access).
The SAML assertion is generated by the Identity Provider and sent to a Service Provider that requested the authentication. The Service Provider then uses the information in the assertion to grant the user access to a protected resource along with permission to perform specific actions within the application.
What is the SAML authentication flow?
Here’s what a typical SAML authentication flow looks like:
- The user attempts to access a service provided by the service provider.
- The service provider sends a SAML request to the browser.
- The browser redirects the user to the identity provider.
- The identity provider authenticates the user and generates a SAML response. The SAML response contains information about the user’s identity, such as their username and email address, as well as any attributes or roles that have been assigned to them. This information is encrypted and signed by the identity provider to ensure its authenticity.
- The service provider then validates the SAML response and grants the user access to the requested service.
- The user can continue to access other services or applications without having to log in again, as long as they are all part of the same SAML-based SSO system.
To understand this better, let’s take an example:
In this example, Gmail is a service provider.
1. A user opens a browser window.
2. User then sends request to login to his Gmail account with the user id “john@twillo.com”
3. The Gmail server provider detects that the user is from a work domain and returns a SAML authentication request back to the browser.
4. The browser then redirects the user to the identity provider for the company specified in the SAML authentication request.
5. The identity provider shows the login page where the user enters the login credentials.
6. The browser sends the login credentials to the Identity Provider.
7. The Identity Provider uses the credentials to authenticate the user. Once the user is authenticated, the identity provider generates a SAML assertion. This SAML Asserion is then returned to the browser.
8. The browser forwards the signed SAML Assertion to the service provider.
9. The service provider validates that the assertion was signed by the Identity Provider. This validation is usually done with public key cryptography.
10. The service provider returns the protected resource to the browser based on what the user is allowed to access as specified in the SAML Assertion.
Now, let’s see what happens when the user navigates to another SSO integrated application, say workday:
The workday sever (as in the case with Gmail) detects the work domain and sends back an SAML authentication request back to the browser.
The browser again redirects the user to the identity provider.
Since, the user has already logged in with the identity provider, it skips the log-in process and instead generates SAML assertion for workday, detailing what the user can access there.
The SAML assertion is returned to the browser and forwarded to workday. Workday validates the signed assertion and grants the user access accordingly. This way the user only has to login once and is then able to access multiple web applications.