Skip to content
SteveTechArcSteveTechArc Courses

Salesforce as the Identity Provider

Chapter 7 of Securing Salesforce: Identity and Access, Part 2: Accepting and Providing Identity. New to single sign-on? Start with chapter 4, then chapter 6.

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

Salesforce can also sit in the other seat. It can be the one that vouches. This chapter puts it there, with two Salesforce orgs: one vouches, the other trusts, and Priya signs in once and goes from one to the other. Then it widens out: apps that aren’t Salesforce, and how to decide who should vouch for whom at all.

The ideas in this chapter

Section titled “The ideas in this chapter”
  • The same five steps, from the other seat. Only the login screen moves: it’s Salesforce’s own, in the identity provider org.
  • The keys change hands. Salesforce signs with its private key, and the service provider holds Salesforce’s certificate.
  • Salesforce should vouch where it already knows the people, and not for staff who already sign in to a corporate identity provider.
  • The dance: one org, then the other, then back, because each side needs values only the other has.
  • For SAML, the service provider is registered in files, a SAML external client app, deployed with the Metadata API. New connected apps need a request to Salesforce Support.
  • The certificate field is the service provider’s, and it only checks its signed requests.
  • Two questions prove it worked: which org am I in, and who am I logged in as? The Federation ID is the secret sauce.
  • SAML, OpenID Connect or an Experience Cloud site: what Salesforce sends depends on what the other app speaks, and who the people are.
  • It’s usually a blend: three or four ways of signing in, and the right identity provider for each group.

The picture

Section titled “The picture”

Here’s the chapter’s main picture: chapter 6’s swim lane, in the same cells, with Salesforce in the identity provider’s lane.

The same swim lane, with Salesforce as the identity provider Four lanes: Priya's browser; Salesforce, the identity provider org; the service provider org's login server; and the service provider org's instance. Step 1: the browser opens a link to a record in the service provider org, which has no session yet and redirects the browser to its login server. Step 2: the login server picks the identity provider from the button for the identity provider org, writes a SAML request and redirects the browser there. Step 3: at Salesforce's login screen in the identity provider org, Priya signs in with MFA; Salesforce signs the response and the assertion and sends the SAML response back. Step 4: the browser posts the response to the service provider org's address for answers; the login server checks it against the identity provider org's certificate and Issuer, finds Priya by her Federation ID, E10442, and redirects her with a session. Step 5: the browser asks again with the session, and Priya is in as the service provider org's Priya. Footnote: the same five steps as chapter 6; only the login screen moved. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-IAM-IDP-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} PRIYA'S BROWSER SALESFORCE: THE IDENTITY PROVIDER ORG THE SERVICE PROVIDER ORG: LOGIN SERVER THE SERVICE PROVIDER ORG: INSTANCE 1. Opens a link to a record in the service provider org No session yet redirects the browser to its login server 2. Goes to the login server redirected by the instance Which identity provider? the button for the identity provider org; writes a SAML request 3. Goes to the identity provider org redirected, with the SAML request Salesforce's login screen Priya signs in to the identity provider org, with MFA; Salesforce signs the response and the assertion 4. Hands over the response posts it to the service provider org's address for answers Checks it against the identity provider org's certificate and Issuer; finds Priya by her Federation ID, E10442 5. Back to the record redirected, with the session The record Priya is in, as the service provider org's Priya asks for the record redirect: go to the login server follows the redirect redirect to the IdP + SAML request SAML request SAML response posts the SAML response redirect + session asks again, with the session the record The same five steps as chapter 6. Only the login screen moved: it's Salesforce's own, in the identity provider org. HOW TO READ IT Salesforce as the identity provider: the one login screen the check passes © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The path through this chapter

Section titled “The path through this chapter”

Six modules, each standing on its own, and a practice.

  1. The Other Seat Turn it around; the same five steps; who holds what; the clock; when Salesforce should vouch, and when it shouldn’t; two ways to vouch.
  2. The Dance Before the dance; seven steps, two orgs; why back and forth; what changed since I filmed it.
  3. Registering the Service Provider Today What the identity provider needs; two ways to register it; three small files; the SAML file, value by value; the one people get wrong; who may go.
  4. The First Login, Watched A clean window; two questions; what Salesforce wrote; starting at the identity provider org; when it doesn’t work.
  5. Beyond Salesforce SAML for any app; OpenID Connect, the other way in; an Experience Cloud site; logging out everywhere; how to choose.
  6. Choosing the Identity Provider The question I always get; it’s usually a blend; four questions for each group; Steve Trucking, from the identity provider’s seat.

Then the practice: connect your two orgs, and log in from one to the other.

Check what stuck with the study guide.

What an architect decides here

Section titled “What an architect decides here”
  • Whether Salesforce should vouch at all, or be one more service provider behind the company’s identity provider.
  • Which org is the identity provider: production, not a sandbox that gets refreshed.
  • The subject type, and the one value both sides keep for each person.
  • External client app or connected app: new work in an external client app, and a plan for the connected apps you have.
  • Who may go, by permission set.
  • Where the files live, and who can read them in an outage.
  • SAML or OpenID Connect for each other app, and the identity provider for each group of people.

Beyond the exam: what AI changes. An agent acting for Priya in the service provider org gets there with her session, not one of its own, so who she is in that org decides what her agent can reach. Chapter 17 takes it further.

Explore

Section titled “Explore”

Each module lists its own sources, each checked 2026-11-07. Two to start with:

Next: OAuth: The Base Pattern.

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.