Study guide
Study guide for chapter 7 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. Which Salesforce technologies provide identity to another system is in its Salesforce as an Identity Provider section, 17% of the exam. Salesforce as a service provider, here the other half of the build, is in its Accepting Third-Party Identity in Salesforce section, 21%. The exam guide aligns to Summer ‘23, so check its current version before you book.
For the Exam
Section titled “For the Exam”Tick them off as you go. Each one links to where it’s taught.
The other seat (supports IDP-4)
- I can walk the SP-initiated flow with Salesforce as the identity provider, and say what moved: the login screen. (The same five steps, from the other seat)
- I know who holds which certificate: Salesforce signs with its private key; the service provider holds Salesforce’s certificate, from Download Certificate or Download Metadata. (Who holds what)
- I know Salesforce’s assertion is valid for 5 minutes, with a 30-second buffer. (The clock, from the other side)
- I can say when Salesforce should vouch and when the company’s identity provider should. (When Salesforce should vouch)
Connecting two orgs (supports IDP-4, TPI-1)
- I can put the setup in order across the two orgs, and say why it goes back and forth. (Seven steps, two orgs; Why back and forth?)
- I know the Federation ID links the two users, and both carry the same value. (Why back and forth?)
- I know what the identity provider needs from the service provider: the Entity ID, the Assertion Consumer Service URL, the subject type, and a certificate only if it signs its requests. (What the identity provider needs to know)
Registering the service provider (supports IDP-4)
- I know the two frameworks, external client app and connected app, and that new connected apps need a request to Salesforce Support since Spring ‘26. (Two ways to register it)
- I know a SAML external client app is set up through the Metadata API only, in three components. (Three small files)
- I can match each value in the SAML file to its pair on the service provider’s side. (The SAML file, value by value)
- I know the
certificatefield is the service provider’s, and what including it does. (The one people get wrong) - I know who may go is set by permission set or profile, and that Salesforce recommends permission sets. (Who may go)
The first login (supports IDP-4, TPI-1)
- I can test it with the two questions: which org am I in, and who am I logged in as? (Two questions)
- I know where each part of Salesforce’s response comes from: the Issuer, the Audience, the Recipient, the NameID, the two signatures. (What Salesforce wrote)
Beyond Salesforce (supports IDP-4)
- I can name the ways Salesforce provides identity to another system: SAML identity provider, OpenID Connect, and an Experience Cloud site as the identity provider. (Three ways Salesforce vouches)
- I know SAML needs Enable Identity Provider; OpenID Connect doesn’t. (OpenID Connect: the other way in)
- I know the subject types Salesforce can send, and what custom attributes and forced authentication are for. (SAML: the one you just built)
- I know single logout is front-channel only in Salesforce. (Logging out everywhere)
Choosing (supports IDP-4)
- I can choose an identity provider for each group of people, starting from what the company already has. (Four questions for each group)
Beyond the Exam
Section titled “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.
- Settle both My Domains before the dance, and keep two clean, clearly labelled orgs.
- Keep the identity provider side in production, not in a sandbox that gets refreshed.
- Keep the external client app’s files where the people who support single sign-on can find them, because Setup won’t show the SAML values.
- Test with a normal user, and keep every admin on a password and MFA.
- Don’t chain identity providers for staff: register the app with the company’s identity provider directly.
- When an app speaks both SAML and OpenID Connect, use the one its vendor recommends and tests the most.
- Plan the move from the connected apps you already have to external client apps.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Identity provider (IdP) | The system that vouches for who someone is; here, a Salesforce org |
| Service provider (SP) | The app that trusts the identity provider; here, the other org |
| Enable Identity Provider | The Setup switch that makes an org a SAML identity provider |
| Issuer | The identity provider’s unique name; for Salesforce, its My Domain unless set otherwise |
| External client app | Salesforce’s new generation of the connected app; for SAML, set up through the Metadata API |
| Connected app | The older framework; existing ones keep working, new ones need a Support request |
entityUrl | The service provider’s Entity ID, in the SAML file |
acsUrl | The service provider’s Assertion Consumer Service URL, where Salesforce sends the response |
| Subject type | What Salesforce puts in the assertion to name the person: username, Federation ID, user ID, a custom field or a persistent ID |
| Federation ID | The value both orgs keep for the same person, on each user record |
| Custom attributes | Extra facts about the user added to the assertion |
| Forced authentication | A service provider’s request that the user sign in again |
| OpenID Connect | The other way Salesforce vouches: an ID token, with no Enable Identity Provider |
| Single logout | Logging out of one app and the other together; front-channel only in Salesforce |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. A company wants its production org to sign people in to its test and training orgs. Which org is the identity provider, and why not a sandbox?
Production. The sandboxes are the service providers. A local external client app isn’t copied when a sandbox is refreshed, so an identity provider in a sandbox would lose its registrations at every refresh. Reread When Salesforce should vouch.
2. A new admin wants to finish the service provider org's single sign-on setting before touching the identity provider org. Why won't that work?
The service provider’s setting needs the identity provider’s Issuer, certificate and login address, from its metadata. So the identity provider org goes first, then the service provider, then back. Reread Why back and forth?
3. A team tries to create a new connected app in a new org to register a SAML service provider, and can't. What do you tell them?
Since Spring ‘26, creating connected apps is turned off by default and needs a request to Salesforce Support. Register it as an external client app instead: for SAML, three files deployed with the Metadata API. Reread Two ways to register it.
4. A reviewer says the SAML file must include a certificate, or single sign-on won't be signed. Is that right?
No. The certificate field is the service provider’s, for its signed requests; with it, Salesforce requires every request to be signed. Salesforce signs its responses with its own certificate, from the Identity Provider page. Reread The one people get wrong.
5. Priya signs in at the identity provider org, but the service provider org won't let her in, and Login History says no user was found. What do you check?
The two Federation IDs. The identity provider sends the Federation ID of its Priya; the service provider looks for a user with the same value. One is missing or different. Reread When it doesn’t work.
6. A web app wants to let people log in with their Salesforce credentials, and it speaks OpenID Connect. Do you need to enable Salesforce as an identity provider?
No. With OpenID Connect you register the app and give it the openid scope; it gets an ID token. Enable Identity Provider is for SAML. Reread OpenID Connect: the other way in.
7. Staff already sign in to Microsoft Entra ID every morning. A project wants Salesforce to be their identity provider for a new app. What's your answer?
Use what the company already has: register the app with Entra ID, and keep Salesforce as one more service provider beside it. One identity provider for staff, and one place to switch them off. Reread One identity provider behind another.
Explore
Section titled “Explore”- Salesforce as an Identity Provider (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.