Single Sign-On with SAML and Identity Providers

Why Single Sign-On Matters
Single Sign-On (SSO) is one of the most heavily tested topics in the Advanced Security and Access section of the Salesforce Advanced Administrator exam. In real organizations, users juggle dozens of applications, and every separate password is a security risk, a help-desk ticket waiting to happen, and a productivity drain. SSO solves this by letting a user authenticate once with a trusted corporate identity system and then access Salesforce (and other apps) without re-entering credentials. For administrators, SSO centralizes control: when an employee leaves, deactivating them in the corporate directory immediately blocks their access everywhere. For the exam, you must understand why a company would choose SSO, which SSO approach fits a given scenario, and how the SAML flow actually works so you can troubleshoot and configure it correctly.

What Is Single Sign-On?
SSO is an authentication method that allows a user to log in once and gain access to multiple independent systems. Salesforce supports several SSO mechanisms, and the exam expects you to distinguish between them:

1. Federated Authentication using SAML - the primary and recommended method. Salesforce trusts a digitally signed assertion from an external Identity Provider. No password is ever sent to Salesforce.
2. Delegated Authentication - Salesforce passes the username and password entered on the login page to a customer-hosted web service, which validates them. This must be enabled by contacting Salesforce Support and requires the Is Single Sign-On Enabled permission on a profile or permission set.
3. Authentication Providers (Social Sign-On / OpenID Connect) - lets users log in with Google, Facebook, LinkedIn, Microsoft, or any OpenID Connect provider. Often used for Experience Cloud communities.

When the exam says SAML, Identity Provider, federation, or assertion, it is pointing you toward Federated Authentication.

Key Terminology You Must Know
Identity Provider (IdP): The system that authenticates the user and vouches for their identity. Examples include Microsoft Entra ID (Azure AD), Okta, Ping Identity, Active Directory Federation Services (ADFS), and Salesforce itself when configured as an IdP.
Service Provider (SP): The application the user wants to access. In most exam scenarios, Salesforce is the Service Provider.
SAML (Security Assertion Markup Language): An XML-based open standard for exchanging authentication and authorization data between an IdP and an SP. Salesforce supports SAML 2.0.
SAML Assertion: The XML document the IdP sends to Salesforce containing statements about the user (who they are, when they authenticated) and a digital signature proving it came from the trusted IdP.
Federation ID: A field on the Salesforce user record that uniquely identifies the user to the external identity system. It is commonly set to the corporate employee ID, email, or network username. It must be unique per user in the org (case-sensitive).
Entity ID / Issuer: A unique identifier (usually a URL) for the IdP and for the SP. Salesforce validates that the Issuer in the assertion matches the one configured.
Certificate: The IdP signs assertions with a private key; Salesforce verifies them with the IdP public certificate you upload in the SSO settings.
Just-in-Time (JIT) Provisioning: A feature that creates or updates the Salesforce user record automatically the first time a user logs in via SAML, using attributes in the assertion.
My Domain: A required prerequisite. SAML SSO with SP-initiated login and authentication service selection on the login page only works with My Domain deployed.

How SAML SSO Works: The Two Flows
IdP-Initiated Flow:
1. The user logs into the corporate portal (the IdP).
2. The user clicks a Salesforce tile or link.
3. The IdP generates a signed SAML assertion and POSTs it to the Salesforce Assertion Consumer Service (ACS) URL (the Login URL shown in the SSO settings).
4. Salesforce validates the signature, issuer, timestamps, audience, and recipient.
5. Salesforce locates the user by matching the identifier in the assertion (Federation ID, username, or user ID) and logs them in.

SP-Initiated Flow:
1. The user goes directly to the company My Domain URL (for example, acme.my.salesforce.com).
2. Salesforce redirects the user to the Identity Provider Login URL configured in SSO settings.
3. The user authenticates with the IdP (or is already authenticated).
4. The IdP returns a signed SAML response to Salesforce.
5. Salesforce validates the response and logs the user in.

SP-initiated flow requires My Domain, because Salesforce must know which org and which IdP the user belongs to before authentication.

Configuring SAML SSO in Salesforce (Salesforce as Service Provider)
Navigate to Setup > Single Sign-On Settings, check SAML Enabled, and create a new SAML Single Sign-On Setting. The critical fields are:

Name and API Name - a label for this configuration (you can have multiple IdPs).
Issuer - the Entity ID of the IdP.
Entity ID - the Salesforce identifier, typically your My Domain URL (recommended) or https://saml.salesforce.com.
Identity Provider Certificate - the public certificate used to verify signatures.
Request Signing Certificate - the Salesforce certificate used to sign outbound SAML requests in SP-initiated flow.
SAML Identity Type - how the assertion identifies the user. Options: Assertion contains the User's Salesforce username, Assertion contains the Federation ID from the User object, or Assertion contains the User ID from the User object. Federation ID is the most common and most flexible choice because usernames can change.
SAML Identity Location - whether the identifier is in the NameIdentifier element of the Subject statement or in an Attribute element.
Identity Provider Login URL - where Salesforce redirects users for SP-initiated login.
Identity Provider Logout URL / Custom Logout URL - where users go after logging out.
Service Provider Initiated Request Binding - HTTP POST or HTTP Redirect.
Single Logout (SLO) - optional; logs the user out of the IdP when they log out of Salesforce and vice versa.
User Provisioning Enabled (JIT) - standard JIT uses assertion attributes with names like User.Username, User.Email, User.ProfileId; custom JIT uses an Apex class implementing the Auth.SamlJitHandler interface.

After saving, Salesforce displays the Login URL (ACS URL) and lets you Download Metadata, an XML file you give to the IdP team so they can configure their side.

My Domain Login Page Settings
Under Setup > My Domain > Authentication Configuration, you choose which Authentication Services appear on the login page. You can show the standard Login Form, one or more SAML configurations, and any Authentication Providers. If you select only the SAML service and deselect Login Form, users are redirected straight to the IdP. The Login Policy option Prevent login from https://login.salesforce.com forces users through My Domain so SSO is enforced. Administrators should keep a path to log in with a Salesforce password (such as keeping Login Form visible or using the direct ?login parameter) to avoid lockout if the IdP fails.

Salesforce as an Identity Provider
Salesforce can also act as the IdP, letting users log into other SAML-enabled applications using their Salesforce credentials. To do this, enable Identity Provider in Setup (requires My Domain), then create a Connected App for each external SP with its Entity ID, ACS URL, and Subject Type. Users access the apps from the App Launcher. This is the solution when a question describes employees wanting to use Salesforce login to access a third-party app.

Troubleshooting Tools
SAML Assertion Validator (in Single Sign-On Settings) - paste a SAML response or review the last failed login to see exactly which validation step failed (signature, issuer, audience, timestamp, user lookup).
Login History - shows the Login Type (for example, SAML Sfdc Initiated SSO or SAML Idp Initiated SSO) and status, including specific SAML failure reasons.
Common failure causes - Federation ID mismatch or blank Federation ID, expired or wrong IdP certificate, clock skew between IdP and Salesforce (assertions are time-bound), wrong Entity ID or Audience, inactive user, or the user lacking a license.

Comparing the Options in Exam Scenarios
Choose SAML Federated Authentication when: the company has an existing IdP (Okta, Entra ID, ADFS); passwords must never be sent to Salesforce; the goal is seamless login from a corporate portal; or users need automatic provisioning via JIT.
Choose Delegated Authentication when: the company wants users to type credentials on the Salesforce login page but have them validated by an internal system (such as LDAP) via a web service; the scenario mentions a SOAP web service or Salesforce Support enabling a feature.
Choose Authentication Providers when: external users (customers, partners) want to log into an Experience Cloud site with Google, Facebook, LinkedIn, or another OpenID Connect provider.
Choose Salesforce as IdP with Connected Apps when: users should log into other applications using their Salesforce credentials.
Choose Login Flows when: additional steps (MFA challenge, terms acceptance, identity verification) must happen after authentication, including after SSO.

Important Behaviors to Remember
- SSO users can still have Salesforce passwords unless the admin removes the login form; password policies in Salesforce do not apply to the IdP-managed password.
- Users with SSO can still log in through the API with username and password unless API access is restricted; delegated authentication can be set to apply to the API as well.
- Multiple SAML configurations are supported in one org, allowing different IdPs for different user groups (for example, employees and partners).
- Profile-level and IP-based login restrictions still apply after SSO authentication.
- Multi-Factor Authentication can be satisfied at the IdP level; Salesforce can be configured to trust the IdP MFA via the Session Security Level in the SSO setting (High Assurance).
- JIT provisioning requires the assertion to include at minimum username, email, last name, and profile ID.
- Salesforce supports SAML 2.0 only; SAML 1.1 is not supported for new configurations.

Exam Tips: Answering Questions on Single Sign-On with SAML and Identity Providers

Tip 1 - Identify the roles first. Read the scenario and determine who authenticates the user (IdP) and who the user wants to access (SP). If employees log into a corporate portal first and then click into Salesforce, Salesforce is the SP and the flow is IdP-initiated. If users bookmark the My Domain URL and get redirected, it is SP-initiated.

Tip 2 - Spot the My Domain requirement. Any question mentioning SP-initiated SSO, choosing authentication services on the login page, Salesforce acting as an IdP, or Connected Apps for SSO implies My Domain must be deployed. If an answer choice omits My Domain when the scenario needs SP-initiated login, it is wrong.

Tip 3 - Federation ID is the default matching key. When a question asks how Salesforce knows which user is logging in, or why a user receives an error after SSO, think Federation ID. It must be populated, unique, and exactly match the value the IdP sends. A blank or mismatched Federation ID is the most common troubleshooting answer.

Tip 4 - Distinguish SAML from Delegated Authentication. Keywords such as assertion, certificate, Okta, ADFS, Entra ID, metadata, and Identity Provider point to SAML. Keywords such as web service, LDAP validation, Salesforce Support must enable, and Is Single Sign-On Enabled permission point to Delegated Authentication.

Tip 5 - Know the troubleshooting tools. If asked how to diagnose a failed SSO login, the best answers are the SAML Assertion Validator and Login History. Setup Audit Trail and Debug Logs are distractors for this scenario.

Tip 6 - Recognize JIT provisioning scenarios. If the question describes new hires who should get Salesforce accounts automatically the first time they log in through SSO, the answer is Just-in-Time provisioning. If custom logic is needed (assigning permission sets, mapping departments to roles), the answer involves a custom Apex SamlJitHandler.

Tip 7 - Salesforce as IdP equals Connected App. When the goal is to let users access an external system with their Salesforce login, the solution is enabling Salesforce as an Identity Provider and creating a Connected App with SAML settings for the external app.

Tip 8 - Social sign-on is an Authentication Provider. Questions about customers logging into a community or Experience Cloud site with Google or Facebook are about Authentication Providers (OpenID Connect), not SAML.

Tip 9 - Watch for lockout prevention. If an answer removes the standard login form completely without any administrator fallback, be cautious. Best practice keeps a way for administrators to log in with Salesforce credentials in case the IdP is unavailable.

Tip 10 - Eliminate answers that misplace certificates. The IdP certificate uploaded into Salesforce is the IdP public certificate used to verify signatures. Salesforce own certificates (from Certificate and Key Management) are used for signing outbound requests or when Salesforce acts as IdP. Answers that reverse these roles are wrong.

Tip 11 - Remember security layers still apply. SSO does not bypass profile login hours, IP restrictions, or session settings. If a user authenticates successfully at the IdP but is blocked, check these Salesforce-side controls.

Tip 12 - Choose the least complex solution that meets requirements. The exam favors declarative configuration. If standard JIT, standard SAML settings, or Login Flows solve the problem, do not choose Apex or custom code answers.

Summary
Single Sign-On with SAML lets Salesforce trust a corporate Identity Provider so users authenticate once and access Salesforce securely without separate passwords. Master the vocabulary (IdP, SP, assertion, Federation ID, Entity ID, certificate), the two flows (IdP-initiated and SP-initiated), the configuration fields in Single Sign-On Settings, the My Domain prerequisite, the alternatives (Delegated Authentication, Authentication Providers, Salesforce as IdP), and the troubleshooting tools (SAML Assertion Validator and Login History). With these concepts and the exam tips above, you will be able to read any SSO scenario, identify the correct approach, and confidently select the right answer.