Study guide

Study guide for chapter 4 of the Securing Salesforce: Identity and Access course. Read the six 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: describing common authentication patterns and how they differ, and how trust is established between two systems. Both are in its Identity Management Concepts section, 17% of the exam. Chapter 3 began the second one with keys and certificates; this chapter puts them to work. Chapters 5 to 7 carry both objectives further. 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.

Why single sign-on (supports IDC-1)

I know every system has two servers: a login server, which checks who you are and issues a session, and the resource, which only checks the session. (Every system has its own guard)
I know the identity provider proves who a person is, and each service provider trusts it instead of keeping its own password. (One place to prove who you are)
I can give the reasons companies do it: fewer, stronger passwords; one place for the password rules, the IP restrictions and the MFA; one way to reset; one switch when someone leaves. (Why companies do it)
I know the catch: if the identity provider is down or fooled, every system behind it is too. (The catch)

The actors (supports IDC-1)

I can name the actors: the browser, the identity provider, the identity store, and the service provider with its login server and its instance. (A cast of characters)
I know Active Directory is an identity store, not an identity provider, and that a directory can be read over LDAP. (The identity store)
I know the identity provider doesn’t get a person into Salesforce: it vouches for them to Salesforce’s login server, which issues the session. (The service provider, and its two servers)
I can apply the test: whichever system shows the login screen is the identity provider, and there should be only one. (The test)
I know Salesforce can be the service provider (chapter 6), the identity provider (chapter 7), or both, with two orgs. (Salesforce can play either part)

The browser is the broker (supports IDC-1)

I know a redirect is a status code in the 300s, most often 302, and that the browser, not the server, makes the next call. (The flicker)
I can walk through a service-provider-initiated login, hop by hop: instance, login server, identity provider with a SAML request, back with a signed SAML response, session, and back to the record. (One login, hop by hop)
I know the small SAML request usually rides in the URL, and the bigger SAML response is usually posted by the browser as a form, because URL length is limited. (How the messages travel)
I know each side needs the other’s addresses, the callback URLs, and that those addresses plus a certificate are most of the setup. (Each side needs the other’s addresses)
I know why the second system doesn’t ask for a login: the identity provider already has a session with the person. (The second login)

Trust without a connection (supports IDC-3)

I know the service provider trusts the identity provider, not the other way round. (Who trusts whom?)
I know the trust is the identity provider’s certificate, uploaded once into Salesforce’s single sign-on setting as the Identity Provider Certificate, while the private key never leaves the identity provider. (A certificate, installed once)
I know Salesforce’s login server checks every SAML response’s signature with that certificate, on the spot, with no call to the identity provider, and that a changed response fails. (Every login, checked on the spot)
I know trust can run the other way too: a Request Signing Certificate for Salesforce’s requests, and an Assertion Decryption Certificate for encrypted assertions. (Trust can run the other way too)
I know provisioning is a separate job, with its own credentials, and isn’t how anyone signs in. (The only direct line)
I know a replaced identity provider certificate has to be updated on both sides at once, or single sign-on stops. (When the certificate changes)

What the browser carries (supports IDC-1 and IDC-3)

I know SAML is Security Assertion Markup Language, an open standard (SAML 2.0, OASIS, 2005), and that an assertion is one system’s statement about a person to another. (A big old XML file)
I know the service provider writes the SAML request, not the browser, and that it carries the issuer, its own ID, a timestamp, and optionally a signature. (Who writes the request?)
I know the response names the request it answers, so it can’t come in cold, and that its status must say success. (The response)
I can name the assertion’s parts: issuer, subject (the Salesforce username or the Federation ID), conditions (not before, not on or after, and the audience), recipient, authentication statement, attributes and signature. (What’s inside the assertion)
I can find those parts in a sample SAML request and response: InResponseTo, Destination, Issuer, Status, the Assertion’s ID, NameID, Conditions, Audience, Recipient and the signature’s SHA-256 algorithms. (Open the messages)
I can ask the five questions, plus Salesforce’s sixth, and match each to its Login History error: Signature Invalid, Issuer Mismatched, Audience Invalid or Recipient Mismatched, Assertion Expired, Subject Confirmation Error, Replay Detected. (Five questions before Priya gets in)
I know the timestamps and the unique ID stop replay attacks, and Salesforce’s window: within 5 minutes of the timestamp, plus or minus 3 (up to 8 minutes after, or 3 before). (Why the times are there)

Keep a back door (supports IDC-1)

I know why a few admins need a local login: when single sign-on breaks, someone has to get in to fix it. (Who must have a local login?)
I know Disable login with Salesforce credentials applies only to users with the Is Single Sign-On Enabled permission, and Salesforce recommends leaving admins out of it. (The switch, and who it leaves out)
I know three more settings that can close the back door: the My Domain login policy, the Login Form checkbox and ?login, and single sign-on as the only login method. (Three more ways the door can close)
I know clocks that are out of step can break single sign-on for everyone, and keep a back door partly so someone can fix them. (The day it breaks)
I test single sign-on with a normal user, not an admin, and keep a backup admin with a password while I change it. (Test with a user, not an admin)

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.

Give the identity provider an owner, a support plan and its own security review. It’s now the most important system for getting work done.
Put the strongest MFA at the identity provider, and phishing-resistant MFA for anyone who holds the keys.
Ask how many directories there are before you design anything.
Draw single sign-on as a swim lane, each call with its answer. Fix any login diagram with an arrow between the identity provider and a service provider.
When a login fails, look at the addresses, the certificate and the clocks before anyone opens a firewall rule.
Put every certificate’s end date on a calendar, with an owner on each side.
Keep the system clocks aligned. The messages carry times, and a drifting clock refuses good ones.
Know the back door is there before you lock the front door, and test it on purpose, on a schedule.
Build it to know it. Two free orgs, a few settings, every one exactly right.

Words to Know

Term	In one line
Single sign-on (SSO)	Signing in once, at one system, and being trusted by the others
Identity provider (IdP)	The system that proves who a person is and vouches for them; the one with the login screen
Service provider (SP)	The system a person wants to use, which trusts the identity provider
Identity store	The directory of users and their credentials, such as Active Directory
LDAP	The standard way to read from a directory
Login server	A system’s security guard: it checks who you are and issues the session
Instance	Your Salesforce org, with its pages and data; it only checks the session
Redirect	A server’s answer in the 300s: “not here, go there instead”
Swim lane	A diagram with one lane per actor and time running down the page
SAML request	The service provider’s “please tell me who this is”, carried by the browser
SAML response	The identity provider’s signed statement about the person, carried by the browser
Service-provider-initiated	A login that starts at the service provider
Callback URL	Where one side sends the browser back to
Identity Provider Certificate	The identity provider’s certificate, installed in Salesforce, used to check every signature
Provisioning	Keeping each system’s user records up to date; a separate job from signing in
Local login	A direct login to Salesforce that doesn’t go through the identity provider
Is Single Sign-On Enabled	The permission that puts a user under Disable login with Salesforce credentials
Assertion	One system’s statement about a person to another; inside the SAML response
Issuer	Who sent a SAML message
Subject	Who to log in as: the Salesforce username or the Federation ID
Audience	Who an assertion is for; must match Salesforce’s Entity ID
Replay attack	Catching a message and using it again later
`?login`	Added to the login address, it brings back the username-and-password form

Check Yourself

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

1. A team says Active Directory is their identity provider. What do you ask?

What shows the login screen? Active Directory is an identity store: the directory where users and their credentials are kept. The identity provider sits in front of it, shows the login screen and checks the password against it. Name both on the diagram. Reread The identity store.

2. In a design review, two systems show a user a login screen in the same morning. Is that single sign-on?

Not yet. Whichever system shows the login screen is the identity provider, and there should be only one. If two do, the user is still signing in twice. Reread The test: who shows the login screen?

3. Priya has signed in to Salesforce through the identity provider. Ten minutes later she opens the HR system, which also uses it, and goes straight in. What happened?

The HR system redirected her browser to the identity provider, as Salesforce did. The identity provider already had a session with her, so it answered at once with a SAML response for the HR system, without a login screen. Reread The second login.

4. A landscape diagram shows an arrow from the identity provider to Salesforce labelled "SSO". The network team asks which firewall port to open. What do you tell them?

None, for the login. There’s no call between them: every message goes through the user’s browser, and Salesforce checks the signature with a certificate an admin installed in advance. Fix the diagram, and draw the login as a swim lane. Reread The wrong diagram.

5. Someone changes a SAML response on its way through the browser, to a user with more access. What happens?

The signature no longer matches, so Salesforce’s login server rejects it and the login fails. The identity provider signed the response with its private key, and Salesforce checks it with the installed certificate. Reread Every login, checked on the spot.

6. The identity provider's team issues a new certificate on Monday. On Tuesday morning, nobody can sign in to Salesforce. What's the likely cause?

The new certificate was installed on the identity provider’s side only. Salesforce still checks signatures with the old one. Replacing the certificate is a job for both sides at once. Reread When the certificate changes.

7. You turn on Disable login with Salesforce credentials, and give Is Single Sign-On Enabled to every user through one permission set, admins included. The identity provider goes down. Who can get in?

Nobody who has the permission, admins included, can log in with a Salesforce password. Keep Is Single Sign-On Enabled away from the two or three admins who hold the back door, and protect them with phishing-resistant MFA. Reread The switch, and who it leaves out.

8. An admin still has a password, but the org's login page shows only the identity provider's button. How does the admin get to the password form?

Add ?login to the end of the login address, and the username-and-password form comes back. Write it down, with the My Domain address, where the admins will find it. Reread Three more ways the door can close.

9. After a weekend, every single sign-on login fails, and Login History shows Assertion Expired for all of them. Nothing in the settings changed. What do you check?

The clocks. Each assertion is only valid inside a short window around its timestamp, compared against each side’s own clock. If either server’s clock has drifted beyond the window, every assertion looks expired. Fix the clock, through the back door if you have to. Reread Why the times are there.

10. A new identity provider is connected, and every login fails with Audience Invalid. What's wrong?

The assertion’s audience doesn’t match the Entity ID in Salesforce’s single sign-on setting. One side has the wrong value. Compare the two, and write the expected values down for both sides. Reread Five questions before Priya gets in.

Explore

SAML Login Errors (opens in a new tab), Salesforce Help (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.