SAML Explained: How Does SAML Work and Why Use It?
Federated identity is crucial for users to have seamless and secure access to applications in today’s web-centric application environment. Without federated identity standardization mechanisms, it would be difficult for businesses to scale single sign-on (SSO) beyond multiple applications in a cost-effective manner.
Secure assertion mark-up language (SAML) has evolved as a primary federation standard, owing to its proven security, certifiable interoperability, and worldwide deployments involving thousands of applications. But how does SAML work? This post delves into SAML to explain how it works and why businesses prefer to use it.
What Is SAML?
SAML is an open authentication standard based on extensible mark-up language (XML). It conveys identity data between an identity provider (IdP) and a service provider (SP). In this case, the IdP authenticates the identity and passes the information in an XML format to an SP, which authorizes the given identity to access the requested services.
Because the IdP stores and manages all the login credentials, SAML enables SPs to provide services without having to undertake their own authentication. SPs can leverage SAML to increase their security postures because they don’t have to store (often weak and insecure) passwords on their platforms. They also don’t need to address forgotten password issues that bedevil most organizations.
With SAML, you can also enable SSO experiences where users log in to user-identity directory services or intranets once and reuse those same credentials to access services from multiple SPs. Most organizations already know the identity of their users either from Active Directory (AD) or Open Lightweight Directory Access Protocol (LDAP).
It makes business sense to use this information to allow users to log in to other resources—whether such resources reside on-premises or in the cloud—and SAML is one of the more elegant ways to achieve it. SAML SSO enhances user experience because users need to sign in only one time to an IdP and access multiple services from different SPs, accelerating the authentication process.
Besides faster authentication, SAML SSO eliminates the need for users to remember multiple credentials for every application. Consequently, users don’t need to inundate IT administrators with password reset requests, potentially freeing them to attend to more productive issues.
Enterprises can also leverage SAML to cut costs. For example, a business can subscribe to an IdP and minimize labor costs significantly rather than building and maintaining its own local authentication implementation solutions.
The Security Services Technical Committee (SSTC) of OASIS is an umbrella organization that defines and maintains SAML protocol. So far, OASIS has released three versions of SAML: SAML 1.0, SAML 1.1, and SAML 2.0. While the latest version (SAML 2.0) builds on previous SAML 1.1 specifications, it is not backward compatible.
What Is SAML Assertion?
A SAML assertion is an XML packet that contains authentication and authorization information about the identity. You can think of assertions as statements made by the IdP about a user. The SP uses SAML assertions to create and configure sessions when a user logs in to a service.
There are three types of SAML assertions:
- Authentication assertions. They help to confirm the identity of the user. Authentication assertions contain statements about which method a user has used to authenticate to the service, such as password, multi-factor authentication (MFA), or Kerberos. They also indicate the time the user logged in to the platform.
- Attribute assertions. These are specific datasets that provide information about the user, such as first name, last name, email address, etc. The attributes that SAML uses to identify a user must be the same in both IdP and SP directories.
- Authorization assertions. Authorization assertions are typically issued by SAML policy decision point (PDP) when a user requests access to a specified resource from the SP. They communicate whether a user’s authorization attempt is successful or not.
How Does SAML Work?
The SAML protocol consists of three parties: the principal (also called the subject), the IdP, and the SP. The principal is the user that wants to authenticate into an enterprise network to access resources. All principals have metadata (also called identity information) attached to them, including their first names, last names, email addresses, etc.
An IdP is a platform that acts as the source of identity information and makes the authentication decision. You can think of an IdP as a database containing all the entries about user identities. IdPs authenticate principals and return identity information in XML-based formats to SPs. Common examples of IdPs include Active Directory Federation Services (ADFS), Azure AD, and Auth0, among others.
An SP, on the other hand, is an SSO-based application that users want to access. Ordinarily, users would simply log into these applications directly. However, with SSO, users log into the SSO instead, and SAML grants them access to the applications. To grant access to resources, SPs take authentication responses from IdPs and use the information to create and configure sessions.
At its core, the SAML standard specifies a request/response model for exchanging XML messages between IdPs and SPs. Besides SAML assertions, the standard comprises protocols, bindings, profiles, and flows. When used together, these components enable the exchange of identity, authentication, and authorization data between federated organizations.
Let’s take a look at these SAML components:
- Protocol. SAML supports hypertext transfer protocol secure (HTTPS) and simple object access protocol (SOAP). The SAML connectors use HTTPS to create a secure connection between the IdP and the federated applications. To establish such a connection, you must get the X.509 certificate from the metadata of the IdP and the application. Each side (the IdP and the SP) then uses the other side’s certificate to establish a secure connection.
- Bindings. SAML bindings define how the underlying transport protocols can transfer various protocol messages. For example, HTTP Redirect Binding defines how the system can transport SAML messages via HTTP redirect messages. In contrast, SOAP binding describes how the system can carry SAML messages get transported within SOAP messages.
- Profiles. SAML profiles bundle the selected SAML assertions, bindings, and protocols for specific federated applications. For example, SAML 2.0 Web Browser SSO—one of the most commonly used profiles—defines the framework for using SAML SSO authentication in web applications.
- Flows. A SAML flow is triggered when a user initiates an SSO process on the browser. SAML supports two types of flows: those initiated by the IdP and those initiated by the SP. In an IdP-initiated flow, you start with the IdP, which authenticates you and redirects you to the SP alongside the SAML assertions. In an SP-initiated flow, you begin with the SP, which redirects you to the IdP to authenticate and then you get redirected back to the service provider.
Here’s how the sequence of events for SAML authentication works:
- You try to access an application such as Parallels® Remote Application Server (RAS) by entering the URL address on a web browser or using a bookmark. In this case, Parallels RAS is your SP.
- The SP identifies your origin based on the IP address or application domain and redirects you to the IdP, asking for authentication. For example, you may be redirected to Okta, OneLogin, or Azure Active Directory (AD).
- The IdP creates an XML-based authentication response containing your login credentials and signs in via an X.509 certificate.
- The IdP then posts the authentication information inform of SAML responses and assertions to the SP.
- The SP already knows the IdP and has its certificate fingerprint. Therefore, it retrieves the SAML responses and validates them using the IdP’s certificate fingerprint. The SP then allows you to access the application.
What’s the Difference between SAML and OAuth?
Both SAML and OAuth are federation identity management protocols that began with the emergence of the SSO trend. Companies needed to unify authentication platforms for better management and security in the wake of proliferating software as a service (SaaS) applications.
SAML and OAuth emerged to offer the following use cases:
- Enhanced user experience. SAML and OAuth allow users to access multiple applications with a single login, avoiding an ever-expanding list of credentials demanded by multiple resources.
- Enhanced security. SAML and OAuth enable IT administrators to enforce access policies for SaaS applications via SSO, strong password enforcement, and MFA.
- Centralized management of identities. IT administrators can use SAML and OAuth protocols to integrate and centralize authentication and authorization processes quickly. For software vendors, these protocols streamline onboarding while allowing them to delegate user management. This reduces overhead and maintenance processes for both on-premises and cloud-based applications.
However, despite the similarities, SAML and OAuth have different functionalities when it comes to access management. While SAML handles authentication processes, OAuth is in charge of authorization. In other words, SAML confirms a user’s identity while OAuth determines what access privileges the user has.
For example, you could use SAML to authenticate you to the Windows environment and gain access to an entire suite of SAML-enabled applications. You could also use both protocols to grant you access to Windows (via SAML) and access protected resources via OAuth.
Parallels RAS Simplifies the Management of User Identities from Different Organizations with SAML 2.0
Parallels RAS is a secure, out-of-the-box desktop-virtualization solution that businesses can use to run and share virtual desktops and applications. IT administrators can use a broad range of features to monitor and secure access to corporate resources in multi-tenancy environments.
Parallels RAS fully supports SAML 2.0—the latest version of SAML—with different IdPs. Organizations can pick their IdPs from a growing list of options, including Okta, Azure AD, RADIUS, Deepnet, and Gemalto (formerly SafeNet), and more.
The identity brokering capabilities with Parallels RAS enable organizations to create, maintain, or modify their current IdPs and associated MFA policies without impacting the solution.
Try Parallels RAS today, and experience first-hand how it streamlines the management of user identities with SAML 2.0!