Skip to content
SteveTechArcSteveTechArc Courses

Salesforce as the Service Provider: SAML

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

Most companies sign their staff in to Salesforce from an identity provider they already run. Salesforce is the service provider: the system that trusts someone else to say who you are.

Chapter 4 showed what single sign-on is from the outside: a browser carrying messages between two systems that never call each other. This chapter sits inside Salesforce. Which setting does it read at each step? How does it find the right user? How does a link from an email still land on the right record? And when it all stops working one morning, where do you look first?

The ideas in this chapter

Section titled “The ideas in this chapter”
  • Five steps, five decisions. In an SP-initiated login, Salesforce reads one part of its single sign-on setting at every step.
  • The second app is still SP-initiated, with no login screen, because the identity provider already has her session.
  • The IdP-initiated flow is the SP-initiated flow with the first half cut off: the app launcher sends a SAML response, with no request to answer.
  • It’s the service provider that trusts the identity provider, so Salesforce holds the identity provider’s certificate.
  • Single sign-on is six pairs of values, each set on both sides, and every pair has to match. Getting them just right is the hard part.
  • Watch it with a SAML tracer. It’s not magic: a request, a response, a few redirects.
  • One signature required, both recommended, and the assertion’s signature is the one that counts most.
  • How she signed in now matters: since February 2026, a password-only assertion from a new device means Device Activation.
  • The Federation ID is the field Salesforce matches, and a stable code makes the best one.
  • The relay state has to be in every step, or a deep link lands on Home.
  • When it fails, get in first, then Login History, then the SAML Assertion Validator.

The picture

Section titled “The picture”

Here’s the chapter’s main picture: chapter 4’s swim lane, from Salesforce’s seat. The same five steps, and in Salesforce’s lane, the settings it reads.

The SP-initiated flow, from Salesforce's seat Four lanes: Priya's browser, the identity provider, Salesforce's login server and Salesforce's instance. Step 1: the browser opens a link to a Salesforce record; the instance has no session yet and redirects the browser to the login server. Step 2: the login server decides which identity provider to use, from the button on the My Domain login page or the Identity Provider Login URL, signs the request with the Request Signing Certificate, and redirects the browser to the identity provider with a SAML request. Step 3: at the identity provider's login screen, Priya signs in with MFA, and the identity provider sends back a signed SAML response. Step 4: the browser posts the response to Salesforce's address for answers; the login server checks it against the setting, the Identity Provider Certificate, the Issuer, the Entity ID and the time, finds the user by the SAML Identity Type, and redirects the browser back with a session. Step 5: the browser asks for the record again, with the session, and Priya is in. Footnote: the same five steps as chapter 4; what's new is the parts of the single sign-on setting Salesforce reads. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-IAM-SP-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} PRIYA'S BROWSER THE IDENTITY PROVIDER SALESFORCE'S LOGIN SERVER SALESFORCE'S INSTANCE 1. Opens a link to a Salesforce record No session yet redirects the browser to the login server 2. Goes to the login server redirected by the instance Which identity provider? the button on the My Domain login page, or the Identity Provider Login URL; signs the request with the Request Signing Certificate 3. Goes to the identity provider redirected, with the SAML request The login screen Priya signs in, with MFA; sends back a signed SAML response 4. Hands over the response posts it to Salesforce's address for answers Checks it against the setting the Identity Provider Certificate, the Issuer, the Entity ID, the time; finds the user by the SAML Identity Type 5. Back to the record redirected, with the session The record checks the session; Priya is in 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 4. What's new is in the two login server cards: the parts of the single sign-on setting Salesforce reads. HOW TO READ IT the identity provider: the one login screen the check passes © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The rest of the chapter grows this picture: the second app, the app launcher, the relay state riding every arrow.

The path through this chapter

Section titled “The path through this chapter”

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

  1. The SP-Initiated Flow, Step by Step Where we left the swim lane; five steps, five decisions; one more check since 2026; on the map.
  2. The Second App, and the IdP-Initiated Flow Ten minutes later; starting at the identity provider and its app launcher; what the shortcut changes.
  3. Setting Up Salesforce as the Service Provider Who trusts whom; the order; the single sign-on setting as pairs; the button on the login page; the back door; Steve Trucking and Entra ID.
  4. Watch It Happen A SAML tracer; the response as Salesforce receives it; each part and its field; two signatures; how she signed in.
  5. Who to Log In As: the Federation ID Three ways to name her; what makes a good Federation ID; where in the assertion; capital letters; when there’s no match.
  6. Deep Links: the Relay State The link in the email; it has to be in every step; why it gets lost; starting at the identity provider.
  7. When It Fails Get in first; Login History and the validator; clocks, certificates, mismatches, a My Domain change, Device Activation.

Then the practice: set up one of chapter 4’s two orgs as the service provider, ready for chapter 7.

Check what stuck with the study guide.

What an architect decides here

Section titled “What an architect decides here”
  • The identity provider for each group of staff, and its single sign-on setting in Salesforce.
  • Which flows to support: SP-initiated always; IdP-initiated if there’s an app launcher.
  • The pairs, written down for both sides, and who owns each side.
  • Which value is the Federation ID, and who fills it in for every user.
  • What the identity provider signs and sends: response and assertion, SHA-256, and an authentication context that shows MFA.
  • Where logins land, and the binding that keeps the relay state.
  • The back door, tested, and the plan for a certificate renewal or a My Domain change.

Beyond the exam: what AI changes. An agent working for one of your staff doesn’t come in through this door; it reaches Salesforce through the API, as chapter 5 showed. But the single sign-on setting still decides who that staff member is. Match the wrong Federation ID, and an agent acting for that person gets the wrong person’s access too. 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: Salesforce as the Identity Provider.

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.