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 authentication is the answer.

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 authentication 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.

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 authentication 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.

Before we get started, here are a few useful terms for navigating SAML lingo.

The site or provider that authenticates the user and sends the SAML assertion.

The site or provider that receives the SAML assertion and trusts the authentication to enable automatic login.

A SAML 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:

1. SAML authentication 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.

2. SAML attribute statements
   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.

3. SAML 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:

1. Entity ID

2. Cryptographic keys

3. Protocol endpoints (bindings and locations)

SAML brings key advantages for security, for users, and for service providers.

• Simplicity: Users login to the IdP just once, and then enjoy seamless and more secure access across all applications.

• Increased security: 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.

• Improved user experience: With SAML, your users can say goodbye to the headache of trying to remember multiple usernames and passwords.

• Time savings: Since SAML also speeds up the authentication process, users lose less time.

• 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.

This is important: 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.

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 user accounts can access multiple web applications, like Microsoft 365, using only their AD credentials.

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 an Active Directory user tries to access a site, AD passes SAML authentication to the SP, who can then grant the user access.

There are a few different ways to set up SAML with on-premise AD. Let’s look at a few of the most common.

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.

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.

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.

Here are a few ways that SAML works with UserLock SSO.

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.

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.

For ecosystems that use Azure AD Domain Services, UserLock also allows secure access and management for Microsoft 365.

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.