Identity Provider
Identity Provider is a Setup page where administrators configure Salesforce to act as an identity provider (IdP) for single sign-on to other applications.
Definition
Identity Provider is a Setup page where administrators configure Salesforce to act as an identity provider (IdP) for single sign-on to other applications. When enabled, users can authenticate once in Salesforce and then access connected third-party applications without entering separate credentials.
In plain English
“Here's a simple way to think about it: Identity Provider lets Salesforce act as the SSO anchor for other applications. Users authenticated to Salesforce launch other apps without re-authenticating - useful when Salesforce is the central system and a few complementary apps need SSO.”
Worked example
The admin at Apex Dynamics configures Salesforce as an Identity Provider so that employees who log into Salesforce can seamlessly access the company's document management system, project tracking tool, and HR portal without additional logins. She sets up SAML-based SSO connections for each application and maps user attributes between the systems.
Why making Salesforce an Identity Provider lets your org sign users into other apps
Most orgs configure Salesforce as a Service Provider - users authenticate elsewhere (Okta, Azure AD, Google) and that identity flows into Salesforce. Identity Provider flips the direction. With this enabled, a user authenticated to Salesforce can launch other applications without a second login. The use cases are typically internal tools, partner portals, or legacy applications that need an identity store but don't have a primary IdP.
The reason this is worth knowing about even if you'd default to a dedicated IdP is that not every organization has one. A small or mid-sized company with Salesforce as its central system of record can use it as the SSO anchor for a handful of complementary apps, getting most of the SSO experience without buying additional identity tooling. The right time to consider it is when you have 1-3 apps that need SSO; if you have 10+, plan for a real IdP.
How to set up Identity Provider
Identity Provider Setup is the inverse of Single Sign-On Settings — here Salesforce IS the IdP, authenticating users for downstream apps (Slack, Box, custom internal tools). It's much rarer than Salesforce-as-SP but useful for orgs that want one Salesforce login to span dozens of apps.
- Open Setup → Identity Provider
Setup gear → Quick Find: Identity Provider → Identity Provider.
- Click Enable Identity Provider
First-time enablement requires picking a self-signed certificate or uploading one. Self-signed is fine for most internal apps; CA-signed for high-assurance.
- Save
Salesforce is now an IdP. The page now shows the metadata your downstream apps need.
- For each downstream app: create a Connected App
Setup → App Manager → New Connected App. Tick Enable SAML. Set Entity ID, ACS URL, NameID Format. The downstream app's docs will tell you each value.
- Configure SP-Initiated and IdP-Initiated flows
On the Connected App's SAML section, set Subject Type, Service Provider URL, Single Logout.
- Download Salesforce IdP metadata
From Setup → Identity Provider → Download Metadata → give the XML to your downstream app's admin.
- Test the login flow
From the downstream app, attempt SSO. Salesforce should authenticate and bounce the user back.
Self-Signed (free) or upload a CA-signed cert. Self-signed is fine for internal apps.
Each downstream app gets its own Connected App with SAML enabled.
Entity ID, ACS URL, NameID Format, Subject Type.
Setup → Identity Provider Event Log shows every IdP login attempt. Useful for debugging.
- Salesforce-as-IdP is rare. Most orgs run Okta / Azure AD / Ping as their primary IdP and have Salesforce as a downstream SP. Only enable Salesforce IdP if you have a clear use case.
- The IdP certificate expires. When it does, every downstream app's SSO breaks at once. Set a rotation reminder 60 days before expiration.
- Each downstream Connected App is its own configuration. There's no "one app to rule them all" — five SaaS apps means five SAML-enabled Connected Apps.
How organizations use Identity Provider
Configured Salesforce as IdP for 4 partner apps; reduced support tickets about partner-app login by 90%.
Internal tools use Salesforce identity; new hires get one-click access to the right apps from their Salesforce session.
Legacy apps requiring identity but lacking primary IdP integrations use Salesforce-as-IdP as a bridge.
Trust & references
Straight from the source - Salesforce's reference material on Identity Provider.
- Enable Salesforce as a SAML Identity ProviderSalesforce Help
- Salesforce as an Identity ProviderSalesforce Help
Test your knowledge
Q1. Can a Salesforce admin configure Identity Provider without writing code?
Q2. Why is understanding Identity Provider important for Salesforce admins?
Q3. What is the primary benefit of Identity Provider for Salesforce administrators?
Discussion
Loading discussion…