The Other Seat

Module 1 of 6 in the chapter Salesforce as the Identity Provider, chapter 7 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: When should Salesforce be the one that vouches for someone, and what changes when it is?

Turn it around

For three chapters, Salesforce has been the one doing the trusting. Priya signs in at the company’s identity provider, the identity provider vouches for her, and Salesforce lets her in on its word. Salesforce is the service provider.

Salesforce can also sit in the other seat. It can be the one that vouches. Priya signs in to Salesforce, and another app lets her in because Salesforce says who she is. Now Salesforce is the identity provider, and the other app is the service provider.

This chapter puts Salesforce in that seat, and the clearest way to see it is to use two Salesforce orgs. One org vouches; the other trusts. Priya signs in once, to the first org, and goes into the second without logging in again. Then it widens out: apps that aren’t Salesforce, and how to decide who should vouch at all.

The same five steps, from the other seat

Here’s the good news. You already know this flow. It’s chapter 6’s swim lane, the same five steps, in the same places. What moved is the login screen.

Click to enlarge

1. Priya opens a link to a record in the second org, the service provider org. It has no session for her, so it redirects her.
2. The service provider org’s login server decides which identity provider to use, writes a SAML request, and redirects her there.
3. This time the login screen is Salesforce’s own, in the identity provider org. Priya signs in there, with MFA. Salesforce writes the SAML response and signs it.
4. The browser carries the response to the service provider org, which checks it and finds Priya.
5. She’s in, as the service provider org’s Priya.

Everything chapter 6 taught about the service provider’s side still holds: the single sign-on setting, the six pairs, the Federation ID, the relay state. Chapter 6’s practice set it up in your service provider org. What’s new is the other side, and it’s Salesforce too.

Who holds what

When you change seats, the keys change hands. This is where people get turned around, so let’s go slowly.

In chapter 6, the identity provider held its private key and signed. Salesforce, the service provider, held the identity provider’s certificate and checked. I say it in every class: remember, it’s the service provider that is trusting the identity provider. The one that trusts holds the certificate.

Now Salesforce is the identity provider, so Salesforce holds the private key. When you turn it on, Salesforce uses a self-signed certificate made with SHA-256 by default, or one you choose (S1). The service provider gets the certificate, by Download Certificate or inside the file from Download Metadata (S1). The private key never leaves Salesforce.

And Salesforce signs both. When Salesforce is the identity provider, it puts its signature in the response body and in the assertion (S5). Chapter 6 said one signature is required and both are recommended; this is Salesforce doing what it recommends.

One more value travels with the certificate: the Issuer, “the unique identifier for your Salesforce identity provider” (S1). The service provider checks it on every response, exactly as your service provider org did in chapter 6.

Test knowledge. In my experience, know who holds which certificate. When Salesforce is the identity provider, Salesforce signs with its private key, and the service provider holds Salesforce’s certificate. When Salesforce is the service provider, it’s the other way round.

The clock, from the other side

Chapter 6’s last module told my clocks story: the times in a message are checked against the other side’s clock, and a few minutes of drift is enough to stop everyone. From this seat, Salesforce is the one setting the times. Salesforce says an assertion it sends “is valid for 5 minutes after it’s issued, with a 30-second buffer to account for clock skew” (S1). If the service provider receives it outside that window, it typically rejects it, and Salesforce’s advice is to work with the service provider so it complies (S7). The fix is the same as before: both sides keep exact time.

When Salesforce should vouch

Salesforce comes ready to be an identity provider. In a new org, it’s one switch. But being able to do it isn’t a reason to do it. So when does it fit?

When one org should vouch for other orgs. This is the one I like to show. Your production org is the identity provider, and the service providers could be a dozen different environment orgs: the test and training orgs your people work in. People sign in once, to production, and click through to each one. One place to switch someone off. One note for architects: local external client apps, the kind module 3 uses, aren’t copied when you refresh a sandbox (S8). So keep the identity provider side in production, where it isn’t refreshed, and let the sandboxes be the service providers.

When the people already live in Salesforce. Partners and customers often have their logins in Salesforce, on an Experience Cloud site. When they need another app too, Salesforce already knows them, so Salesforce can vouch for them. Module 5 shows the ways, and chapter 14 builds the sites.

When there’s nothing else. A small company running on Salesforce, with no identity provider of its own, can sign its people in to a few other apps through Salesforce.

When it shouldn’t

Most companies already have an identity provider for their staff: Microsoft Entra ID, Okta, Google. Everyone signs in to email with it every morning. When I’m asked whether Salesforce or the company’s identity provider should vouch for staff, my first question is: does the customer already have one? If they do, use it. Salesforce becomes another service provider behind it, as in chapter 6, and the other apps trust that identity provider too.

That’s not a weakness of Salesforce. It’s where the people are. The identity provider should be the system that already knows them and switches them off when they leave. Module 6 comes back to this: it’s usually a blend.

Two ways to vouch

Salesforce has two ways to be the identity provider (S10). With SAML, you turn on Salesforce as an identity provider and register the service provider as a SAML-enabled app. With OpenID Connect, you don’t turn anything on as an identity provider; you register the other app, and it asks Salesforce who the person is. This chapter builds SAML, because it’s what one Salesforce org uses to vouch for another. OpenID Connect sits on OAuth, so chapter 9 builds it, after chapter 8 teaches OAuth.

On the map

On the grid of every way to sign in (chapter 5, module 6), this chapter is the set “Salesforce as the identity provider”. This module and the next turn two of its cards blue: the SAML identity provider, and Salesforce to Salesforce.

Click to enlarge

What’s next

Module 2: the dance. Two orgs, seven steps, back and forth in one order.

What an architect decides here

• Whether Salesforce should vouch at all, or be one more service provider behind the identity provider the company already has.
• Which org is the identity provider, when there are several: production, not a sandbox that gets refreshed.
• The certificate Salesforce signs with, the default or your own, and who renews it on both sides (chapter 3).

Explore

• Salesforce as an Identity Provider (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
• Enable Salesforce as a SAML Identity Provider (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)