Share This Article
As IT continues to shift toward the cloud and Software-as-a-Service (SaaS) applications, SAML is an important topic when considering authentication options. SAML also uniquely provides authorization that can be used to enforce user permissions on services. Let’s explore SAML, how it works, its history and benefits, how you can use it, and how it compares to its alternatives.
What Is SAML SSO?
The Security Assertion Markup Language (SAML) protocol is the go-to for many web application single sign-on (SSO) providers and is used to securely connect users to web applications with a single set of credentials. SAML utilizes Extensible Markup Language (XML) certificates to assert user authentications between an identity provider (IdP) and a service provider (SP) or web application.
Users can create a single, strong password to secure their IdP credentials without having to worry about keeping their web app passwords written out in a document or on a sticky note attached to their monitor, or having to leverage password managers to store credentials. (Note that you can still benefit from an SSO password manager, though.)
In short, it’s web-based single sign-on (SSO). That’s a lot of acronyms, but they will make more sense once we dive into how SAML works.
What Is SAML 2.0?
SAML 2.0 is the current version of the SAML standard. It was a substantial update that wasn’t backward compatible with its predecessor and added features that had been included in the Liberty Alliance Identity Federation Framework, making it significantly more robust and mature. Single logout (across services) was one of the most significant improvements.
The Benefits of SAML
There are numerous benefits to using SAML. Security and relative ease of managing credentials are clear wins: end users do not need to remember all of the passwords necessary to access their various web apps. The assertion process uses secure XML communication via SAML directly between the SP and IdP, and passwords aren’t stored on remote servers or sent over the wire. Overall, IT admins gain centralized user lifecycle management with very granular control over what resources users may access. This characteristic is ideal for regulated industries that must take stringent measures to secure data confidentiality and privacy rights.
IT admins generally experience a reduction in password-related help desk tickets in addition to increased security through SAML, and the ability to layer on strong, user-friendly multi-factor authentication (MFA), such as Push MFA, and protections against phishing. SSO also reduces the risks of shadow IT, which is when users manage their own access to applications under IT’s radar. End users, having to only worry about a single password, experience less password fatigue with SSO as well.
Many SSO providers have created web portals where end users can log in once and then click on a tile with the application they need to access, which offers another incentive to adopt SAML.
Examples of SAML in Action
The aforementioned SSO portal is a good example of how SAML can drive IT synergies within small and medium-sized enterprises (SME). This process is often referred to as “SAML flow,” when users click on an application icon and authentication occurs behind the scenes.
Another use case leverages user attributes to determine which part of an application they should have access to. For example, someone who’s an accounting clerk shouldn’t have the same level of access as a CFO. It reinforces the security concept of separation of duties and helps to ensure adherence to least privilege, essential to a robust Zero Trust security model.
JumpCloud uniquely leverages attribute-based access control (ABAC) to provide an instant cross-check of users within a group to the apps and resources they need, and includes suggestions to modify group memberships. This differs from traditional role-based and nested access control methods that weren’t originally designed for SaaS-based IT infrastructures.
Developers can also use SAML as a solution to secure backend web services using a feature called SAML message protection. SAML is extremely flexible and customizable.
The JumpCloud User Portal leverages SAML
How Does SAML Work?
The process of SAML is, in essence, a series of exchanges between the user, a service provider (who hosts the web application the user wants to access), and an identity provider (which is the means by which the user can authenticate). When a user wants to access a web application, they first visit the service via an “agent,” which is almost always a standard web browser like Chrome, Firefox, Safari, or Edge. The agent then attempts to request access from the SP by logging into the web application.
Components of SAML
The exchange of identity information about authentication and authorization is made possible through SAML’s core components functioning as a system. This section outlines each component and its role in enabling SAML’s message/response framework that makes it possible to federate identities and user information across domains. First, let’s examine a visualization of the basic steps of a transaction via the SAML protocol.This example illustrates what happens underneath the covers when a user enters their company credentials into a service that your organization uses.
Bindings
Bindings are the infrastructure that make SAML messages transfer over common networking protocols. For instance, an HTTPS POST binding defines how to transport a SP’s responses to requests from a user agent (web browsers).
Protocols
How do most users establish secure connections to web services? HTTPS is an example of one of the protocols, along with SOAP, that’s specified within the SAML standard. Digital certificates (X.509 certificate) are used on the IdP and SP sides for secure communications.
Profiles
Profiles are the glue that bundle SAML’s protocols, bindings, and assertions for each use case. JumpCloud simplifies this concept by making a library of hundreds of “connectors” available to users, to spare them the heavy lifting.
The next section details how assertions work, which are XML packets that contain organizational information about the user, the method of authentication, as well as policies that specify access to resources and transaction logs.
What Is SAML Assertion?
The SP has been administratively set to defer its authentication to a specific source of authentication — the IdP or user database, if you will. Login is then securely redirected via the internet (and through the browser) to request an authentication from the identity provider to verify the user’s identity.
From the user’s perspective, this acts as a redirection to another website that contains a simple user interface with a username and password field. The user then enters their IdP credentials, which in turn verifies them against its own records.
Upon successful verification, the IdP will generate an XML-based certificate, referred to as an assertion. This means the IdP is generating a figurative “hall pass,” claiming it knows the user and they may gain entrance to the requested application. This certificate is relayed back to the user’s browser and then on to the service provider, redirecting the page back to the service so it can ingest the “hall pass” and permit the user to enter. Note that in some more sophisticated flows, more data is returned by the IdP, including attributes, group membership, and more, to help the service provider accurately assign authorization rights as well as provide additional data that the SP may need to better serve the user.
IdP and SP with SAML
The exchange of information occurs between the IdP and SP. As demonstrated above, providers use SAML to relay credentials between an identity provider, which contains the credentials to verify a user, and a service provider, which is the resource that requires authentication. The process can be initiated by either party, but the IdP is the one that’s responsible for securing and managing user identities and directory groups. Accounts stored within an IdP ultimately become verified users on a service through SAML identity federation.
SAML can be used in combination with other authentication standards depending on the use case. For example, an SME within the healthcare industry would use SAML for secure application portal access, but a mobile app would benefit from the efficiencies of OIDC. The next section provides a brief overview of which method of SSO is most optimal for each case.
Other Authentication Options
SAML vs. OAuth
OAuth tends to be more application centric than SAML, which is primarily used for web SSO. OAuth would be the preferred choice in an instance where an app must scope access to devices’ hardware functions, such as a webcam or camera.
Click here for a detailed comparison between SAML and OAuth.
SAML vs. OpenID Connect (OIDC)
OIDC is growing in popularity, especially among mobile developers. It provides scalable, efficient communications, but doesn’t have the same ability to authorize users with services that SAML is built for. OAuth serves as its underpinnings, with an additional identity layer that’s intended for decentralized identity. It’s as much a philosophical stance as a technology one.
Click here for a detailed comparison of SAML vs. OpenID.
SAML vs. LDAP
These two standards go hand in hand, with an LDAP directory serving as the user management role for an IdP. Combining these authentication protocols makes it possible to connect to an even wider variety of services, securely, to help meet your business objectives.
Click here for a detailed comparison between SAML and LDAP.
The JumpCloud Directory Platform enables IT admins to manage their users and their access to systems, applications, networks, infrastructure, file servers, and more with just a single set of credentials. As a cloud IdP, JumpCloud has reimagined the partnership that exists between Active Directory and SSO for the modern era, providing practically all of the same capabilities and many others, all from a single cloud admin console.
JumpCloud leverages SAML, along with LDAP, RADIUS, and more, to provide a True SSO experience, meaning IT organizations can use one comprehensive solution instead of a host of others. Beyond that, IT admins can also use JumpCloud to implement Zero Trust security policies, such as multi-factor authentication (MFA), conditional access, password complexity, and more across their organization at scale.
Using SAML with JumpCloud
True Single Sign-On™ extends beyond simply SAML, using an array of other protocols and authentication methods to extend one set of user credentials to virtually all resources. Thankfully, JumpCloud’s next-generation cloud directory service provides a True SSO experience for modern IT organizations.
This article outlines how to get started with SAML SSO using JumpCloud. The easiest method is to search through our growing library of connectors, but it’s also possible to write your own.
How to Configure SAML
To connect an application to JumpCloud:
- Log in to the JumpCloud Admin Portal at https://console.jumpcloud.com/login.
- Go to User Authentication > SSO, then click ( + ). The Configure New Application panel appears.
- Search for an application by name using the search bar at the top of the panel.
- When you find the application you want to connect, click configure.
Tip: If there isn’t a connector for an application you want to connect to JumpCloud, you can use the SAML 2.0 connector to connect that app with JumpCloud.
JumpCloud uses the SAML 2.0 protocol as its method to assert identities with application service providers. JumpCloud is considered the identity provider, and the application is considered the service provider.
How to Manage SAML Authentication
The service provider typically provides SAML configuration parameters to set up SSO from a compatible IdP like JumpCloud.
The following image shows Salesforce’s instructions for setting up the Marketing Cloud for SAML SSO.
How to Manage SAML Assertion
To log in to a web-based application using IdP initiated SAML authentication:
- A user enters their credentials in the IdP.
- The IdP authenticates and authorizes the user.
- After logging in, the user navigates to a list of web-based applications they can access, and selects the one they want to use.
- When the user clicks on the web-based application, the IdP sends a SAML assertion to the SP.
- The SP receives the SAML assertion and does a few things:
- The SP checks to make sure the assertion is valid and authentic.
- The SP finds out who the user is and how they should be logged in.
- The SP gives the user access to the application without requiring them to log in again.
To log in to a web-based application using SP initiated SAML authentication:
- A user navigates to a web-based application’s login page and enters their username.
- The SP behavior varies, but many detect that SAML SSO is involved, and redirects the user to an IdP login page.
- The user enters their credentials on the IdP login page.
- The IdP authenticates and authorizes the user, then sends a SAML assertion back to the SP with the information it needs.
- The user is redirected back to the SP with access to the application.
Read JumpCloud’s SAML attributes notes.
Get Started with JumpCloud
You can experience True SSO with SAML, LDAP, RADIUS, and more yourself, with JumpCloud.
Want to dip a toe in before jumping right in? We also offer free, personalized demos of the platform to show you the ropes before you try JumpCloud for yourself. Please contact us if you would like to learn more.
