Skip to content
SteveTechArcSteveTechArc Courses

Registering the Service Provider Today

Module 3 of 6 in the chapter Salesforce as the Identity Provider, chapter 7 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: In the identity provider org, how do you tell Salesforce about the app it will vouch for?

The step that changed

Section titled “The step that changed”

Module 2 walked the dance. Step 6 was the one where you go back to the identity provider org and register the service provider. When I build it live, it’s the quickest step: a few fields, the two addresses pasted in, the Federation ID chosen, a profile given access. All I need is a couple of pieces of information back from the service provider.

The pieces haven’t changed. The screens have.

What the identity provider needs to know

Section titled “What the identity provider needs to know”

Whatever the tool, the identity provider needs four things from the service provider (S7):

  • The Entity ID: the service provider’s unique name. For a Salesforce org, it’s on its single sign-on setting’s Endpoints, usually its My Domain address.
  • The address for answers: the Assertion Consumer Service URL, where Salesforce sends the SAML response. Also on the Endpoints.
  • The subject type: what the service provider expects to find in the assertion to name the person. In the lab, the Federation ID.
  • A certificate, only if the service provider signs its requests. More on that below: it’s the one people get wrong.

Those are chapter 6’s pairs, seen from the other side.

Two ways to register it

Section titled “Two ways to register it”

Salesforce gives two frameworks for it: an external client app or a connected app. In its own words, “The external client apps framework is the new generation of the connected apps framework” (S2).

The connected app is the one in my videos, and many orgs have them today. They keep working. But since Spring ‘26, creating a new connected app is turned off by default in new orgs, in Setup and through the Metadata API, and needs a request to Salesforce Support (S8). And Salesforce says that “In future releases, Salesforce Support won’t be able to enable the creation of new connected apps” (S8).

So for anything new, it’s an external client app. Here’s the part to know: “For SAML, the external client apps framework currently supports only Metadata API configuration” (S2). There’s no SAML page to fill in. You describe the app in files and deploy them.

Three small files

Section titled “Three small files”

A SAML-enabled external client app is three pieces of metadata (S4):

A SAML external client app: three files Two columns: your project's three files, and the identity provider org. File 1, the app: its name and contact, and Local, because a SAML app can't be packaged. File 2, its policies: the SAML plugin on and every other plugin off. File 3, its SAML policies: the Entity ID, the address for answers, the subject type, SHA-256 and who may go. All three are deployed together into the identity provider org, where External Client App Manager shows the app but not its SAML values. Footnote: one command deploys all three, sf project deploy start with the manifest; to change one value, deploy all three again. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-IAM-IDP-06", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} YOUR PROJECT: THREE FILES THE IDENTITY PROVIDER ORG 1. The app name, contact; Local: a SAML app can't be packaged 2. Its policies the SAML plugin on, every other plugin off 3. Its SAML policies Entity ID, address for answers, subject type, SHA-256, who may go External Client App Manager shows the app, but not its SAML values the app the plugins the SAML values One command deploys all three: sf project deploy start --manifest package.xml. To change one value, deploy all three again. HOW TO READ IT the org that vouches © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge
  1. The app (ExternalClientApplication): its name, a contact email, and distributionState Local. It has to be Local, because “External client apps with SAML configurations can’t be packaged or distributed” (S4).
  2. Its policies (ExtlClntAppConfigurablePolicies): which plugins the app uses. SAML on. Turning plugins on turns them all on unless you turn each one off (S12), so OAuth, mobile and the rest are set off by name.
  3. Its SAML policies (ExtlClntAppSamlConfigurablePolicies): the values from the service provider.

You put them in a small Salesforce DX project with a package.xml that lists all three, and deploy them with the Salesforce CLI, sf project deploy start --manifest package.xml. To check, retrieve them back (S4). To change anything, change the file and deploy all three again: “You can’t deploy a single component” (S4). The practice gives you the files, with a placeholder for each value.

The SAML file, value by value

Section titled “The SAML file, value by value”

Here’s the third file for the lab, with Priya’s service provider org in it:

<ExtlClntAppSamlConfigurablePolicies xmlns="http://soap.sforce.com/2006/04/metadata">
    <externalClientApplication>ServiceProviderOrg</externalClientApplication>
    <label>ServiceProviderOrgSaml</label>
    <entityUrl>https://MyDomainName.my.salesforce.com</entityUrl>
    <acsUrl>https://MyDomainName.my.salesforce.com?so=00Dx00000000001</acsUrl>
    <subjectType>FederationId</subjectType>
    <nameIdFormat>Unspecified</nameIdFormat>
    <signingAlgorithmType>SHA256</signingAlgorithmType>
    <commaSeparatedPermissionSet>0PSx00000000001</commaSeparatedPermissionSet>
</ExtlClntAppSamlConfigurablePolicies>

Read it against chapter 6, module 3. Every pair has its other half here.

The six pairs, from the identity provider's side Two columns: the identity provider org, and the service provider org's single sign-on setting, with six pairs. Its own name, the Issuer, your My Domain unless issuer is set, goes in the message as the Issuer and matches the setting's Issuer. Who the app is, entityUrl from the service provider's Endpoints, goes as the Audience and matches the Entity ID. Where to send answers, acsUrl, goes as the Destination and Recipient and matches the Assertion Consumer Service URL. Its signing key, the certificate on the Identity Provider page with the private key kept in the org, makes the signature, checked with the Identity Provider Certificate from the metadata file. Its login address, in the metadata file the service provider imported, is where the setting's Identity Provider Login URL sends the SAML request. Who she is, subjectType FederationId and Priya's Federation ID E10442, goes as the NameID and matches the SAML Identity Type, Federation ID, where her user has E10442 too. Footnote: chapter 6 set the right-hand column; the identity provider org holds the left; one value wrong on either side and nobody gets in. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-IAM-IDP-07", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} IN THE IDENTITY PROVIDER ORG IN THE SERVICE PROVIDER'S SETTING Its own name the Issuer: your My Domain, unless issuer is set Issuer Who the app is entityUrl, from the service provider's Endpoints Entity ID usually the My Domain address Where to send answers acsUrl, from the service provider's Endpoints Assertion Consumer Service URL made by Salesforce when you save Its signing key the certificate on the Identity Provider page; the private key stays here Identity Provider Certificate from the metadata file Its login address in the metadata file the service provider imported Identity Provider Login URL Who she is subjectType FederationId, and Priya's Federation ID: E10442 SAML Identity Type Federation ID; her user has E10442 too Issuer in the message Audience in the message Destination and Recipient the signature the SAML request goes here NameID in the Subject Chapter 6 set the right-hand column; the identity provider org holds the left. One value wrong on either side, and nobody gets in. HOW TO READ IT set in the identity provider org © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge
  • entityUrl is the service provider’s Entity ID, “a globally unique ID that Salesforce uses to recognize the service provider” (S5).
  • acsUrl is its address for answers, “the endpoint where the service provider receives SAML responses from Salesforce” (S5).
  • subjectType says what goes in the assertion to name her. Salesforce can send the username, the Federation ID, the 15-character user ID, a custom field, or a persistent ID (S5). The lab uses FederationId, because both users carry E10442.
  • nameIdFormat is the format of that name. Unspecified is the default; take the value from the service provider (S5).
  • signingAlgorithmType is how Salesforce signs. It signs both the response body and the assertion (S5). Use SHA-256.
  • issuer isn’t in the file, on purpose. Left out, it’s your My Domain (S5), which is exactly what the service provider org imported from the metadata. Set it only for something else, such as an Experience Cloud site (module 5).

One more value lives on the user, not the app. With the Federation ID as the subject type, “you must provide a Federation ID in the user’s Salesforce settings” (S6): Priya, in the identity provider org, gets E10442 too.

The one people get wrong

Section titled “The one people get wrong”

There’s a certificate field, and it looks as if it belongs here. It does, but not the way you’d think. It’s the service provider’s certificate, the one it uses to sign its SAML requests, and you include it “only if your service provider signs SAML requests”. Then “Salesforce requires that all SAML requests from the service provider are signed. If you don’t include a certificate, Salesforce accepts all SAML requests, whether or not they’re signed” (S5).

So it isn’t the certificate that makes single sign-on work. That’s Salesforce’s own, on the Identity Provider page, and the service provider already has it from the metadata. This one is an extra check on the requests coming in.

Test knowledge. In my experience, know which certificate is whose. When Salesforce is the identity provider, it signs with its own certificate, and the service provider holds that one. The service provider’s certificate, if it’s registered at all, only checks the service provider’s signed requests.

Who may go

Section titled “Who may go”

The identity provider decides who it will vouch for into this app. In the SAML file, that’s commaSeparatedPermissionSet or commaSeparatedProfile: IDs, separated by commas. Salesforce recommends permission sets over profiles (S5). In the lab, you make one permission set, give it to Priya, and put its ID in the file.

What Setup shows, and what it doesn’t

Section titled “What Setup shows, and what it doesn’t”

After the deploy, the app is in External Client App Manager in Setup. But “you can’t view or edit its SAML configuration information from Setup” (S4). The file is the only place the values live.

For an architect, that cuts both ways. The configuration is in source control, reviewed and deployed like any other metadata, and it goes to each org the same way. But an admin looking at Setup during an outage can’t see the values. So keep the files where the people who support single sign-on can find them, beside the six pairs you wrote down in chapter 6.

Two more facts to plan around. Local external client apps aren’t copied when a sandbox is refreshed (S8), as module 1 said. And Salesforce’s pages disagree on editions. The page for SAML external client apps lists the Developer, Performance and Unlimited Editions (S4); the page for Salesforce as a SAML identity provider, which covers both external client apps and connected apps, adds Enterprise (S13). If your org is Enterprise Edition, check the current page for your org before you plan on a SAML external client app.

What’s next

Section titled “What’s next”

Module 4: the first login, watched.

What an architect decides here

Section titled “What an architect decides here”
  • External client app or connected app: new work in an external client app; a plan for the connected apps you already have.
  • The subject type, and the one value both sides keep for each person.
  • Who may go, by permission set.
  • Where the files live, who can deploy them, and who can read them in an outage.
  • Whether the service provider signs its requests, and so whether its certificate is registered.

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.