Checkpoint challenge

Original, hands-on practice. Never modeled on actual exam questions. This closes the chapter Salesforce as the Identity Provider, chapter 7 of Securing Salesforce: Identity and Access. It finishes the lab from chapter 4’s practice and chapter 6’s practice.

Scenario

Your lab has two Salesforce orgs, each with its own My Domain and logo, an admin who never uses single sign-on, and a test user, Priya Sharma. In chapter 6 you set up the service provider org: its single sign-on setting from the identity provider org’s metadata, Priya’s Federation ID, E10442, and the button on its login page. You also wrote down the pairs.

Now you finish it. You register the service provider org in the identity provider org, say who may go, and log in from one to the other. If you can do this yourself, from two clean orgs, you’ve got single sign-on nailed, from both seats.

Requirements

The identity provider org has the service provider org registered as a SAML-enabled external client app, from three small files.
Priya can use it, through a permission set, and carries the same Federation ID in both orgs.
Priya logs in once, at the identity provider org, and lands in the service provider org as the service provider org’s Priya.
The pairs page is complete: every value, on both sides.

Constraints

Lab orgs only. No company data, nothing personal.
Never turn single sign-on on for an admin. Both admins keep a password and MFA.
SHA-256 for anything that’s signed.
No connected app. New ones need a request to Salesforce Support; this lab uses an external client app.

Your task

1. Check where you are. Open your pairs page from chapter 6. You need two values from the service provider org’s single sign-on setting, in its Endpoints section: the Entity ID and the Assertion Consumer Service URL. Check the logos: you’ll switch orgs several times.

2. Give Priya her Federation ID in the identity provider org. Open her user record in the identity provider org, and under Single Sign On Information, set Federation ID to E10442, the same as in the service provider org (S6). The identity provider will send this value; the service provider will look for it.

3. Turn on external client apps in the identity provider org, if they aren’t on already. Salesforce’s metadata reference calls it the “Opt in to External Client Apps” permission in Setup (S11). The name on the Setup page may differ a little in your org; search Setup for “external client app”.

4. Make the permission set. In the identity provider org, create a permission set called “SSO to the service provider org” and assign it to Priya. Note its ID: it starts with 0PS, and you’ll find it in the address bar on its page.

5. Make the project. On your computer, make a folder for a small Salesforce DX project with these five files. They’re the same three components Salesforce describes (S4), with only SAML turned on.

sfdx-project.json:

{
  "packageDirectories": [{ "path": "force-app", "default": true }],
  "name": "saml-eca-lab",
  "namespace": "",
  "sourceApiVersion": "66.0"
}

package.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types><members>*</members><name>ExternalClientApplication</name></types>
    <types><members>*</members><name>ExtlClntAppConfigurablePolicies</name></types>
    <types><members>*</members><name>ExtlClntAppSamlConfigurablePolicies</name></types>
    <version>66.0</version>
</Package>

force-app/main/default/externalClientApps/ServiceProviderOrg.eca-meta.xml, the app:

<?xml version="1.0" encoding="UTF-8"?>
<ExternalClientApplication xmlns="http://soap.sforce.com/2006/04/metadata">
    <contactEmail>admin@example.com</contactEmail>
    <description>The service provider org, registered for SAML single sign-on (lab)</description>
    <distributionState>Local</distributionState>
    <isProtected>false</isProtected>
    <label>ServiceProviderOrg</label>
</ExternalClientApplication>

force-app/main/default/extlClntAppPolicies/ServiceProviderOrgPolicies.ecaPlcy-meta.xml, its policies. Turning plugins on turns all of them on unless each is turned off (S12), so only SAML is left on:

<?xml version="1.0" encoding="UTF-8"?>
<ExtlClntAppConfigurablePolicies xmlns="http://soap.sforce.com/2006/04/metadata">
    <externalClientApplication>ServiceProviderOrg</externalClientApplication>
    <isEnabled>true</isEnabled>
    <isCanvasPluginEnabled>false</isCanvasPluginEnabled>
    <isMobilePluginEnabled>false</isMobilePluginEnabled>
    <isNotificationPluginEnabled>false</isNotificationPluginEnabled>
    <isOauthPluginEnabled>false</isOauthPluginEnabled>
    <isPushPluginEnabled>false</isPushPluginEnabled>
    <isSamlPluginEnabled>true</isSamlPluginEnabled>
    <label>ServiceProviderOrgPolicies</label>
</ExtlClntAppConfigurablePolicies>

force-app/main/default/extlClntAppSamlConfigurablePolicies/ServiceProviderOrgSaml.ecaSamlPlcy-meta.xml, its SAML policies. Replace the three capitals with your values from steps 1 and 4:

<?xml version="1.0" encoding="UTF-8"?>
<ExtlClntAppSamlConfigurablePolicies xmlns="http://soap.sforce.com/2006/04/metadata">
    <externalClientApplication>ServiceProviderOrg</externalClientApplication>
    <label>ServiceProviderOrgSaml</label>
    <entityUrl>SP_ENTITY_ID</entityUrl>
    <acsUrl>SP_ACS_URL</acsUrl>
    <subjectType>FederationId</subjectType>
    <nameIdFormat>Unspecified</nameIdFormat>
    <signingAlgorithmType>SHA256</signingAlgorithmType>
    <commaSeparatedPermissionSet>PERMISSION_SET_ID</commaSeparatedPermissionSet>
</ExtlClntAppSamlConfigurablePolicies>

If an address has & in it, write it as & in the XML.

6. Deploy. Install the Salesforce CLI if you don’t have it. Log in to the identity provider org as its admin, then deploy from the project folder (S4):

sf org login web --alias idp-org --instance-url https://YOUR-IDP-DOMAIN.my.salesforce.com

sf project deploy start --manifest package.xml -o idp-org

If the deploy fails, read the error: it names the file and the field. Compare that field with module 3, then deploy again.

7. Check it. In the identity provider org’s Setup, find External Client App Manager: the app is there, but not its SAML values (S4). Retrieve the files to check what Salesforce holds:

sf project retrieve start --source-dir force-app -o idp-org

8. The first login. Open a private window and turn on your SAML tracer. Go to the service provider org’s My Domain address, choose the identity provider’s button, and sign in as Priya at the identity provider org. Then answer the two questions: which org are you in, and who are you logged in as? In the tracer, find the SAML response and check its Issuer, Audience, Recipient and NameID against your pairs page.

9. Start at the identity provider org. In a new private window, sign in to the identity provider org as Priya, and go into the service provider org from there. Look for the app in the App Launcher. This start hasn’t been tested in this course for a SAML external client app; if you don’t find the app there, step 8’s login is the one that matters, and the identity provider org’s Identity Provider Event Log (module 4) shows what it received.

10. Finish the pairs page. Fill in every blank from chapter 6: the identity provider side of each pair, and where each value lives (the file, the Identity Provider page, the user).

Discussion

Why give Priya E10442 in both orgs? Because the identity provider puts the Federation ID of its Priya in the assertion, and the service provider looks for a user with that value in its Federation ID field. Her usernames are different and always will be. The Federation ID is what’s the same.

Why a permission set, and not “everyone”? The identity provider decides who it vouches for. Here it’s one person; in a company, it’s the people who should reach that app. Salesforce recommends permission sets over profiles for it (S5).

Why isn’t there a certificate in the SAML file? The certificate field is the service provider’s, for its signed requests (S5). The certificate that makes single sign-on work is the identity provider org’s own, and the service provider took it from the metadata file in chapter 6.

Where would you look if Priya got an Audience error? In the service provider org’s Login History, then at entityUrl in your file against the Entity ID in the service provider’s Endpoints. One of them is different (module 4).

What happens to this app if the identity provider org is a sandbox and it’s refreshed? It’s gone: local external client apps aren’t copied on a refresh (module 1). That’s why the identity provider side belongs in production.

Check your lab

The app: in External Client App Manager, deployed from three files you keep.
Priya: E10442 in both orgs, and the permission set in the identity provider org.
The login: from the service provider’s button, through the identity provider org, back in as the service provider org’s Priya.
The back door: both admins still log in with a password and MFA.
The pairs page: no blanks.

Exam objectives exercised

IDP-4 (Which Salesforce technologies provide identity to a third-party system): Salesforce as a SAML identity provider.
TPI-1 (When Salesforce acts as a service provider): the other half, connected.

Explore

Integrate a SAML SSO Service Provider as an External Client App (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
ExtlClntAppSamlConfigurablePolicies (opens in a new tab) (Metadata API Developer Guide; checked 2026-11-07)
Map Salesforce Users to the SAML Service Provider (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)