Skip to content

Study guide

Study guide for chapter 10 of the Securing Salesforce: Identity and Access course. Read the five 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: choosing the mechanism for accepting third-party identity, in its Accepting Third-Party Identity section, 21% of the exam; and supporting external identity providers in communities, in its Community section, 18%. The exam guide aligns to Summer ‘23, so check its current version before you book.

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

Social sign-on (supports TPI-3, COM-2)

  • I can say who is the identity provider and who is the client in social sign-on. (Who’s the client?)
  • I can walk social sign-on as the web server flow reversed: the button, the provider’s login and consent, the code, the swap, the user info. (Five steps, in the mirror)
  • I can name the three single sign-on flows into Salesforce: SP-initiated SAML, IdP-initiated SAML, and social sign-on or OpenID Connect. (Three ways in)

Auth providers (supports TPI-3, COM-2)

  • I know social sign-on is set up with an auth provider, and the choices: a ready-made type, OpenID Connect, or a custom one in Apex. (A ready-made list)
  • I know not every type does single sign-on: GitHub and Microsoft Access Control Service don’t; X does, but gives no data access. (A ready-made list)
  • I can put the pieces in order: the provider’s app, its key and secret, the URL suffix, the callback URL back into the provider’s app, the button. (The pieces)
  • I know the button’s Icon URL shows only on an Experience Cloud site’s login page. (The button)
  • I know the Salesforce type connects two orgs, with an external client app in the identity provider org. (Between two Salesforce orgs)

The registration handler (supports TPI-3, COM-2)

  • I know social sign-on needs a registration handler, the Auth.RegistrationHandler interface. (Two methods)
  • I know its two methods: createUser the first time, updateUser every time after. (Two methods)
  • I know it runs as the Execute Registration As user, who needs Manage Users. (The user it runs as)
  • I know it can be Apex or a flow. (Apex or Flow)

Where it fits (supports COM-2)

  • I know social sign-on is most likely for customers on an Experience Cloud site, and staff come in through the company’s identity provider. (Three groups, three doors)

Delegated authentication (supports TPI-3)

  • I can walk delegated authentication: Salesforce’s login page collects the password, calls your SOAP web service, and gets back true or false. (True or false)
  • I know the permission is Is Single Sign-On Enabled, and Salesforce doesn’t store the password. (True or false)
  • I know what it gives up: no password reset, and it doesn’t meet the MFA requirement. (What you give up)
  • I know when to choose it: only when the store can’t learn SAML or OpenID Connect. (The better answer first)

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.

  • A registration handler that checks before it lets anyone in, and refuses rather than guess.
  • Validate the ID token before trusting a claim from it.
  • PKCE on every auth provider, and your own app in production, not the Salesforce-managed one.
  • Ask only for the data you’ll use, so the consent matches the need.
  • Teach the legacy store SAML or OpenID Connect before you reach for delegated authentication.
  • Keep admins off delegated authentication, so somebody can always get in.
TermIn one line
Social sign-onLogging in to Salesforce with an account at another provider, such as Google
Auth providerThe setup in Salesforce that sends people to another provider and brings them back
Relying partyThe org that trusts another for login; here, Salesforce in the mirror
URL suffixThe auth provider’s name in the addresses Salesforce generates for it
Callback URLWhere the provider sends the person back with the code; goes into the provider’s app
Registration handlerThe Apex class or flow that decides which Salesforce user she becomes
Auth.UserDataThe one shape Salesforce gives the handler, whatever the provider sent
createUserRuns the first time; returns a user, new or existing
updateUserRuns every time after; updates her user
Execute Registration AsThe user the handler runs as; needs Manage Users
Delegated authenticationSalesforce asks your web service whether the password is right
Is Single Sign-On EnabledThe permission that sends a user’s password check to your service
Delegated Gateway URLYour web service’s address, in Single Sign-On Settings

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

1. In social sign-on with LinkedIn, which system is the identity provider, and which is the client?

LinkedIn is the identity provider: it collects her credentials. Salesforce is the client: it asks LinkedIn for her information. Reread Who’s the client?.

2. A team is building social sign-on for a customer site. Which class do they implement, and with which two methods?

Auth.RegistrationHandler, with createUser and updateUser. Or they build it as a flow. Reread Two methods.

3. After social sign-on goes live, people with no relationship to the company are getting users and using up licences. What went wrong?

The registration handler creates a user for anyone who signs in. It needs checks before createUser returns anyone: who may come in, matched to whom, with which profile and licence. Reread The checks.

4. A company wants its staff to log in to Salesforce with their personal Google accounts, "to save setting up single sign-on". What do you say?

Staff should come in through the company’s identity provider, so leaving is one switch and the company sets their MFA. Social sign-on is for people nobody manages but themselves, such as customers. Reread Three groups, three doors.

5. A company's users and passwords live in an old directory. Its team can't change it, and it can't speak SAML. How can those users log in to Salesforce with those passwords?

Delegated authentication: give them Is Single Sign-On Enabled, and Salesforce sends each login to your SOAP web service, which answers true or false. Keep the admins off it. Reread True or false.

6. An org puts every profile on delegated authentication. One morning the web service is down. What happens, and what should have been different?

Nobody on delegated authentication can log in, admins included. Always keep some users, starting with the admins, on Salesforce passwords. Reread Don’t lock yourself out.

7. Two Salesforce orgs need their users to log in to one with the other's credentials, over OAuth. What do you set up, and where?

An external client app in the identity provider org, and an auth provider of type Salesforce in the other org with its key and secret; the auth provider’s callback URL goes back into the app. Reread Between two Salesforce orgs.

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