Checkpoint challenge

Original, hands-on practice. Never modeled on actual exam questions. This closes the chapter Single Sign-On: The Browser Is the Broker, chapter 4 of Securing Salesforce: Identity and Access. You’ll connect these two orgs in chapter 7, so keep them.

Scenario

You’re the architect on a project that will turn on single sign-on for Salesforce. Nobody has set it up at your company before, and the first time anyone turns these knobs shouldn’t be in production.

So you build a lab: two free Salesforce orgs. One plays the identity provider, the one that pops up the login screen. The other plays the service provider, the Salesforce org people actually work in. Before you connect them, you set each one up so you can always tell which one you’re in, and so you can never lock yourself out.

This is the homework I give every class. It’s literally just a few settings, but it’s a little intricate. If you can build it, you know it.

Requirements

Two orgs: one identity provider, one service provider.
You can always tell them apart: by the address in the browser, and by the logo on the page.
Two admins: one in each org, who never uses single sign-on. They turn the knobs.
Two test users: a normal user in each org, the same person in both: Priya Sharma, the person this course follows. She’s the one you’ll test single sign-on with.

Constraints

Free, but use it or lose it. Developer Edition orgs cost nothing (S8). The sign-up form says Salesforce “may terminate any org that has been inactive for 45 days” (S8a). You’ll need these orgs again in chapter 7, so log in to both every few weeks.
No company data. These are lab orgs. Use invented names and nothing personal, not even in the My Domain name. Salesforce’s own advice: “Avoid entering personal information in your domain name” (S12).
Use your own email address. The form asks for a work email, and Salesforce sends the activation email there. The form doesn’t ask for a username: Salesforce gives each org its own. Keep a note of which username belongs to which org. If the form won’t take the same email twice, use an alias with a +, if your mail service supports it.

Your task

1. Sign up twice. Go to developer.salesforce.com/signup (S8). Today’s form asks for only a few things: your country or region, your state or province, and a work email. Read and accept the agreements, and select Sign me up (S8a). Each sign-up sends an activation email; open it, set the password, and log in. Then do it again for the second org. After activation, Salesforce’s developer site may offer you more than the org itself; what you need here is the org. Name each one at once, so you can tell them apart: in Setup, Company Information, set the company name to “SP org” or “IdP org”.

2. Rename each My Domain. This is an important part. Your My Domain is the address of your org, and single sign-on depends on it (module 3). In each org: from Setup, find My Domain, select Edit under My Domain Details, enter a new name, select Check Availability, and save (S12). In a Developer Edition org, the name can have 3 to 27 characters: letters, numbers and hyphens, but it can’t start with a hyphen. Choose names that say what each org is, such as yourcompany-identity-idp and yourcompany-identity-sp. Salesforce then provisions the new address, which “usually finishes in a few minutes, but it can take up to 24 hours”, and emails you when it’s ready to deploy. Deploy it, and log in again at the new address.

3. Give each org its own logo. When you switch between two browser tabs all day, the two orgs look exactly the same. So brand them. From Setup, find Themes and Branding, create a custom theme, and upload a logo (S13). Anything simple works: the letters “IdP” in one color, “SP” in another. Now one look at the page tells you which org you’re in.

4. Keep your admin out of single sign-on. The admin you signed up with is your back door in each org (module 5). It keeps its Salesforce password. Turn on multi-factor authentication for it, with a backup method, the way you would in production.

5. Create Priya twice. In each org, create a normal user, Priya Sharma, with a standard user profile. Give her the same name in both, but remember: her username in each org is different, because a username can belong to only one user in all of Salesforce. That’s the first thing single sign-on has to solve, and chapter 6 shows how (the federation ID). A Developer Edition org has a few Salesforce licenses; if the new user page says none is free, Company Information shows the licenses your org has.

6. Watch the redirects. Open a private browser window, so nothing is remembered, and open your browser’s developer tools on the Network tab. Turn on the option to keep the log between pages. Now go to your service provider’s My Domain address and log in as Priya. Look at the list. Find the responses whose status starts with 3: those are the redirects, the server saying “go there instead” (S7), with the new address in the Location header. Count them, and write down where each one sent the browser.

You’ve just watched the browser be the broker, with only one org. In chapter 7, the identity provider joins the list.

Discussion

Why two orgs, and not a real identity provider? Because you already know Salesforce, and you can get two for free. Salesforce can play the identity provider as well as the service provider, so you get both sides of the swim lane from module 3 without buying anything. You’ll see each side’s settings, which is the point: there aren’t many, but every one has to be exactly right.

Why the logos and the names? Because the most common mistake in a lab like this isn’t a setting. It’s being in the wrong org. You save a change in the identity provider that belonged in the service provider, and then spend an hour wondering why nothing works. The address and the logo stop that.

Why the My Domain? Single sign-on runs on addresses. The service provider sends the browser to the identity provider’s address, and the identity provider sends it back to the service provider’s address (module 3). If you rename a My Domain after single sign-on is set up, you’ve changed one of those addresses, and the other side doesn’t know. So settle the names first.

Why Priya, and not the admin? If the admin is your test user and you get a setting wrong, you’re locked out of the org you need to fix. Priya can fail all day; the admin keeps a password the whole time (module 5).

What did the redirects show? Even without single sign-on, a login is more than one request. You asked for one address and the browser was sent on to others, each time because a server answered with a 3xx and a new address. When the identity provider joins, nothing about that changes. There are just more stops, and one of them is a different system.

Check your lab

Before chapter 7, check your lab against module 5’s checklist:

The back door: each org has an admin with a password and MFA, who will never get Is Single Sign-On Enabled.
The addresses: both My Domain addresses are written down, and you’ve logged in at each, recently enough that neither org has gone 45 days without a login.
The test user: Priya exists in both orgs, and you’ve logged in as her in each.
No surprises: you can tell the two orgs apart at a glance.

Exam objectives exercised

IDC-1, IDC-3 (Identity Management Concepts): the identity provider and service provider roles, and the parts of a single sign-on setup.

Explore

Step One: Sign up for Salesforce Developer Edition (opens in a new tab) (Salesforce Developers, REST API Developer Guide; checked 2026-11-07)
Change Your My Domain Details (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
Personalize Your Org with Themes and Branding (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)