The Problem SAML Solves

Part 1 of the SAML From First Principles series

Imagine you work at a company that uses 10 different web applications. Slack for messaging, Jira for project tracking, Gmail for email, Salesforce for CRM, Confluence for documentation, and so on.

Each one of these applications has its own login page. Its own username and password. Its own database of who's allowed in.

What does that mean for you as a user?

You carry 10 different sets of credentials. Each application stores your name, email, and password independently. Every time you switch from one app to another, you enter your credentials again. And if one of those applications gets breached, your credentials for that application are compromised.

Now think about it from the company's perspective. Every application has to build and maintain its own authentication system. Every application has to handle password resets, account lockouts, and multi-factor authentication on its own. The security team has no central view of who has access to what.

The actual problems

Users remember too many passwords. When people have 10 passwords to manage, they reuse the same password everywhere or pick weak ones they can remember. This is human nature, not a training problem.

Credentials are stored in too many places. Your password exists in 10 different databases, managed by 10 different teams with 10 different security practices. Each one is a potential breach point. The attack surface is enormous.

Every application reinvents authentication. Each development team writes their own login logic, their own session management, their own password hashing. More code means more bugs. More bugs mean more security holes.

Multi-factor authentication is inconsistent. Some apps support MFA. Some don't. Some support SMS only. Some support authenticator apps. There's no way to enforce a consistent MFA policy across all applications.

The user experience is terrible. You log into Slack. Then you open Jira and log in again. Then Gmail. Then Salesforce. Every context switch costs you time and friction.

If you look at all five problems, they share a single root cause: there is no central authority for identity. Every application is acting as both the application and the identity verifier.

The first fix: centralize identity

The first logical step is to pull users out of the applications and put them in one central place. That's exactly what Directory Services do. The most well-known example is Microsoft Active Directory.

Think of it as a master registry. Instead of each application keeping its own list of employees, there's one central database that stores everyone's name, email, phone number, department, role, and group memberships. When an application needs to verify a user, it asks the directory instead of checking its own database.

This is a big improvement. Users exist in one place. When someone joins the company, you add them to the directory once and they can access all their apps. When someone leaves, you disable them in the directory once and they lose access everywhere.

LDAP: how apps talk to directories

We have a central directory with all our users. Now applications need a way to query it. That's what LDAP does. LDAP stands for Lightweight Directory Access Protocol. It's the language that applications use to communicate with directory services like Active Directory.

When a user tries to log into an application, the flow looks like this:

1. The user enters their username and password into the application's login page
2. The application takes those credentials and sends them to the directory via LDAP
3. The directory checks: does this username exist? Does the password match?
4. The directory responds: yes or no
5. If yes, the application creates a session and lets the user in

The application itself doesn't store the password. It delegates the password check to the directory. That's progress.

One password, still broken

Users now have one password. The directory stores it centrally. Applications use LDAP to verify credentials. But let's look at what's still wrong.

Applications still touch your password. When you log into Slack, you type your password into Slack's login page. Slack takes that password and sends it to Active Directory via LDAP. That means Slack sees your password. Same for Jira. Same for Gmail. Same for every application.

You're handing your password to every application so it can forward it to the directory on your behalf. It's like giving your house key to every delivery person so they can verify your address. They only need to know you live there. They don't need your actual key.

Users still log in every single time. Go to Slack, enter your password. Open Jira, enter your password again. Switch to Gmail, enter it again. Every application requires a separate login, even though you're the same person who authenticated 30 seconds ago.

Every application needs LDAP integration. Each development team has to write code to connect to the directory via LDAP. That's connection management, bind operations, search queries, error handling. More code means more bugs.

Applications must be on the same network. LDAP requires network connectivity between the application and the directory. If your Active Directory is on-premises but your application is in the cloud, you need a VPN or a direct network path.

The root cause: the application is doing two jobs. It's being an application (showing you your messages, your tickets, your email) and it's verifying your identity (taking your password, checking it against the directory). These two responsibilities should be separated.

An application should never see or handle your password. That's the key insight that leads to SAML.

Next in this series: How SAML Works, The Big Idea