Steve Trucking

Module 7 of 7 in the chapter SSO or OAuth? Choosing the Mechanism, chapter 5 of Securing Salesforce: Identity and Access, and the end of Part 1. Original practice, never modeled on actual exam questions.

The question this checkpoint answers: Can you take a real company, list everyone and everything that signs in, and choose a door for each?

Scenario

Steve Trucking is a regional delivery company. It runs on Salesforce: dispatch, finance, account management and its partner relationships all live in one org. You’re the identity architect, and before anyone builds anything, the CIO wants one page: who signs in, to what, and how.

Here’s what you’ve learned in the discovery workshops.

• Staff (dispatchers, finance, account managers and the Salesforce admins) work in the org in a browser all day. The company already uses Microsoft Entra ID as its identity provider; it came with Microsoft 365, and everyone signs in to email with it.
• Retail Partners, the large retailers whose goods Steve Trucking delivers, have staff who use a partner site to see deliveries to their distribution centers. Most of these retailers have their own identity provider, and they want their people to use it. A few don’t.
• Small partner carriers, the trucking companies Steve Trucking subcontracts to, also use the partner site. Most of them have no identity system at all; some are a family and three trucks.
• Crews, the drivers and helpers, use a mobile app on their phones all day: their stops, the proof of delivery photos, the signatures. The app reads and writes Salesforce data through the API.
• Recipients, the people receiving a delivery, follow it on a tracking page. Most just tap the link in a text message. A few want an account, to see their past deliveries and set their preferences.
• The route data service sends updated routes overnight, and the company’s integration layer moves orders between Salesforce and the warehouse systems. Neither has a person at the keyboard. One rule from finance: a change to a customer’s credit terms must show the account manager who approved it, even when the integration layer makes it.

Requirements

• Every group above has a door, and you can say why.
• Nobody’s password is handed to another system.
• Nothing you choose is on the “leaving” list in module 6.
• You can still get into the org if the identity provider has a bad day.

Your task

1. List everyone and everything that signs in. Six groups. For each, answer the two questions: who starts it, and what does it reach?
2. Draw the lines. One box for Salesforce, the partner site and the tracking page; one box for each group; one line for each way in, starting where the call starts.
3. Choose the door for each line, using the decision table in module 6.
4. Find the one that needs a named person, and decide how you’ll meet finance’s rule.
5. Mark the back door.

Try it before you read on.

Discussion

Here’s how I’d answer it. Your words will be different; the doors should match.

Click to enlarge

Staff: single sign-on with Entra ID. A person in a browser, on Salesforce’s own pages: the top row. They already sign in to Entra ID every morning, so Salesforce becomes another service provider behind it. One place for passwords and MFA, and one switch when someone leaves. Chapter 6 sets it up.

The back door: two admins. Before you lock the front door, know where the back door is. Two admins keep a local Salesforce login with strong MFA, and never get single sign-on switched on for them (chapter 4, module 5). That’s requirement four.

Retail Partner users: their own identity provider. Still a person in a browser, so still no OAuth. But the identity provider isn’t Steve Trucking’s; it’s each retailer’s. The partner site trusts each one separately, and a retailer without one gets site logins. Chapters 10 and 14 cover it.

Small carriers: Salesforce logins on the site. A person in a browser, with no identity provider to bring. The site checks who they are itself, with MFA or a passwordless login. Chapters 14 and 15.

Crews: OAuth, web server flow with PKCE. A person, but through a mobile app reaching the API: the little line. The app sends the driver to log in once, gets a token and a refresh token, and doesn’t ask again every stop. Chapter 9.

Recipients: the tracking link, and social sign-on as an option. A person in a browser, on a page. Most need no account at all; the link in the text message carries a token that expires. The few who want an account can sign up with a social login. Still no OAuth for Steve Trucking to set up for them; the social provider is their identity provider (chapter 10).

The route data service and the integration layer: client credentials. No person there, reaching the API. First ask: should we just use the integration user? Here, yes: one integration user for each, each with only the access it needs, on the client credentials flow (chapter 11).

Finance’s rule: JWT bearer, for that one change. The credit terms change must carry the account manager’s name. That’s a process acting as a chosen person, so the integration layer uses the JWT bearer flow for that change, with only the account managers pre-authorized. If the security team won’t allow that much trust, ask whether Entra ID can issue an assertion, and use the SAML bearer assertion flow instead. Either way, everything else stays on client credentials.

What’s not on the page. No usernames and passwords in any integration, no user-agent flow in the mobile app. Count the doors: six kinds of sign-in, and four of them need no OAuth at all. It’s usually a blend.

Exam objectives exercised

• IDC-1 (Identity Management Concepts): common authentication patterns and how they differ.
• IDP-1 (Salesforce as an Identity Provider): choosing the right OAuth flow.

Explore

• Module 6 of this chapter, The Decision Table.