Skip to content
SteveTechArcSteveTechArc Courses

Checkpoint challenge

Original, hands-on practice. Never modeled on actual exam questions. This closes the chapter Salesforce as the Service Provider: SAML, chapter 6 of Securing Salesforce: Identity and Access. It uses the two orgs you built in chapter 4’s practice. Keep them: chapter 7 connects them.

Scenario

Section titled “Scenario”

Your lab has two Salesforce orgs: one that will be the identity provider, and one that will be the service provider, the org people work in. Each has its own My Domain, its own logo, an admin who never uses single sign-on, and a test user, Priya Sharma.

Now you set up the service provider’s side. When you’re done, the service provider knows which identity provider to trust, how to check what it sends, and how to find Priya when it says who she is. Chapter 7 does the identity provider’s side, and that’s where the first login happens.

Requirements

Section titled “Requirements”
  • The service provider org has a SAML single sign-on setting for the identity provider org, made from the identity provider’s metadata.
  • Priya has a Federation ID in the service provider org, and you know which value the identity provider will send for her.
  • The login page of the service provider shows a button for the identity provider.
  • The pairs are written down: every value from module 3, for both sides.
  • The back door still works.

Constraints

Section titled “Constraints”
  • Lab orgs only, as in chapter 4: no company data, nothing personal.
  • Never turn single sign-on on for the admin. Do everything as the admin, with a password and MFA. Priya is the only one who will use single sign-on.
  • SHA-256 for anything you choose to sign.

Your task

Section titled “Your task”

1. Check your addresses. Log in to both orgs, as each admin. Write down both My Domain addresses, exactly as they appear in the browser: https://, the name, .my.salesforce.com (or the Developer Edition form you see). Every value below comes from these two. Check the logos: you should always know which org you’re in.

2. In the identity provider org: turn it on, and take the metadata. This one step is borrowed from chapter 7. From Setup, find Identity Provider, select Enable Identity Provider, keep the default certificate (self-signed, SHA-256), and save. Then select Download Metadata: an XML file that describes this identity provider, for a service provider to use (S12). On the same page, note the Issuer, the identity provider’s unique name (S12). That’s all for this org, for now.

3. In the service provider org: turn on SAML. Switch to the service provider org (check the logo). From Setup, find Single Sign-On Settings, select Edit, and select SAML Enabled. Leave Make Federation ID case-insensitive on (S1). Save.

4. Create the setting from the metadata file. Select New from Metadata File, choose the file from step 2, and create it (S1). Salesforce fills in as much as it can. Now check every field against module 3:

  • Name: call it after the identity provider org, the name people will see on the button.
  • Issuer: the Issuer you noted in step 2. Does it match?
  • Identity Provider Certificate: filled from the file.
  • Entity ID: your service provider’s My Domain address.
  • SAML Identity Type: Assertion contains the Federation ID from the User object.
  • SAML Identity Location: Identity is in the NameIdentifier element of the Subject statement.
  • Request Signature Method, if you sign requests: RSA-SHA256.
  • Identity Provider Login URL: filled from the file, the identity provider org’s address for SAML requests.

Save. On the setting’s page, find the Endpoints section (S10). Write down the Assertion Consumer Service URL and the Entity ID: chapter 7 gives them to the identity provider.

5. Give Priya a Federation ID. In the service provider org, open Priya’s user record and edit it. Find the Federation ID field and set it to a value that will never change for her, her employee number: E10442, the same value as in module 4’s sample. Write it down. In chapter 7, the identity provider will send exactly this value for its Priya.

6. Add the button. From Setup, find My Domain, edit Authentication Configuration, and select your new setting alongside the login form (S7). Keep the login form: your admin still logs in with a password. Save.

7. Look, and try the back door. Open a private window and go to the service provider’s My Domain address. You should see the login form and a button with your identity provider’s name. Don’t press the button yet; chapter 7 finishes the other side. Now add ?login to the address and check that you can still log in as your admin with a password and MFA (S1). That’s your back door, tested.

8. Write the pairs. Make a page with module 3’s six pairs, each with the value on the identity provider’s side and the value in your setting: the issuer, the Entity ID, the address for answers, the certificate (its name and expiry date), the login address, and Priya’s Federation ID. Some identity-provider values will be blank until chapter 7. That page is your map for chapter 7, and for module 7 of this chapter if anything goes wrong.

Discussion

Section titled “Discussion”

Why from the metadata file? Because every value you type is a chance for a typo, and one wrong letter means nobody gets in. The file carries the issuer, the certificate and the login address together. But check them anyway: you’re the one who has to know why each value is there.

Why does the service provider hold the identity provider’s certificate, and not the other way round? Because the service provider is the one trusting. Salesforce lets Priya in on the identity provider’s word, so it has to be able to check that word: the signature, with the identity provider’s certificate. The identity provider doesn’t need Salesforce’s certificate to log Priya in.

Why a Federation ID, and not the username? Priya’s usernames in the two orgs are different, and they don’t look like anything the identity provider holds. A Federation ID is a value you choose, that both sides keep for the same person. In a company, it would be the employee number the identity provider already has (module 5).

Why keep the login form on the page? For the admin. If you remove it and the identity provider fails, the button is the only way in, and it doesn’t work. ?login still gets you in, but leave the form until you’re sure (module 7).

What would break if you renamed a My Domain now? The Entity ID and the address for answers both change, and the identity provider, once it’s set up, would still have the old ones. That’s why chapter 4 had you settle the names first (module 7, S10).

Check your lab

Section titled “Check your lab”
  • The setting: saved, from the metadata, with the Federation ID as the identity type and the issuer you checked.
  • Priya: has a Federation ID, and you’ve written it down.
  • The login page: shows the button and the login form.
  • The back door: ?login works, and the admin has a password and MFA.
  • The pairs: on one page, with the blanks chapter 7 will fill.

Exam objectives exercised

Section titled “Exam objectives exercised”
  • TPI-1 (Accepting Third-Party Identity in Salesforce): Salesforce as a service provider.
  • IDC-3 (Identity Management Concepts): how trust is established between two systems.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.