Pure-admin SAML SSO setup, with Okta/Azure AD/Ping/Auth0/etc. as the IdP. Salesforce is the Service Provider (SP).
Steps:
- Pick the relationship. Salesforce-initiated (user goes to the My Domain login page first) vs IdP-initiated (user starts at the IdP). Most enterprises use IdP-initiated through their portal.
- Get the IdP metadata — typically an XML file from the IdP exposing certificates, single sign-on URL, entity ID, and signing details.
- In Salesforce: Setup -> Single Sign-On Settings. Create a new SAML SSO Settings record. Either upload the IdP's metadata XML or paste fields manually.
- Configure the Federation ID — pick which User field on Salesforce (typically the Federation ID field, less commonly Username) the IdP will use to identify the user. The IdP must include the same value in its assertions.
- In the IdP: configure Salesforce as a service provider. Set the ACS URL (
https://my.salesforce.com/saml-something), entity ID, and which user attribute maps to the Federation ID. - Test from a single test user. Use the SAML Validator in Salesforce to inspect assertions if it fails. Common errors: clock drift between IdP and SP (assertions valid for too short a window), wrong Federation ID, expired certificate.
- Decide login flow. Do you want to force SSO-only, or allow both Salesforce-direct and SSO logins? My Domain settings let you "Prevent login from https://login.salesforce.com" so users can only land via the SSO path.
- Roll out by profile. Don't flip everyone over at once. Start with a small group, make sure their MFA is satisfied at the IdP level, then expand.
Common problem you should call out: service / integration users. You almost always exempt them from SSO and let them log in with username/password (or use OAuth client-credentials) — otherwise scheduled jobs running as those users can't authenticate.