Skip to content

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?

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.

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

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.

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 responseWhere it came from
IssuerThe 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 RecipientacsUrl, the service provider’s address for answers
AudienceentityUrl, the service provider’s Entity ID
NameIDPriya’s Federation ID in the identity provider org, E10442, because subjectType is FederationId
Two signaturesSalesforce signs the response body and the assertion (S5), with SHA-256 and the certificate on the Identity Provider page
The timesValid “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.

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.

The IdP-initiated flow, with Salesforce as the identity provider The IdP-initiated flow, with Salesforce as the identity provider, in 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: Priya's browser goes first to the identity provider org's own My Domain address; at Salesforce's login screen she signs in with MFA. Step 2: from inside the identity provider org, she chooses the service provider org, and Salesforce writes and signs a SAML response, with no request to answer. Step 3: the browser posts the response to the service provider org's address for answers; its login server checks the identity provider org's certificate and Issuer, finds Priya by her Federation ID, E10442, and redirects her with a session. Step 4: she's in, on Home or the relay state's page, as the service provider org's Priya. Marked green: the shortcut, a response with no request. Footnote: chapter 6's four steps, from the other seat: Salesforce supports both IdP-initiated and SP-initiated login for SAML, as Salesforce Help says, checked 2026-11-07. {"author": "Steve Simpson", "blueprint": "1.0.1", "builder": "standard 1.59.0", "built": "2026-11-07", "id": "DGM-IAM-IDP-08", "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. Goes to the identity provider org first thing, its own My Domain address Salesforce's login screen Priya signs in to the identity provider org, with MFA 2. Chooses the service provider org from inside the identity provider org Writes the response Salesforce signs a SAML response, with no request to answer 3. Hands over the response posts it to the service provider org's address for answers Checks it the identity provider org's certificate and Issuer; finds Priya by her Federation ID, E10442 4. Into the service provider org with the session Home, or the relay state's page Priya is in, as the service provider org's Priya opens it signed in picks the org SAML response posts the SAML response redirect + session asks, with the session the page Chapter 6's four steps, from the other seat: Salesforce supports both IdP-initiated and SP-initiated login for SAML, as Salesforce Help says, checked 2026-11-07. HOW TO READ IT the shortcut: a response with no request © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

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.

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 entityUrl or acsUrl in 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).

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.

Module 5: beyond Salesforce, the apps that aren’t Salesforce.

  • 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.