Simplifying password management is key to staying sane these days. As organizations take a “quantum leap” in digitization, employees use more tools than ever for collaboration, messaging or storage. This poses a challenge for IT management: how to offer employees secure access to line-of-business applications and data stored in the cloud? For many, SAML is the answer.
What is SAML
SAML (Security Assertion Markup Language) is an open standard that simplifies the authentication process. It’s based on Extensible Markup Language (XML) format, which standardizes communication between the authenticating entity and the service or web application. In other words, SAML is what makes it possible to use one set of credentials to log into many different applications. It enables the communication necessary to link the authentication of a user’s identity with the authorization needed to use a given web application or service.
What about SAML SSO?
One of SAML’s key roles is to enable SSO. Before SAML, SSO was achievable, but relied on cookies that were only viable within the same domain.
SAML enables single sign-on (SSO) by allowing users to access multiple applications with only one login and one set of credentials. Although SAML isn’t exactly new – it’s been around since 2002 – many new applications and SaaS companies still use SAML for SSO. The most recent version of SAML, SAML 2.0, enables web-based, cross-domain SSO, and is the standard for authorization of resources.
In Windows Active Directory (AD) environments, SAML SSO can allow employees to access a wide range of applications using only their AD credentials. On-premises AD users can continue to use a centralized identity source (AD) for access to cloud apps like Microsoft 365.
If you are looking for information about how SAML works with on-premises Active Directory, and how SAML can integrate with MFA and access management providers like UserLock, this guide is for you.
A primer on SAML terminology
Before we get started, here are a few useful terms for navigating SAML lingo.
Identity provider (IdP)
The site or provider that authenticates the user and sends the SAML assertion.
Service provider (SP)
The site or provider that receives the SAML assertion and trusts the authentication to enable automatic login.
An assertion contains a packet of information called statements. These are usually transferred from IdPs to SPs. Statements allow SPs to make decisions about who has the authentication needed to gain access. There are three types of SAML statements:
These statements tell the SP that the IdP authenticated the user at a certain time and using a certain method of authentication. This statement may also contain other information about the user, known as authentication context.
An attribute is a name-value pair that SPs and IdPs use to make decisions about whether or not to grant access. These statements assert that the user is associated with certain attributes.
Authorization decision statements:
These statements confirm, or assert, that a user has a certain authorization. Usually, these follow a simple formula: a user (often called, “principal”) is permitted to perform action A on resource R given evidence E.
SAML metadata is contained in a document and describes a SAML deployment. This can be in the context of an SP or IdP. Deployments share metadata to establish trust and interoperability, and share at least:
Protocol endpoints (bindings and locations)
What are the advantages of SAML authentication?
SAML brings some key advantages for security, for users, and for service providers.
Users login to the IdP just once, and then enjoy seamless and more secure access across all applications.
Many SPs have neither the resources nor the time to implement and enforce secure user authentication at login. As a general rule, the IdP is much better equipped to authenticate user identity. By referring authentication to the IdP, SAML enables secure authentication that can enforce multiple layers of security, like MFA.
Advantages for users
Improved user experience
With SAML, your users can say goodbye to the headache of trying to remember multiple usernames and passwords.
Since SAML also speeds up the authentication process, users lose less time.
Advantages for service providers
Reduce management burden
Service providers can increase the security of their platform without the need to store passwords.
Reduce costs and burden on Help Desk
With no need to manage forgotten password issues, service providers save on staffing costs and free up existing support staff for other, more critical issues.
Difference between IdP-initiated vs. SP-initiated SAML
It’s important to note that both IdPs and SPs can initiate a SAML request. With SP initiation, the request login is initiated by the application the user wants to access. The user is then redirected to the IdP, and the IdP then verifies whether or not the user is currently logged in and authenticated. The IdP then generates a SAML response back to the SP that gives the user access to the application.
In IdP initiated login, the user logs in directly to the IdP. When the user then opens supported applications, the SP sends a request for authentication to the IdP. Once authenticated, the IdP communicates that the user is authenticated and the user gains access to the application.
How does SAML work with Active Directory?
On-premises AD has been a hallmark of identity management for decades. Now, as organizations transition to hybrid or cloud environments, they want to build on the significant investment they’ve made in AD. Organizations need a way to continue using AD to manage authentication to cloud apps, with no disruption to users or IT operations.
With SAML, on-premises AD users can access multiple web applications, like Microsoft 365, using only their AD credentials.
How does this work exactly? This common practice uses a federated identity: user IDs stored across separate applications and organizations. SAML is a common language that allows these federated apps and orgs to communicate and trust one another’s users.
First, SAML passes authentication information – like logins, authentication state, identifiers, etc. – between the IdP (Active Directory) and the SP (cloud apps and web services). When a user tries to access a site, AD passes SAML authentication to the SP, who can then grant the user access.
How to set up SAML with on-premise Active Directory
There are a few different ways to set up SAML with on-premise AD. Let’s look at a few of the most common.
Set up SAML SSO with Microsoft AD FS or Azure AD
First, Microsoft offers solutions that leverage SAML to provide SSO: Active Directory Federation Service (AD FS) and Azure AD (now Microsoft Entra ID).
AD FS is a standalone federated identity solution that can provide SSO capabilities for on-premises AD users, but it’s complex to deploy and manage.
Azure AD brings Microsoft’s identity management platform to the cloud – away from the on-premises server. Microsoft Azure AD Connect enables SSO capabilities for AD users to access cloud apps. Microsoft now recommends Azure AD Connect for all but AD FS legacy systems.
Azure Active Directory Domain Services is an optional managed service that deploys Windows Server domain controllers in Azure. Azure AD Domain Services offers support for organizations with legacy services and protocols that they want to lift into the cloud.
While Azure AD does offer a way for on-premises AD environments to use SSO, many organizations – for security reasons, simplicity, or other factors – prefer to keep all AD identity authentication on-premises.
Set up secure SAML SSO for on-premises Active Directory with UserLock
UserLock extends on-premises AD identity authentication to the cloud, while ensuring that all authentication takes place via the on-premises AD server. With UserLock, organizations can also combine SSO with multi-factor authentication (MFA) for secure, frictionless access to both network and cloud resources.
Installed and configured in minutes on a standard Windows server, UserLock’s SSO supports SAML 2.0 protocol to enable federated authentication of cloud apps. Users log in just once with their on-premises AD credentials to access the organization’s cloud apps and resources.
How UserLock SSO works: A SAML example for Active Directory
Bob, like most desk warriors, starts his workday by logging into his computer. He types in his on-premises AD credentials. Since his company has two-factor authentication (2FA) in place with UserLock, he also quickly scans his thumbprint using his Token2-Bio security key. Then he opens up his daily toolbox: Slack, Salesforce and Microsoft 365. Since UserLock provides SSO for these apps, Bob can access all of these applications without entering any additional credentials.
Use cases: How UserLock SSO leverages SAML for Active Directory
Here are a few ways that SAML works with UserLock SSO.
Use case #1: SSO for supported SaaS apps
UserLock supports a growing list of SaaS apps. Using SAML SSO, the user is authenticated with their existing on premise credentials. UserLock may also prompt users for two-factor authentication, depending on the conditions set. Find out what apps are supported and how to configure them.
Use case #2: SSO for Microsoft 365 via Active Directory
With UserLock, users can also enjoy seamless access to the Microsoft 365 suite after logging into AD. IT administrators can then enjoy UserLock’s full controls to manage user access to Microsoft 365.
Use case #3: SSO for Microsoft 365 via Azure AD Domain Services
For ecosystems that use Azure AD Domain Services, UserLock also allows secure access and management for Microsoft 365.
Use case #4: SSO for non-supported SaaS apps
IT administrators can also configure a non-supported SaaS application using SAML protocol. Then, using their existing Windows AD credentials, users get secure and seamless access to the SaaS apps your team uses the most.
UserLock: Secure SSO for on-premises AD identities using SAML
With UserLock, organizations can provide secure, time-saving SSO with SAML. Since all AD identity authentication remains on-premises, there’s no need to create and manage a new directory for user identities. And, IT administrators can easily enforce session management policies for accounts, services, roles and groups.