Single Sign-On Settings
Single Sign-On (SSO) Settings is a Setup page in Salesforce where administrators enable and configure federated authentication, allowing users to log in through an external Identity Provider (IdP) rather than entering Salesforce credentials directly.
Definition
Single Sign-On (SSO) Settings is a Setup page in Salesforce where administrators enable and configure federated authentication, allowing users to log in through an external Identity Provider (IdP) rather than entering Salesforce credentials directly. The page provides options to enable SAML-based SSO, specify the IdP's entity ID and login/logout URLs, upload the IdP's signing certificate, configure the SAML assertion attributes, and set the identity type and location. Salesforce supports SAML 2.0 for SSO and can act as both a Service Provider (SP) and an Identity Provider. SSO Settings works alongside Auth. Providers for OAuth-based social sign-on and OpenID Connect integrations.
In plain English
“Single Sign-On Settings is a Setup page where admins enable and configure federated authentication. It lets users log in through an external Identity Provider (like Okta, Azure AD, or Google) rather than using separate Salesforce credentials.”
Worked example
When IT at Larkford Software wants employees to log into Salesforce via the corporate Okta, the admin opens Single Sign-On Settings in Setup. She enables SAML, enters Okta's IdP entity ID and the SAML SSO URLs, uploads Okta's signing certificate, and configures the SAML assertion attribute mappings (Federation_Identifier on the Salesforce User maps to Okta's email field). After saving, employees see "Sign in with Okta" on the My Domain login page; one click redirects to Okta and back, authenticated. Single Sign-On Settings is the SAML configuration surface for federated authentication.
Why Single Sign-On Settings matters
Single Sign-On (SSO) Settings is a Setup page in Salesforce where administrators enable and configure federated authentication, allowing users to log in through an external Identity Provider (IdP) rather than using separate Salesforce credentials. SSO eliminates the need for separate Salesforce passwords by delegating authentication to a central identity system.
SSO is a security best practice for enterprise Salesforce deployments because it centralizes authentication management: one password policy, one MFA configuration, one deprovisioning point. When someone leaves the company, disabling their IdP account immediately revokes Salesforce access without needing to separately deactivate the Salesforce user. Mature orgs use SSO for all Salesforce authentication.
How to set up Single Sign-On Settings
Single Sign-On Settings configure SAML-based SSO where Salesforce is the Service Provider — users log in via your IdP (Okta, Azure AD, Ping, ADFS) and land in Salesforce already authenticated. Setup requires close coordination with your IdP admin since both sides must trust each other.
- Get IdP metadata XML from your identity provider
Okta / Azure AD / Ping / ADFS all have a Salesforce-template app that emits metadata. Download the XML — you'll upload it to Salesforce.
- Open Setup → Single Sign-On Settings
Setup gear → Quick Find: Single Sign-On Settings → Single Sign-On Settings.
- Click New from Metadata File and upload the IdP XML
Salesforce parses out the IdP Login URL, Logout URL, and Certificate. Saves a lot of typing.
- Set Name, API Name, and SAML Identity Type
Identity Type: Federation ID (matches User.FederationIdentifier) or Username (matches User.Username). Federation ID is more flexible.
- Pick Identity Provider Initiated Login URL or Service Provider Initiated
IdP-initiated: user starts at the IdP, gets redirected to Salesforce. SP-initiated: user starts at Salesforce, gets bounced to the IdP. Most orgs do both.
- Save
Salesforce creates an entry in My Domain → Authentication Configuration. Now flip a User's Login Type to "Federated" to test.
- Test with one User first
Set one User's Login Type → Federated, populate Federation ID, attempt login via the IdP. Resolve issues before flipping the whole org.
1.1 or 2.0. Use 2.0 for any new IdP.
Federation ID (User.FederationIdentifier) or Username (User.Username). Federation ID is decoupled from Salesforce username — better for portability.
Where Salesforce redirects users to authenticate.
Where users land after logging out (single logout).
When ticked, new users on first SSO login are auto-created from SAML attributes. Skip user-creation work.
When user logs out of Salesforce, also log out of the IdP.
- SAML config requires both sides — your IdP must have a Salesforce app configured with the Salesforce ACS URL (Assertion Consumer Service). One-sided config silently fails.
- Federation ID vs Username: if you migrate users between Salesforce orgs, Federation ID stays portable; Username is org-specific. Default to Federation ID for new orgs.
- Certificate expiration breaks all federated logins instantly. Set a calendar reminder 60 days before the IdP cert expires — coordinate rotation with your IdP admin.
How organizations use Single Sign-On Settings
Configured SAML SSO with their corporate Okta IdP for centralized authentication.
Uses SSO for all Salesforce access, eliminating separate Salesforce passwords.
Treats SSO as foundational security infrastructure for centralized access control.
Trust & references
Straight from the source - Salesforce's reference material on Single Sign-On Settings.
- SAML SSO with Salesforce as the Service ProviderSalesforce Help
🧠 Test your knowledge
Q1. What are SSO Settings?
Q2. Why use SSO?
Q3. What Identity Providers work?
Discussion
Loading discussion…