SAML vs LDAP: What's the difference?
SAML (Security Assertion Markup Language) and LDAP (Lightweight Directory Access Protocol) are both user authentication protocols, but their application and use cases are largely different.
SAML is an open identity standard used for exchanging authentication data in cross-domain scenarios, while the LDAP protocol is used for managing access to directory services within closed networks.
For organizations with distributed employees who need to access multiple intranet systems and SaaS applications without managing separate credentials for each system, you need to implement SAML to enable single sign-on (SSO).
For organizations with a complex on-premise infrastructure, and an overworked IT/Security team that has to manually delegate access and permissions across multiple internal resources (whether servers, intranet systems, computers, or printers), you need to implement LDAP to centralize authentication and directory services.
What is SAML, and how does it work?
SAML is a federated identity protocol used to implement single sign-on (SSO) in enterprise environments. It relies on XML (Extensible Markup Language) to exchange authentication and authorization data about employees in the form of SAML requests and responses.
SAML-enabled applications (also known as service providers in SAML speak) use the protocol to send authentication requests (AuthnRequests) to SAML-enabled identity providers, which then send back responses that contain XML assertions about an authentication decision.
Service providers (SPs) are typically SaaS applications such as Slack, Notion, or GitHub that employees need to access for work, while identity providers (IdPs) could be platforms like Okta, Microsoft Entra ID, Google Workspace, or One Login that are responsible for managing centralized user identities within an organization.
At its core, SAML enables end users to authenticate once with a central identity provider and access all integrated cloud applications without needing to log in separately for each service. For more detailed information about how SAML works, see our "What is SAML?" article, and for a comparison with another industry-wide SSO protocol, see our "SAML vs OIDC" article.
What is LDAP, and how does it work?
LDAP is an open protocol for maintaining and modifying directory resources or entries over a network. It enables organizations to manage employee accounts, group memberships, files, intranet applications, physical devices, and other corporate network resources, all within a centralized directory service.
The protocol defines the language and methods for interacting with a directory, but it doesn’t specify how data is stored internally. This means that LDAP doesn’t inherently provide a database, rather, it provides a method to query information stored in a directory service.
The directory service itself (often referred to as an LDAP server) is responsible for storing and organizing the data. Examples of directory services include Microsoft Active Directory, OpenLDAP, RedHat Directory Server, IBM Security Directory Server, Oracle Enterprise Directory Server, Apache Directory Server, and others.
In LDAP, the identity and authentication process involves verifying a user's information by binding their credentials (typically a username and password) to an entry in the directory. If the credentials match the stored attributes, the user is then authenticated. Authorization, on the other hand, determines what resources the authenticated user can access, based on their attributes and group memberships within the directory.
LDAP’s architecture
Unlike traditional relational databases that store information in tables with rows and columns, LDAP directory services store data using an attribute-value pair model. Each entry in the directory is a collection of attributes that can contain one or more values. For example, a user entry might have attributes like ‘cn’ (common name), ‘mail’ (email address), and ‘uid’ (user ID), each with corresponding values.
LDAP directories are typically organized hierarchically, much like a file system, with entries arranged in a tree structure according to nodes that represent different levels in the hierarchy. This hierarchical nature makes it well-suited for storing organizational information, which can be structured from the root according to geography (country, state, city), organizations (company, division, department), units (specific teams or workgroups), roles (job titles or positions), individual persons or employees, and even resources (computers, printers, servers).
Additionally, groups can be created to manage collections of users or other entries for access control and permissions, independent of the hierarchical structure. At its core, LDAP’s architecture is based on a client-server model, where an LDAP client has to make requests (queries) to an LDAP server in order to access information.
LDAP queries involve constructing search operations based on attributes in order to locate specific entries within the directory structure. The search operation typically specifies a base DN (Distinguished Name) to define the starting point of the entire search path, a scope to define the extent of the search (whether base, one-level, or subtree), a filter to refine the search criteria (e.g., (uid=jdoe)), and the attributes to return in the results. The LDAP server then processes the query, navigates the directory tree, and returns matching entries based on the specified filters and scope.
Cloud-based SSO vs. on-premise SSO
As we’ve established so far, SAML enables cloud-based SSO (single sign-on) across domains by exchanging XML messages between identity providers (IdPs) and service providers (SPs).
The way this works is quite straightforward: When a user attempts to access a SaaS application/service provider via SAML SSO, the application typically generates an authentication request (AuthnRequest) and routes the user to the IdP used to manage identity profiles within their organization. The user then logs into the IdP using their IdP-provisioned credentials.
If the credentials are valid, the IdP has to generate a SAML response containing XML assertions about the user’s authentication and authorization status, and route the user back to the application that made the initial AuthnRequest. The application then parses the SAML assertion and grants the user access to their system without requesting any credentials. This approach eliminates the need for users to maintain and remember multiple usernames and passwords across different cloud applications.
However, when it comes to authenticating users into multiple on-prem resources using a single set of credentials, it’s impossible to rely solely on LDAP. While LDAP doesn't inherently provide SSO functionality, it can be a key component within an on-premise SSO system. LDAP alone provides directory services and authentication, but when implemented alongside other protocols like SAML and Kerberos, it can be used to support on-premise SSO.
On-premise SSO using Kerberos and LDAP
In Windows environments, Kerberos authentication can be combined with LDAP directory services to provide an SSO-like experience within a domain. In this setup, LDAP is used for directory services and user management, while Kerberos provides the single sign-on (SSO) functionality.
Here’s how this works: When a user logs into their Windows computer, the device communicates with their domain controller using Kerberos. The domain controller authenticates the user’s credentials against an LDAP server and issues a Kerberos ticket-granting ticket (TGT) which serves as proof of the user’s identity.
As the user accesses various resources within the domain (like file servers, intranet applications, or printers), their computer uses the TGT to request specific service tickets from the domain controller, without requiring the user to re-enter credentials across these resources.
This approach allows users to access multiple internal resources seamlessly after their initial login, creating an SSO-like experience within the Windows domain. However, it's important to note that this SSO experience is typically limited to resources within the same domain or trusted domains, unlike SAML which can work across disparate systems and domains.
On-premise SSO using SAML and LDAP
In this scenario, identity providers (IdP) like Okta, Entra ID, One Login, and Google Workspace can be used to implement SAML in an on-premise environment because they offer lightweight LDAP agents and/or virtual LDAP interfaces that can connect to on-prem LDAP servers.
Here’s how this would typically work: When a user attempts to access an application, they’re redirected to the IdP, which must have been deployed on the organization’s network and interfaces with the LDAP directory. The IdP then authenticates the user by validating their credentials against the LDAP directory using the IdP’s installed agent, without replicating these credentials with the IdP. Once authenticated, the IdP generates the appropriate SAML assertions and redirects the user back to the application, which then grants access to the user without requiring any credentials.
This approach combines the best of both worlds: It allows organizations to maintain their existing LDAP infrastructure for user management while providing a modern SSO experience that works across applications and environments, including on-premise and the cloud.
Is SAML an LDAP alternative, or vice versa?
As we’ve seen so far, SAML and LDAP are not direct alternatives, as they serve different purposes and use cases. LDAP is a directory access protocol used primarily for storing and retrieving user information within on-premise environments, while SAML is an XML-based authentication protocol designed for web-based single sign-on (SSO) across multiple domains and applications.
Can SAML and LDAP be used together?
Yes, SAML and LDAP can be used to complement each other in modern IT environments that maintain both cloud-based and on-prem resources. LDAP enables authentication to on-prem resources, while SAML enables authentication to cloud-based applications via SSO. In this setup, identity providers act as the bridge between LDAP directories and SAML-enabled service providers, combining the strengths of on-prem user management with flexible, cross-domain authentication.
Getting started with Stytch
In this article, we've been able to successfully compare SAML vs LDAP as authentication and authorization protocols that can be used to authenticate users, and grant them access to both on-prem and off-prem company resources.
Ready to support SAML and other open protocols such as OIDC, OAuth, and SCIM using Stytch? Check out our docs and sign up for a free developer account to start building.
Share
