The First Login, Watched
Module 4 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: With both orgs set up, what happens when Priya logs in, and how do you know it really worked?
A clean window
Section titled “A clean window”Open a private window, so nothing is remembered from before, and turn on the SAML tracer from chapter 6, module 4. Then go to the service provider org’s My Domain address, the one with the service provider’s logo.
You’ll see the login form and, beside it, the button for the identity provider org that you added in chapter 6’s practice. Choose the button.
Watch the address bar. You’ve left the service provider org: you’re on the identity provider org’s login page, with its logo. That’s the redirect, and the SAML request has just gone with it. Now sign in as Priya, with her identity provider password and MFA.
The tracer fills up, the address bar changes again, and you’re in a Salesforce org.
Two questions
Section titled “Two questions”When this works in a class, I always stop and ask the room two questions.
Which org am I in? Look at the logo and the address. It’s the service provider org. You asked for the service provider, it sent you to the identity provider, you logged in there, and it sent you back and let you in.
Who am I logged in as? Open the profile. It’s the service provider org’s Priya: a different user, with a different username, in a different org. Nobody typed a second password.
What joined the two Priyas is the Federation ID. The identity provider put E10442 in the assertion; the service provider looked for the user with E10442 in her Federation ID field, and let you in as her. That’s the secret sauce.
What Salesforce wrote
Section titled “What Salesforce wrote”Now look in the tracer for the SAML response, the one posted back to the service provider org. Chapter 6, module 4 opened a response part by part. This one has the same parts; what’s new is who wrote them. It’s Salesforce, from the values you deployed in module 3:
| In the response | Where it came from |
|---|---|
Issuer | The identity provider org’s My Domain, because the file left issuer out (S5). It matches the Issuer the service provider imported in chapter 6’s practice. |
Destination and Recipient | acsUrl, the service provider’s address for answers |
Audience | entityUrl, the service provider’s Entity ID |
NameID | Priya’s Federation ID in the identity provider org, E10442, because subjectType is FederationId |
| Two signatures | Salesforce signs the response body and the assertion (S5), with SHA-256 and the certificate on the Identity Provider page |
| The times | Valid “for 5 minutes after it’s issued, with a 30-second buffer to account for clock skew” (S1) |
That’s the whole trick, seen from the other seat. It’s not magic: a request, a response, a few redirects, and one value both sides agree on.
Starting at the identity provider org
Section titled “Starting at the identity provider org”The other way to start: Priya signs in to the identity provider org first, and goes from there into the service provider org, with a response and no request. That’s the IdP-initiated flow from chapter 6, module 2, with Salesforce as the identity provider. Salesforce supports both: “Salesforce supports identity provider-initiated login and service provider-initiated login for SAML” (S13). Chapter 6’s picture of the IdP-initiated flow holds; only the identity provider has changed.
Where Priya clicks to start it, for an app set up as a SAML external client app, is the one step this course hasn’t tested yet: look for the app in the identity provider org’s App Launcher. The SP-initiated login above is the one to get working first, and the one the practice depends on.
When it doesn’t work
Section titled “When it doesn’t work”If it doesn’t work the first time, it’s usually one value that’s off. Chapter 6, module 7 is the checklist, and from this side two places help:
- In the service provider org, Login History names the failure, and the SAML Assertion Validator checks the response you copied from the tracer against the single sign-on setting (chapter 6, module 7). An Audience or Recipient error means
entityUrloracsUrlin your file doesn’t match the service provider’s Endpoints; an Issuer error means the service provider expects a different issuer. - No user found means the two Federation IDs don’t match, or one is empty. Check both Priyas.
- In the identity provider org, the Identity Provider Event Log lists the latest login attempts and why each one failed, for example “User does not have a Federation Identifier selected” (S14). It’s the identity provider’s side of Login History. Chapter 16 says more.
- The clocks. Salesforce gives its assertion five minutes and a 30-second buffer (S1), so the service provider’s clock has to be right (chapter 6, module 7).
One more: logging out
Section titled “One more: logging out”If Priya logs out of the identity provider org, is she logged out of the service provider org? Not unless you set up single logout, and Salesforce supports only the front-channel kind: “If a browser session expires, users aren’t logged out of the other apps” (S9). The lab doesn’t set it up; module 5 says a word more.
What’s next
Section titled “What’s next”Module 5: beyond Salesforce, the apps that aren’t Salesforce.
What an architect decides here
Section titled “What an architect decides here”- How you’ll prove it worked: the two questions, and a test user who isn’t an admin.
- Which flows people will use: from a link (SP-initiated) and from the identity provider org (IdP-initiated).
- Whether single logout matters for this pair of apps.
Explore
Section titled “Explore”- Enable Salesforce as a SAML Identity Provider (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- ExtlClntAppSamlConfigurablePolicies (opens in a new tab) (Metadata API Developer Guide; checked 2026-11-07)
- Single Logout (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
