Skip to content
SteveTechArcSteveTechArc Courses

Setting Up Salesforce as the Service Provider

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

The question this module answers: What do you set up in Salesforce so that it trusts an identity provider, and what has to match on the other side?

Who trusts whom

Section titled “Who trusts whom”

Before any settings, one question. In single sign-on, who trusts whom?

The service provider trusts the identity provider. Salesforce is going to let people in because the identity provider says so. So the trust is set up on Salesforce’s side: Salesforce holds the identity provider’s certificate, and checks every response against it. The identity provider doesn’t need to trust Salesforce in the same way. That’s why the certificate goes onto the service provider, as you saw in chapter 4, module 4.

Everything in this module is that one idea, written down as settings.

The order

Section titled “The order”

Here’s the order I’d set it up in. It’s the same at every company, whatever the identity provider.

  1. My Domain. Salesforce’s single sign-on works through your org’s own address, its My Domain. Check what yours is before you start: it ends up in half the values below.
  2. Gather from the identity provider. Its name (the issuer), its login address, its certificate, and how it will identify each user (S2). Many identity providers give you all of this in one metadata file.
  3. Create the single sign-on setting in Salesforce.
  4. Give the identity provider Salesforce’s side: its Entity ID and its address for answers.
  5. Add the button to the My Domain login page.
  6. Test with one user, and keep the back door.

The single sign-on setting

Section titled “The single sign-on setting”

From Setup, find Single Sign-On Settings. Turn on SAML Enabled if it isn’t already. To change these settings you need Customize Application and Modify All Data (S1).

Then create the setting. You can type every field yourself, or start from the identity provider’s metadata file or metadata URL, and Salesforce fills in as much as it can (S1). Use the file when you have one. It’s fewer chances to get a value wrong.

Give it a Name. If you put the identity provider on the login page, this is the name people see on the button, so Salesforce suggests using the identity provider’s own name (S1).

Now the fields. I find it easiest to think of them as pairs. Each value is set twice, once at the identity provider and once here, and the two have to agree.

The pairs that must match Two columns: at the identity provider, and in Salesforce's single sign-on setting. Six pairs. The identity provider's own name pairs with Salesforce's Issuer field, carried as the Issuer in the message. Who the app is, Salesforce's name from its Endpoints, pairs with the Entity ID, usually the My Domain address, carried as the Audience. Where to send answers pairs with the Assertion Consumer Service URL, which Salesforce makes when you save, carried as the Destination and the Recipient. The identity provider's signing key, whose private key stays at the identity provider, pairs with the Identity Provider Certificate uploaded to Salesforce, checked through the signature. The identity provider's login address pairs with the Identity Provider Login URL, where the SAML request goes. Who she is, the value the identity provider sends for Priya, pairs with the SAML Identity Type, her username, Federation ID or user ID, carried as the NameID in the Subject. Footnote: one value wrong on either side, and nobody gets in; write each pair down for both sides. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-IAM-SP-04", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} AT THE IDENTITY PROVIDER IN SALESFORCE'S SINGLE SIGN-ON SETTING Its own name the identity provider's issuer ID Issuer Who the app is Salesforce's name, from its Endpoints Entity ID usually the My Domain address Where to send answers Salesforce's address for answers, from its Endpoints Assertion Consumer Service URL made by Salesforce when you save Its signing key the private key stays at the identity provider Identity Provider Certificate its certificate, uploaded Its login address where requests go Identity Provider Login URL Who she is the value it sends for Priya SAML Identity Type her username, Federation ID or user ID Issuer in the message Audience in the message Destination and Recipient the signature the SAML request goes here NameID in the Subject One value wrong on either side, and nobody gets in. Write each pair down for both sides. HOW TO READ IT set at the identity provider © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Here they are with what Salesforce does with each.

Field in SalesforceWhat it holdsWhat it must match
IssuerThe identity provider’s unique name, usually an addressThe Issuer in every response (S1)
Entity IDSalesforce’s own name in this relationship; for most orgs, the My Domain addressOne of the Audience values in the assertion (S1)
Identity Provider CertificateThe identity provider’s certificate, uploadedThe key that signed the response (chapter 3)
Identity Provider Login URLWhere Salesforce sends the SAML requestThe identity provider’s real login address
SAML Identity Type and LocationHow the identity provider names the user, and where in the assertionThe value on Priya’s user record (module 5)
Service Provider Initiated Request BindingHTTP POST or HTTP RedirectWhat the identity provider asks for
Request Signing Certificate and Request Signature MethodSalesforce’s own certificate, if it signs its requests; RSA-SHA256What the identity provider expects, if it checks

A few more fields you’ll see: Assertion Decryption Certificate, if the identity provider encrypts its assertions; Custom Logout URL, where people go when they log out; and Custom Error URL, a public page to show when a login fails (S1).

One choice in the Request Signature Method: Salesforce still offers RSA-SHA1. Choose RSA-SHA256. Chapter 3 explains why SHA-1 is finished.

When you save, Salesforce makes its own side of the pairs. On the setting’s page, the Endpoints section shows the values the identity provider needs from you: the Assertion Consumer Service (ACS) URL, Salesforce’s address for answers, and the Entity ID (S10). Give those to the identity provider. That’s step 4.

So that’s the hardest part of single sign-on, and I mean that. It’s installing a certificate and putting some addresses in, and getting them just right. One letter wrong in an Entity ID and nobody gets in. Write every pair down, for both sides, before you start.

The button on the login page

Section titled “The button on the login page”

Users need a way to choose the identity provider. In Setup, My Domain, edit Authentication Configuration, and select your new setting as an authentication service. Its button appears on the My Domain login page, and a click sends the user to the identity provider (S7). If you have several identity providers, Salesforce suggests the Login Discovery page type instead (S7); chapter 15 shows it.

Keep the back door

Section titled “Keep the back door”

Chapter 4, module 5 said it, and I’ll say it again here: before you turn this on for everyone, make sure someone can still get in when the identity provider can’t.

Salesforce gives you a way. If the identity provider is down, the standard Salesforce login page is still there: add ?login to your My Domain address, https://MyDomainName.my.salesforce.com?login (S1). Keep at least one admin who logs in with a Salesforce password and MFA, not through the identity provider. And test the back door before you need it.

At Steve Trucking

Section titled “At Steve Trucking”

Steve Trucking’s staff sign in from Microsoft Entra ID, which came with the company’s Microsoft 365. Entra ID has Salesforce in its gallery of ready-made apps. The Entra admin adds it, chooses SAML, and downloads Entra’s metadata file. In Salesforce, the admin creates the setting from the metadata file, then adds it to the My Domain login page (S8). The Entity ID and the address for answers go back into Entra’s side.

And two of Steve Trucking’s admins keep a local Salesforce login, with their own MFA. That’s the back door.

Practice

Section titled “Practice”

This chapter’s practice picks up the two orgs you built in chapter 4. You set up one of them as the service provider: its single sign-on setting, ready for an identity provider, and its login page. Chapter 7 turns the other org into the identity provider, and the first single sign-on login between them happens there.

What’s next

Section titled “What’s next”

Module 4: watch the login happen, and read what Salesforce actually receives.

What an architect decides here

Section titled “What an architect decides here”
  • Who owns each side: the Salesforce admin and the identity provider’s team, and the pairs written down for both.
  • Metadata file or by hand, and who keeps the identity provider’s certificate up to date (module 7).
  • RSA-SHA256 for anything Salesforce signs.
  • The login page: a button, several buttons, or a Login Discovery page.
  • The back door: which admins keep a local login, and when it was last tested.

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.