SAML basics – How SAML Authentication Works
This article covers the basics of SAML authentication, how it works behind the scenes, the benefits of using SAML authentication and how it streamlines user access to your organization’s applications.
What is SAML authentication?
Introduced in 2001, Security Assertion Markup Language (SAML) is an XML based protocol used for single sign-on (SSO) authentication and authorization to web-based applications.
To support SSO, SAML allows web-based applications to communicate with each other. The applications share information to determine if users are authenticated to one application, thus allowing them to access another application without having to share the local identity database.
What are the SAML main components?
SAML has the following main components:
1. Client
The user trying to authenticate into a web-based application.
2. Identity Provider (IdP)
The server or authorization authority that the client ultimately authenticates with. It holds the client’s credentials. Example:
When you log in to an application using Gmail credentials, Gmail is the IdP.
3. Service Provider (SP)
The web-based application that the client tries to access. Example: When you log in to GitHub using your Gmail credentials, then GitHub is the SP. SPs do not authenticate the user but delegate the task to the IdP.
4. Identity Management Service/Single Sign-On (IDM/SSO) Service
The service that enables communication between the SP with the IdP, allowing clients to access a service using a single account.
How does SAML Authentication work?
The key to SAML basics and SAML authentication is browser redirects. Let us consider an example of a user (client) trying to authenticate to GitHub (SP) using Gmail credentials (IdP). There are two ways using which SAML authentication is initiated: SP-initiated and IdP-initiated.
SP-Initiated:
- The client tries to authenticate to a protected resource directly on SP (GitHub) without the IdP being aware of the
attempt.
- The SP redirects the client to IdP (Gmail) for authentication. There are two situations in this case:
- If the client has already authenticated, the IdP grants access immediately.
- If the client has not been authenticated, they need to enter their IdP credentials for authentication to access the SP.
- The client can now access the protected resource on SP.
IdP-Initiated:
- The client tries to authenticate to SP (GitHub) and selects the option to be authenticated via IdP (Gmail).
- The client is redirected to the IdP where they enter the IdP credentials.
- Since the authentication is IdP-initiated, the browser is redirected to a generic landing page of the SP.
The question now is how does this work behind the scenes?
- Before anything happens, the SP (GitHub) has already been configured to communicate with the IdP (Gmail) using SAML metadata. SAML metadata is an XML document that sits with the SP and directs the SP to the IDP. The SAML metadata is usually provided by the IDM/SSO service.
- When a client requests authentication to the SP, the SAML metadata directs the request to IdP.
- The IdP authenticates the client after the credentials are entered and generates a SAML token which is sent back to
the SP. The SAML token is also an XML file that contains metadata about the token and the authenticated client.
- The SAML token metadata allows the client to authenticate and access the SP.
- When closing and opening the browser again, the authentication to SP is successful if the SAML token has
not expired. If the SAML token expires, steps 1-4 should be repeated.
Benefits of using SAML
- User Experience: Since SAML offers SSO services, it reduces “password fatigue” from maintaining multiple passwords, offering a better user experience.
- Ease of Use: SAML allows organizations to manage permission levels and application access for their users with ease.
- Security: Since SAML offers SSO using IdP, user credentials are stored in the more secure IdP, rather than on every SP. Since communication between the IdP and SP uses SAML tokens, it is inherently more secure.
- Platform Neutrality: SAML allows integration with standard services like Azure Active Directory and IdP providers like Google Authenticator or Microsoft Authenticator to provide authentication services.
- Reduced Administrative Costs: SAML “reuses” single authentication and reduces the administrative cost of
maintaining individual SP account databases by transferring this burden to the IdP.
How Parallels RAS leverages SAML
Parallels® Remote Application Server (RAS) is a virtual desktop infrastructure (VDI) solution that delivers applications and desktops to any device. It allows users to access applications from their endpoint devices despite the kind of device or operating system being used.
Parallels RAS supports SAML authentication, enabling you to streamline user access to the web applications hosted on your central server. As part of SAML SSO, Parallels RAS establishes communication with Microsoft Certificate Authority (CA) to manage, request and enroll digital certificates on behalf of your users. In doing so, users do not have to put in their Active Directory (AD) credentials to authenticate to your applications every time.
With Parallels RAS, you do not have to maintain your own identity management solution. It allows seamless integration with third-party IdPs such as Microsoft Azure, Ping Identity, Gemalto and Okta to allow your users to have a true SSO experience with reduced hassle to your organization.
Download the free trial of Parallels RAS to get started with SAML authentication!
