The Actors

Module 2 of 6 in the chapter Single Sign-On: The Browser Is the Broker, chapter 4 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: When several systems take part in one login, who is who, and how do you tell which one is the identity provider?

A cast of characters

Single sign-on can feel confusing at first, and it’s mostly because of the cast. There are more players than people expect, each one has a name with “provider” or “server” in it, and they pass Priya around between them. So let’s meet them one at a time, with one job each. Here they are, using Priya from module 1, who signs in to Salesforce through her company’s identity provider:

Click to enlarge

The browser

Priya’s browser is the one actor that talks to everyone. It goes to Salesforce, to the identity provider, and back again. Hold on to that, because module 3 shows that the browser does much more than you’d think: it carries every message.

The identity provider

The identity provider, or IdP, has one job: proving who Priya is. It shows the login screen, checks her password, asks for her second factor, and then vouches for her to the other systems.

Because every system relies on it, this is where you put your strongest controls: the password rules, the MFA, the IP restrictions. Put everything about proving identity into the identity provider, and make it as strong as you can. Then the other systems don’t need all those layers themselves. They just need to check what the identity provider vouched for.

The identity store

Here’s a distinction people often miss. The identity provider checks passwords, but it doesn’t have to be where they’re kept. They’re kept in the identity store: the directory of users and their credentials.

In a Microsoft company, that’s usually Active Directory. I ask this in every class: is Active Directory an identity provider? It isn’t. Active Directory is an identity store. The identity provider sits in front of it and checks Priya’s password against it. In companies that don’t use Microsoft, the store is often another directory, reached over LDAP, the standard way to read from a directory. The identity provider and the identity store can be one product, or two different ones.

Either way, the passwords in the store should never be readable. They’re kept as hashes, the one-way fingerprints from chapter 3, so that someone who breaks into the store doesn’t walk away with everyone’s password.

And one question to ask early in any single sign-on project: how many directories do you have? One company I worked with had about ten Active Directories. Some were for regions. Some came from companies they’d bought and never merged. Sometimes a parent directory sits over them all, so it looks like one. Either way, it’s the identity provider’s job to know how to work across them. But you need to know about all ten before you design anything.

The service provider, and its two servers

The service provider, or SP, is the system Priya actually wants to use. Here, it’s Salesforce.

Remember from module 1 that every system has two servers, and Salesforce is no exception:

The login server is Salesforce’s own security guard. Even with single sign-on, it’s still there, and it still issues Priya’s session, the wristband from the front door. The identity provider doesn’t do that.
The instance is Priya’s org, with her pages and her data. It only checks the wristband.

So here’s the part that surprises people. The identity provider doesn’t get Priya into Salesforce. It vouches for her to Salesforce’s login server, and the login server lets her in. Module 3 shows exactly how that hand-off works.

Count them

Now count. You might think a single sign-on login has three players: Priya, the identity provider and Salesforce. Add a second service provider, say the HR system from module 1, and look again. There’s the identity provider. There’s Salesforce’s login server and Salesforce’s instance. There’s the HR system’s login server and its resource. That’s five different services, all behind one login, before you even count the identity store. No wonder it looks like a lot at first.

So when five systems are working together, which one is the identity provider?

I once sat down with a client’s team, early in a project, and asked them exactly that, again and again, until it stuck. The answer is simple. Where is Priya typing her username and password? Whichever system shows the login screen is the identity provider. There should be only one.

That one test settles most arguments about a single sign-on design. And it works the other way too: if two systems are showing Priya a login screen, you don’t have single sign-on yet.

Salesforce can play either part

Salesforce can be either one.

The service provider: the company’s identity provider, such as Okta, Ping Identity or Microsoft Entra ID, shows the login screen, and Salesforce trusts it. Chapter 6.
The identity provider: Salesforce shows the login screen, and other applications trust Salesforce. Chapter 7.
Both, with two orgs: in Salesforce-to-Salesforce single sign-on, one org is the identity provider and the other is the service provider. One org’s login screen controls the other. It’s the easiest way to try all of this yourself, and the practice for this chapter does exactly that.

What’s next

So we have a browser, an identity provider, an identity store, and a service provider with two servers. They pass Priya from one to the other. But how, if the identity provider and Salesforce never talk to each other? Module 3: the browser is the broker.

What an architect decides here

Name the identity provider, and the identity store behind it, on every diagram. If nobody can say which is which, stop and find out.
Ask how many directories there are, and whether a parent sits over them, before you design anything.
Decide which part Salesforce plays: service provider, identity provider, or both.
Apply the login screen test. One login screen, one identity provider.

Explore

SAML SSO with Salesforce as the Service Provider (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
RFC 4511: Lightweight Directory Access Protocol (LDAP): The Protocol (opens in a new tab) (IETF, June 2006; checked 2026-11-07)