No Arrow Between Them

Module 4 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: If the identity provider and Salesforce never call each other, why does Salesforce believe what the identity provider says?

Who trusts whom?

Here’s a question I ask every class. When you set up single sign-on between an identity provider and a service provider, who is trusting whom? Is the identity provider trusting the service provider, or is the service provider trusting the identity provider?

The service provider trusts the identity provider. Salesforce is the one being asked to let Priya in on someone else’s word. So Salesforce needs a way to be sure that the word really came from her company’s identity provider, and that nobody changed it on the way through her browser.

You already know how that’s done. It’s chapter 3.

A certificate, installed once

When single sign-on is set up, the identity provider gives Salesforce its certificate. In practice, an admin downloads the certificate from the identity provider and uploads it into Salesforce’s single sign-on setting, in a field Salesforce calls the Identity Provider Certificate. Salesforce’s own help says it plainly: the certificate “is shared by the IDP… team and needs to be uploaded in Salesforce.”

Remember what’s in a certificate: the public key, the silver key, and the name of whoever owns it. The private key, the gold key, stays with the identity provider and never leaves. That’s the whole relationship. It’s a pre-installed certificate, but there’s no actual communication between the identity provider and the service provider. That’s the secret of this thing.

Click to enlarge

Every login, checked on the spot

Now watch what happens at every login, using the swim lane from module 3.

The identity provider builds its SAML response, the statement that says “this is Priya, and here’s how she proved it”, and signs it with its private key. The response travels back through Priya’s browser to Salesforce’s login server. The login server checks the signature with the certificate it already holds. In Salesforce’s words, that certificate is “used to verify SAML assertions sent from the IDP to Salesforce.”

Notice what the login server doesn’t do. It doesn’t call the identity provider to ask “did you really send this?” It doesn’t need to. The check happens right there, on Salesforce’s side, in milliseconds. It’s the same idea as your browser checking a website’s certificate against the root certificates it already holds (chapter 3, module 4): you trust what you installed in advance, and check everything else against it.

And if anyone changes the response on its way through the browser, say from Priya to someone with more access, the signature no longer matches, and the login fails. That’s the bandits changing “the mountain road” to “the river road” in chapter 3, module 3, and getting caught.

Trust can run the other way too

Two settings let the trust work in the other direction as well. Both are optional, and chapter 6 sets them up.

• Signed requests. Salesforce can sign its SAML requests with a certificate of its own, which the identity provider installs. Salesforce’s setting for this is the Request Signing Certificate: it “generates the signature on a SAML request to the identity provider.” Now the identity provider can be sure the request really came from Salesforce.
• Encrypted assertions. The identity provider can also encrypt what it says about Priya, so only Salesforce can read it on the way through the browser. Salesforce then decrypts it with an Assertion Decryption Certificate it holds.

Either way, the idea is the same: certificates installed in advance, and messages carried by the browser.

The wrong diagram

So why does this matter so much? Because of the diagrams people draw.

When I see a system landscape with an arrow between the identity provider and Salesforce, that’s not correct. There’s an installed certificate, but no call. And that one wrong arrow causes real trouble:

• Firewall rules get opened for a call that never happens. The network team is asked to let the identity provider reach Salesforce, or the other way round, and spends days on it.
• People look for logs that don’t exist. When a login fails, they search for the failed call between the two systems. There isn’t one. The answers are in Salesforce’s login history and the browser.
• The real cause gets missed. “The connection is down” is usually an expired certificate, a certificate that was replaced on one side only, or a wrong address on one side.

That’s why single sign-on gets a swim lane, not a landscape. In a swim lane, every arrow goes through the browser, and there’s simply no place to draw the wrong one.

The only direct line

Is there ever real traffic between an identity provider and a service provider? Sometimes, but it isn’t the login. A company may run a job that pushes new users, changes and leavers from the identity provider into Salesforce, so the user records stay up to date. That’s a separate job, called provisioning, and it’s chapter 12. It has its own credentials and its own arrow. It isn’t how anyone signs in.

For completeness: the SAML standard does have one way of sending messages where the service provider calls the identity provider directly to collect the full response (the Artifact binding). Salesforce’s setting doesn’t offer it; it uses the redirect and the posted form from module 3.

When the certificate changes

Because the whole relationship rests on that installed certificate, replacing it is a job for both sides at once. Certificates expire (chapter 3, module 7). When the identity provider’s certificate is due, the identity provider’s team issues a new one and shares it, and a Salesforce admin uploads it. Salesforce’s advice is to “plan to update certificates on both the IDP side and Salesforce simultaneously.” Miss it, and in Salesforce’s words, “users will be unable to authenticate via SSO.”

So the certificate’s end date belongs on someone’s calendar, with an owner on each side.

What’s next

So everything rests on one identity provider, one certificate and a few addresses. What happens on the day one of them breaks, and the people who could fix it can’t sign in either? Module 5: keep a back door.

What an architect decides here

• Draw single sign-on as a swim lane. If a diagram shows an arrow between the identity provider and a service provider for logins, fix the diagram.
• Know every certificate in the relationship: whose it is, where it’s installed, who renews it and when.
• Decide whether Salesforce signs its requests and whether the identity provider encrypts its assertions.
• Keep provisioning separate: its own job, its own credentials, its own diagram (chapter 12).

Explore

• Step 2: Create a SAML Single Sign-On Setting in Salesforce (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
• Salesforce Platform: Replace an Expired Certificate in SSO (Single Sign-On) Settings (opens in a new tab) (Salesforce Help, 2026-04-02; checked 2026-11-07)