The Dance
Module 2 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: To connect two Salesforce orgs with single sign-on, what do you do in which org, and why do you go back and forth?
Before the dance
Section titled “Before the dance”When I build this live in a class, it takes about five minutes. That surprises people. But the five minutes only work because of what’s done before.
You need two orgs, and you need to always know which one you’re in. In chapter 4’s practice, you gave each one its own My Domain and its own logo, an admin who never uses single sign-on, and a test user, Priya. That’s about half the effort, and it matters. The addresses are very important in single sign-on: almost every value you’ll exchange is built from them. So settle each My Domain before you start. Change it later, and the values change with it (chapter 6, module 7).
And keep the admins out of it. You’ll test with Priya. If a setting is wrong, Priya can fail all day; the admin still gets in with a password and MFA.
Seven steps, two orgs
Section titled “Seven steps, two orgs”Here’s the order. I call it the dance, because you go from one org to the other and back.
In the identity provider org:
- Enable the identity provider. From Setup, find Identity Provider and select Enable Identity Provider. Keep the default certificate, self-signed with SHA-256, and save (S1). In a new Developer Edition org it may already be on. If it is, check the certificate and move on.
- Take its metadata. Select Download Metadata: one XML file that describes this identity provider (S1). It carries the Issuer, the certificate and the address where requests should go. Note the Issuer on the page too.
In the service provider org:
- Turn on SAML, and add the setting. In Single Sign-On Settings, enable SAML, then select New from Metadata File and choose the file from step 2. Salesforce fills in what it can. Set the identity type to the Federation ID, and save. That’s chapter 6, module 3, field by field.
- Priya, and the button. Give Priya her Federation ID: E10442, her employee number, the value that will never change for her. Then, in My Domain’s Authentication Configuration, add the identity provider’s button beside the login form. Keep the login form, for the admin.
- Read the Endpoints. On the saved setting, the Endpoints section shows two values the identity provider needs: the service provider’s Entity ID and its address for answers, the Assertion Consumer Service URL.
Chapter 6’s practice did steps 2 to 5. If you followed it, you’re halfway through the dance already.
Back in the identity provider org:
- Register the service provider. Tell the identity provider about the app it will vouch for: a SAML-enabled app (S2). It holds the two values from step 5, the Entity ID and the address for answers, and the subject type, which says what Salesforce puts in the assertion to name the person. Set it to the Federation ID (S7).
- Say who may go. The identity provider decides who it will vouch for into this app, by profile or permission set. Give Priya a permission set for it. And give Priya in this org the same Federation ID, E10442 (S6).
Then the first login, which is module 4. When it works, I always ask the room two questions: which org am I in, and who am I logged in as? You’ll see the answer there.
Why back and forth?
Section titled “Why back and forth?”Why not do one org, then the other, and be done? Because each side needs values that only the other one has.
The service provider can’t trust the identity provider until it has the identity provider’s Issuer and certificate. Those come from the identity provider, in the metadata file. So the identity provider goes first.
The identity provider can’t send an assertion anywhere until it knows the service provider’s Entity ID and its address for answers. Those don’t exist until the service provider’s setting is saved. So you have to go back.
Chapter 6 gave you the six pairs that must match, with the service provider’s column filled in. The dance fills in the other column:
| The pair | Comes from | Goes to |
|---|---|---|
| The identity provider’s Issuer | Identity provider org, step 2 | The service provider’s setting, step 3 |
| The certificate | Identity provider org, step 2 | The service provider’s setting, step 3 |
| The identity provider’s login address | Identity provider org, step 2 | The service provider’s setting, step 3 |
| The service provider’s Entity ID | Service provider org, step 5 | The registered app, step 6 |
| The address for answers | Service provider org, step 5 | The registered app, step 6 |
| Priya’s Federation ID | You choose it: E10442 | Both users, steps 4 and 7 |
Look at the last row. It’s the only one that isn’t copied from one org to the other. You choose it, and you put the same value on both users. That’s the secret sauce: the Federation ID on the identity provider’s Priya and the Federation ID on the service provider’s Priya are what link them together. Her usernames in the two orgs are different, and they always will be; the Federation ID is what’s the same.
What changed since I filmed it
Section titled “What changed since I filmed it”When I filmed this build, step 6 was New Connected App: a few fields in Setup, a couple of pasted addresses, done. That’s still how existing orgs do it, and those connected apps keep working. But since Spring ‘26, creating a new connected app is off by default in every new org, and you need a request to Salesforce Support to do it (S3, S8). Salesforce’s way now is an external client app.
Nothing about the dance changes. Same order, same values, same reason to go back. What changes is how step 6 looks, and module 3 shows it.
It isn’t that complex
Section titled “It isn’t that complex”Once you’ve done it, it really isn’t that complex. You just need to get the little intricacies right: the right value in the right org, in the right order. If you can do this yourself, from two clean orgs, you’ve got single sign-on totally nailed, from both seats.
Watch it on video
Section titled “Watch it on video”In 2023 I filmed this whole build, from two brand-new orgs to the first login. The note under the video says what’s still right and what’s changed since.
What’s next
Section titled “What’s next”Module 3: registering the service provider today, step 6 in detail.
What an architect decides here
Section titled “What an architect decides here”- The two My Domains, settled before the dance starts.
- Which value is the Federation ID, and who puts it on every user, in both orgs.
- Who may go: the profile or permission set the identity provider vouches for.
- Who owns each side, when the two orgs have different admins, and where the six pairs are written down.
Explore
Section titled “Explore”- Enable Salesforce as a SAML Identity Provider (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Complete Prerequisites for SAML Service Provider Integration (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Map Salesforce Users to the SAML Service Provider (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)