Study guide

Study guide for chapter 6 of the Securing Salesforce: Identity and Access course. Read the seven modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter carries two of the Identity and Access Management Architect exam’s objectives. Salesforce as a service provider is in its Accepting Third-Party Identity in Salesforce section, 21% of the exam. How trust is established between two systems is in its Identity Management Concepts section, 17%. The exam guide aligns to Summer ‘23, so check its current version before you book.

For the Exam

Tick them off as you go. Each one links to where it’s taught.

The SP-initiated flow (supports TPI-1)

I can walk through the SP-initiated flow in five steps and say what Salesforce does at each. (Five steps, five decisions)
I know how Salesforce chooses the identity provider: a button on the My Domain login page, and the Identity Provider Login URL. (Which identity provider?)
I know which fields Salesforce checks the response against: the Identity Provider Certificate, the Issuer, the Entity ID, the time, and the SAML Identity Type. (The checks)

The other flows (supports TPI-1)

I know the second app of the day is SP-initiated again, with no login screen, because the identity provider has her session. (Ten minutes later)
I know the IdP-initiated flow starts at the identity provider, usually its app launcher, with a SAML response and no request. (Starting at the identity provider)
I know what having no request changes: no InResponseTo to match, and she lands on Home unless a relay state says otherwise. (What the shortcut changes)

Setting it up (supports TPI-1, IDC-3)

I know the service provider trusts the identity provider, so Salesforce holds the identity provider’s certificate. (Who trusts whom)
I can set up the order: My Domain, gather from the identity provider, the setting (from a metadata file where there is one), Salesforce’s Endpoints back to the identity provider, the login page, a test, the back door. (The order)
I can name the pairs that must match on both sides, and the field for each. (The single sign-on setting)
I know the back door: ?login on the My Domain address, and an admin with a password and MFA. (Keep the back door)

Watching it (supports TPI-1, IDC-3)

I know how to watch a login with a SAML tracer. (Watch the back and forth)
I can match each part of a response to the field that checks it, and the Login History error if it fails. (Each part, and the field that checks it)
I know Salesforce requires one signature, the response’s or the assertion’s, checks the response first, and recommends both. (Two signatures, and which one counts)
I know the authentication context decides whether a new device needs Device Activation (since February 2026). (How she signed in)

Finding the user (supports TPI-1)

I can name the three SAML Identity Types: the username, the Federation ID and the user ID, and the two locations. (Three ways to name her)
I know why a stable code makes a better Federation ID than a username or an email. (What makes a good Federation ID)
I know Salesforce matches users by default, and creating them is just-in-time provisioning (chapter 12). (When there’s no match)

Landing in the right place (supports TPI-1)

I know the relay state carries the original page through every step, and that she lands on Home if it’s lost. (It has to be in every step)
I know a relay state must be a path inside the org. (Starting at the identity provider)

When it fails (supports TPI-1, IDC-3)

I know where to look first: Login History, then the SAML Assertion Validator. (Then look in two places)
I can name the usual causes: clocks, an expired certificate, a value that doesn’t match, a My Domain change, and Device Activation prompts. (The usual causes)

Beyond the Exam

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

Write every pair down, for both sides, before you set anything up.
Use the identity provider’s metadata file, then check every value it filled in.
Test the back door before you turn single sign-on on for anyone.
Choose a Federation ID that never changes, and decide who fills it in for every user.
Ask the identity provider to sign the response and the assertion, with SHA-256, and to say how people signed in.
Watch a login with a SAML tracer before the day you need to.
Put the identity provider’s certificate expiry on a calendar, next to your own.
Plan a My Domain change with the identity provider’s team in the room.

Words to Know

Term	In one line
Service provider (SP)	The system that trusts the identity provider to say who someone is; here, Salesforce
SP-initiated flow	A login that starts at the service provider, with a SAML request
IdP-initiated flow	A login that starts at the identity provider, with a SAML response and no request
App launcher	The identity provider’s page of buttons, one for each app a user can open
SAML single sign-on setting	The Salesforce setting that holds everything about one identity provider
Issuer	The identity provider’s unique name, which must match the response
Entity ID	Salesforce’s own name in the relationship, usually the My Domain address
Assertion Consumer Service (ACS) URL	Salesforce’s address for SAML responses, shown in the setting’s Endpoints
Identity Provider Certificate	The identity provider’s certificate, uploaded to Salesforce to check signatures
Metadata file	An XML file from the identity provider with its settings, to create the setting from
SAML Identity Type	Whether the assertion names the user by username, Federation ID or user ID
Federation ID	A field on the user record that holds the value the identity provider sends
SAML tracer	A browser extension that shows the SAML messages in a login
Authentication context	The part of an assertion that says how the user signed in
Device Activation	Salesforce’s check of a device it doesn’t recognize
Relay state	The value that carries the original page through a SAML login
SAML Assertion Validator	A Setup tool that checks an assertion against the setting

Check Yourself

Short scenarios in the style of the course. Decide your answer before you open it.

1. A user signs in to the company's identity provider, opens the expense app, then ten minutes later clicks a link to a Salesforce record. Which flow, and does she see a login screen?

The SP-initiated flow: Salesforce has no session for her and sends a SAML request. She sees no login screen, because the identity provider already has her session from this morning. Reread Ten minutes later.

2. Users start their day at the identity provider's app launcher and click Salesforce. A reviewer asks where the SAML request is. What do you say?

There isn’t one. That’s the IdP-initiated flow: the identity provider sends a signed SAML response straight away, with nothing for it to answer. Salesforce still checks the signature, issuer, audience, time window and the assertion’s ID. Reread What the shortcut changes.

3. After setup, every login fails, and Login History shows Audience Invalid. Where do you look?

At the Entity ID. The audience in the assertion must match the Entity ID in Salesforce’s setting; one side has a different value. Compare them and fix one. Reread Each part, and the field that checks it.

4. A project wants to send users' email addresses as the identifier, because "everyone has one". What's your concern?

Email addresses change, with names, domains and mergers, and then the login stops matching. Use a stable code the identity provider already holds, such as an employee number, as the Federation ID. Reread What makes a good Federation ID.

5. Users click links to opportunities in emails, sign in through single sign-on, and always land on Home. What's happening?

The relay state is being lost, most often at the identity provider. Watch a login with a SAML tracer, find where it disappears, and check that the binding matches what the identity provider expects. Reread Why it gets lost.

6. Logins suddenly fail with Assertion Expired, though the assertions were just made. What do you check first?

The clocks. Salesforce accepts an assertion within 5 minutes of its timestamp, plus or minus 3, measured against its own clock. If the identity provider’s servers have drifted, every assertion looks expired. Reread The clocks.

7. The company renames its My Domain. The next morning, single sign-on fails for everyone. Why, and what should have happened first?

The change gave Salesforce a new Entity ID and a new address for answers, and the identity provider still has the old ones. Give it the new values from the setting’s Endpoints. Before the change, make sure an admin can log in without single sign-on. Reread A My Domain change.

8. Since February 2026, staff who sign in with MFA at the identity provider are asked to activate their device in Salesforce. What's the likely cause?

The assertion’s authentication context says a password, not MFA, so Salesforce can’t tell they used a secure method. Ask the identity provider’s team to send the authentication context that matches how people sign in. Reread How she signed in.

Explore

Step 2: Create a SAML Single Sign-On Setting in Salesforce (opens in a new tab), Salesforce Help (Winter ‘27; checked 2026-11-07)
Salesforce Certified Platform Identity and Access Management Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-07)

The official list of objectives and their weights. Always check the current version before you book an exam.