SAML authentication is a must for organisations that want to do federated identity and single sign-on. These applications require both sides of the service or application to use a common set of credentials for identification and authorization. This is an effort to reduce security risks, increase the availability of services through more robust authentication, improve reliability by leveraging existing investments in infrastructure, and improve the end-user experience. This blog will cover the basics of SAML authentication, how it works, SAML examples, and the differences between OAuth and LDAP.
What is Security Assertion Markup Language (SAML) authentication?
LDAP, RADIUS and SSH are traditional network-based authentication protocols that many IT administrations or engineers are quite familiar with. However, as the advancements in technology continue and organisations are looking into transition to cloud-based infrastructure, a new process for authentication called Security Assertion Markup Language SAML is introduced.
SAML is a standardised process to authenticate users into web applications over the web. SAML uses the Single Sign-On (SSO) technology to authenticate a user once and then use that authentication over multiple applications. SAML enables identity federation, making it possible for identity providers (IdPs) to seamlessly transfer authenticated identities and their associated attributes to service providers (SPs). Using SAML federated apps and organisations can communicate and trust one another’s users. SAML also provides a way to authenticate users into third-party applications such as Gmail for business, Office 365, Salesforce etc.
SAML is a framework that can authenticate users over the web by having them verify their identity through various means such as entering credentials or clicking on a link sent in an email. The Internet Engineering Task Force (IETF) developed the SAML protocol for authentication and has been accepted as one of the industry standards for software-based single sign-on (SSO). This makes SAML very attractive since it helps companies avoid building proprietary solutions with different vendors and instead work together using open specifications. Due to its ease of integration, you may want to consider implementing this solution if your organisation needs a centralised approach without a large attack surface while maintaining usability across platforms.
What is single sign-on (SSO)?
Single Sign-On allows users to be authenticated in multiple applications and services using a single set of credentials. Using SSO, a user signs in once on a login screen using their credentials and then can use several applications. The user does not have to confirm their identities for every application or service.
For all these mechanisms to work properly, the SSO system communicates with every external application and notifies them that the user is currently logged in; SAML comes into play.
Terminologies to know about SAML
When learning about SAML, there are few common terminologies that one must understand before moving forward; these include:
Identity Provider (IdP)
This software performs the authentication process by validating credentials, verifying account status and invoking multi-factor authentication.
Service Provider (SP)
The service provider is the resource or web application where the user wants to login.
This is a message sent over HTTP via browser redirects asserting the user’s identity and other attributes.
What is SAML used for?
Implementing SAML simplifies the process of federated authentication and authorisation for users, identity providers and service providers. This provides a centralised user management solution where the service providers and identity providers can exist separately.
When a user logs into a SAML enabled application, the first step is that the service provider requests authorisation from the relevant identity provider.
The identity provider then authenticates the users and returns the authorisation for the service provider. After that, the user can access the application.
What is a SAML Provider?
As the name suggests, a SAML provider is a system that helps users access the services they need. There are types of SAML providers, Identity Providers (IdPs) and Service Providers (SPs).
A service provider is basically the web application or service that the user needs access to; the SP needs the authentication from IdP to grant authorisation to the users.
On the other hand, the identity provider carries out the validation and verification of the user’s credentials and authenticates them. After verification, the data is sent to the service provider and the user’s access rights for the service in question.
Examples of identity providers include Microsoft Active Directory or Azure AD, whereas service providers include Salesforce and other CRM solutions.
What is a SAML Assertion?
A SAML assertion is an XML document that the identity provider sends to the service provider. This document contains information about the user’s access rights and authorisations.
There are three types of SAML assertions:
This document provides proof for the user’s identification, the time the user logged in, and the authentication method they used (e.g. Kerberos, Two factors, etc.)
The attribute assertion is used to pass the SAML attributes to the service provider. This is specific information that provides information about the user.
This assertion notifies the service provider. The identity provider generates the SAML response and returns it to the user’s browser. The browser sends the generated SAML response to the service provider’s web application which verifies it. If the verification succeeds, the web application grants the user access.
How SAML Works
As mentioned above SAML enabled applications work bypassing or transferring the user’s identity from one place, i.e. the identity provider, to another place, i.e. the service provider, using digitally signed XML documents.
To understand how SAML authentication works consider the following scenario; a user logs into a system (SAML identity provider) and wants to access a remote application such as an accounting application (service provider).
To grant the user access to this application, the following steps take place:
- The user accesses the remote application via a link.
- The application identifies the user’s origin (i.e. IP address, application subdomain etc.) and redirects the request to the identity provider for authentication.
- The identity provider checks if the user has an existing browser session; if not, then the identity provider asks for the user credentials.
- After verifying the credentials, the identity provider builds the authentication assertion XML document containing the user’s username and password. This is signed using an X.509 certificate. The XML document is then sent to the service provider.
- The service provider receives the XML document and verifies the digital signature.
- Depending upon the message received, the service provider either grants access to remote applications to the user or denies the access.
Consider the following example of an employee accessing a CRM. This SAML example concerns a user’s experience.
- Bob (user) logs into the SSO at the start of this office day.
- Bob then tries to open the webpage to his CRM.
- The CRM (a service provider) checks for Bob credentials with the identity provider.
- The identity provider validates the credentials and sends the authorisation and authentication messages back to the CRM.
- The CRM receives these messages and grants Bob access to use the CRM and complete his tasks.
SAML SSO Flow
The diagram below illustrates how the flow for a service provider Single Sign-On will be:
IdP-Initiated vs SP-Initiated
IdP-initiated and SP-initiated refer to the provider where the authentication workflow starts from. An IdP-initiated login starts with the user navigating to the IdP (typically a login page or dashboard). The IdP then sends the request to the SP with a SAML assertion.
On the other hand, an SP-initiated login starts with the user navigating to the SP, where the SP redirects the user to the IdP with a SAML request, and later the IdP redirects the user back to the SP with a SAML assertion.
IdP-initiated SSO with SAML Authentication
In an IdP-initiated SSO, the user first navigates and logs in to the identity provider. This type of workflow is commonly found in workforce SSO solutions.
After the user enters their credentials in this workflow, the IdP takes the user’s identity, and any other attributes needed and constructs the XML based SAML assertion.
The XML assertion document is then digitally signed using a pair of public and private keys already exchanged between the IdP and SP when the SSO partnership is configured.
The IdP then sends the signed assertion to the SP, where it is verified and the SP either grants or denies access depending upon the contents inside the assertion.
SP-initiated SSO with SAML authentication
SP-initiated SSO is when a user directly tries to access the resources provided by the service without going through the authentication process.
In such cases, a user might try to access an authenticated web page directly or clicks on a link to a specific resource. Because the user is not authenticated with the SP and does not have an active session, the SP redirects the user to the IdP for authentication.
The IdP then asks for the user’s username, and password validates the credentials and builds the assertion. Then the IdP sends the assertion to the SP and redirects the user back to the SP along with the URL of the resource the user was trying to access.
The remaining steps are the same as with the IdP-initiated SSO; the SP receives the SAML assertion and verifies the digital signature. The SP then either grants or denies access depending upon the contents inside the assertion.
Advantages of SAML authentication
There are many advantages when it comes to choosing SAML; a few of these benefits are described below:
- Enhanced user experience — Since SAML provides its users with SSO authentication, the users only need to sign in once and can access multiple service providers. This creates a faster, more seamless authentication process.
- Improved security — By using SSO, SAML provides a single point of authentication, which is carried out at the secure identity provider. The user credentials are not transferred to any other service or server except the IdP.
- Loose coupling of directories — Unlike other authentication mechanisms, SAML does not require that the user information be synchronised between multiple directories.
- Reduced costs for service providers — The account information is maintained and stored with the identity provider; this eliminates the need to manage multiple services.
What is SAML 2.0?
SAML 2.0 is the latest and modern version of SAML. As of now, the majority of the applications work with SAML 2.0. This is the combination of several previous versions of SAML.
For backwards compatibility, some applications still use SAML 1.1, but SAML 2.0 is the modern standard.
What is OAuth, and how does it work?
The term “auth” can mean either Authorisation or Authentication, but in the case of OAuth protocol, authorisation is being considered. The OAuth protocol allows one to pass authorisation from one service to another without sharing the user’s credentials. Using OAuth, users can sign in on one platform and then be authorised to view and perform tasks on another platform.
A common example of OAuth that users can see every day is the “Sign in with Facebook” or “Sign in with Google” option web applications provide on their user sign up pages.
For OAuth, the workflow is:
- Request: The user clicks on the button to sign in to an application using a third-party platform.
- Choice: The user chooses which third party credentials to use.
- Log in: The user logs in to the third-party application; this creates an authorisation token sent back to the original resource server.
- Connection: The resource server verifies the authorisation token and grants the user access to the application.
How do OAuth authorisation tokens work?
Let’s explain how the authorisation tokens work with OAuth using an example. Consider a company employee Bob. At the start of the day, Bob signs in using his company’s SSO system; at the end of his day, he wants to access the company’s file storage application, which he did not access all day.
When Bob opens the files storage application, instead of simply giving him access, the application sends an authorisation request for Bob to the SSO system. Because Bob is already authenticated with the SSO, the SSO will send the OAuth authorisation token in response.
This token contains the needed permissions and privilege information about what access Bob should have in the application. This token has an expiry time, and after the time limit is reached, Bob would have to sign in with the SSO again.
OAuth vs SAML – Their similarities and differences
When it comes to OAuth and SAML, both of these solutions provide their users ease of use and save companies and users alike from managing a never-ending list of usernames and passwords.
OAuth and SAML streamline the authentication process for customers and users, save them from hassles, and allow for an easy onboarding experience. For the IT admins using these mechanisms results in faster integration, fewer overheads and a centralised login process.
But there is a basic fundamental difference between what these two technologies actually accomplish. SAML deals with Authentication, where a user has to prove their identity and verify they are who they say they are.
Whereas OAuth deals with Authorisation, a step that comes after authentication, where the permission, privilege and access rights of a validated user are determined.
When to use what: SAML or OAuth?
As mentioned earlier, both OAuth and SAML serve very different purposes. One aids in authorisation decisions, while the other offers an authentication mechanism. So it is safe to say that they are not alternatives of each, but rather can be used together.
Typically in a Microsoft environment, OAuth handles the authorisation, and SAML takes care of the authentication.
What is LDAP?
The Lightweight Directory Access Protocol (LDAP) is a cross-platform vendor-neutral software protocol used for directory service authentication. For simplicity, imagine LDAP as an extensive virtual phone book. The phone book gives access to a large directory of contact information for hundreds of people. Using LDAP, it is easy to search through the phone book and find whatever information is needed.
LDAP maintains directory information in an organised and easy to search manner; it allows anyone to query and communicate within the directory service servers and locate data related to the organisation, users, devices and other resources such as files in a network.
LDAP vs SAML – Their similarities and differences
LDAP and SAML both provide authentication mechanisms for their users. They are implemented so that users can access the resources and services required to perform their daily tasks. More often than not, in many organisations, both LDAP and SAML are used together and are key processes for identity management.
The difference between these two lies in the environments and infrastructure they are used in. LDAP is more focused on facilitating “on-premises” or “on-prem” authentication and other server processes. At the same time, SAML is more aligned towards serving authentication facilities to web applications and cloud services.
SAML is an essential part of modern life – it’s everywhere and permeates our daily lives. It’s the technology behind Facebook Connect, meaning when you sign in with an account from a different website using Facebook, you’re really just authenticating against Facebook and then allowing that site access to your information via the SAML protocol. It’s how we log into the various office portals, and it’s what enables single sign-on on many websites, including some big names.
But without painting a scary picture, if the implementations aren’t done right – there are always gaping loopholes that could be attractive to threat actors. Ensure that your choice of authentication mechanisms, frameworks, and implementation follows secure coding practices.
Get in touch for independent validation of your application security controls before it’s too late.