User Authentication and Single Sign-On in Salesforce

Part 28: User Authentication and Single Sign-On in Salesforce

Up to this point in the series, every user we have created logs in with a username and password directly in Salesforce. That works fine for a small org, but the moment your company has fifty, five hundred, or five thousand employees all using Salesforce alongside Slack, Google Workspace, Jira, and a handful of other SaaS tools, managing separate credentials for each application becomes a nightmare. Users forget passwords, IT spends half its life resetting them, and security suffers because people reuse the same weak password everywhere.

Single Sign-On (SSO) solves this problem. Instead of each application maintaining its own credentials, a central identity provider handles authentication and tells Salesforce “this user is who they say they are.” Combine SSO with Multi-Factor Authentication (MFA) and you have a security model that is both easier for users and harder for attackers.

In this post, we will cover the authentication landscape end to end: the protocols that make SSO possible, MFA requirements, how to integrate Okta with Salesforce step by step, how to bring SSO to Experience Cloud sites, and a full project walkthrough for setting up Ping Federate as your identity provider.

What Is Single Sign-On (SSO)

Single Sign-On is an authentication scheme that allows a user to log in once with a single set of credentials and then access multiple applications without being prompted to log in again. When you sign in to your company’s identity portal in the morning and then open Salesforce, Gmail, and Confluence without entering another password, that is SSO at work.

How SSO Works at a High Level

┌──────────┐          ┌───────────────────┐         ┌─────────────┐
│          │  1. User │                   │         │             │
│  User    │ ──────>  │  Service Provider │ ──2───> │  Identity   │
│ (Browser)│          │  (Salesforce)     │         │  Provider   │
│          │ <──5───  │                   │ <──4─── │  (Okta,     │
│          │  Access  │                   │  Token  │   Azure AD, │
│          │  Granted │                   │         │   Ping)     │
│          │          │                   │         │             │
└──────────┘          └───────────────────┘         └─────────────┘
                                                        │
                                                   3. User logs
                                                      in here

1. The user attempts to access Salesforce (the Service Provider or SP).
2. Salesforce redirects the user to the Identity Provider (IdP) — the central authentication server.
3. The user authenticates at the IdP (or is already authenticated from a previous session).
4. The IdP sends a signed token back to Salesforce confirming the user’s identity.
5. Salesforce grants access.

The user only ever enters credentials at the IdP. Salesforce never sees the password.

Key Terminology

The Three Protocols: SAML, OAuth 2.0, and OpenID Connect

SSO is not a single protocol — it is a concept that can be implemented using several different protocols. The three you will encounter most often in the Salesforce ecosystem are SAML, OAuth 2.0, and OpenID Connect (OIDC).

SAML (Security Assertion Markup Language)

SAML is the oldest and most widely used protocol for enterprise SSO. It is an XML-based standard designed specifically for exchanging authentication and authorization data between an IdP and an SP.

How SAML Works:

┌─────────┐      ┌───────────────┐      ┌──────────┐
│ Browser │──1──>│  Salesforce   │      │   IdP    │
│         │      │  (SP)         │──2──>│ (Okta)   │
│         │<─────│               │      │          │
│         │  redirect to IdP     │      │          │
│         │──3─────────────────────────>│          │
│         │      │               │      │          │
│         │<─4── SAML Assertion ────────│          │
│         │──5──>│               │      │          │
│         │      │ Validates     │      │          │
│         │<─6── │ assertion     │      │          │
│         │      │ Grants access │      │          │
└─────────┘      └───────────────┘      └──────────┘

1. User navigates to Salesforce.
2. Salesforce generates a SAML AuthnRequest and redirects the browser to the IdP.
3. Browser follows the redirect to the IdP login page.
4. User authenticates. IdP generates a signed SAML Assertion (an XML document containing the user’s identity, attributes, and a digital signature).
5. Browser POSTs the assertion back to Salesforce’s Assertion Consumer Service (ACS) URL.
6. Salesforce validates the signature, maps the assertion’s subject to a Salesforce user, and creates a session.

SAML Key Concepts:

When to use SAML: SAML is the standard choice for enterprise SSO into Salesforce. If your company uses Okta, Azure AD, ADFS, or Ping Identity for employee authentication, SAML is almost certainly what you will configure.

Section Note: SAML 2.0 is the current version. SAML 1.1 is deprecated and should not be used for new integrations. When someone says “SAML” in the Salesforce context, they mean SAML 2.0.

OAuth 2.0

OAuth 2.0 is an authorization framework, not an authentication protocol. It was designed to allow third-party applications to access a user’s resources without exposing the user’s password. However, it is frequently used alongside authentication protocols and is deeply embedded in the Salesforce platform.

OAuth 2.0 is about authorization, not authentication. When an external application needs to call Salesforce APIs on behalf of a user, OAuth 2.0 is the mechanism that grants that access.

Key OAuth 2.0 Concepts:

Common OAuth 2.0 Flows in Salesforce:

When to use OAuth 2.0: Use OAuth when an external application needs API access to Salesforce data. OAuth does not replace SAML for user login — it complements it.

Section Note: Salesforce requires a Connected App for every OAuth integration. The Connected App defines the OAuth settings (callback URL, scopes, certificate) and can enforce IP restrictions, session policies, and MFA.

OpenID Connect (OIDC)

OpenID Connect is an authentication layer built on top of OAuth 2.0. While OAuth 2.0 answers “what is this application allowed to access?”, OIDC answers “who is this user?”

OIDC adds an ID Token (a JSON Web Token / JWT) to the OAuth flow. The ID token contains claims about the authenticated user — their name, email, unique identifier, and when they authenticated.

How OIDC Relates to SAML and OAuth:

┌─────────────────────────────────────────────────┐
│                   SSO Protocols                 │
│                                                 │
│  ┌────────────────┐  ┌───────────────────────┐  │
│  │    SAML 2.0    │  │     OAuth 2.0         │  │
│  │                │  │                       │  │
│  │ Authentication │  │   Authorization       │  │
│  │ + Authorization│  │                       │  │
│  │                │  │  ┌─────────────────┐  │  │
│  │  XML-based     │  │  │  OpenID Connect │  │  │
│  │  Enterprise    │  │  │                 │  │  │
│  │  focused       │  │  │ Authentication  │  │  │
│  │                │  │  │ layer on OAuth  │  │  │
│  │                │  │  │ JSON/JWT-based  │  │  │
│  └────────────────┘  │  └─────────────────┘  │  │
│                      └───────────────────────┘  │
└─────────────────────────────────────────────────┘

OIDC Key Concepts:

When to use OIDC: OIDC is increasingly popular for modern web and mobile applications. Salesforce supports OIDC both as a provider (Salesforce can act as an OIDC identity provider) and as a relying party (Salesforce can authenticate users via an external OIDC provider). It is the recommended protocol for Experience Cloud social login and for modern identity providers that prefer JSON over XML.

Section Note: In practice, many Salesforce SSO setups still use SAML because the enterprise identity providers (Okta, Azure AD, Ping) have mature SAML integrations. OIDC is becoming more common for Experience Cloud sites and mobile apps.

Protocol Comparison

What Is Two-Factor Authentication (MFA)

Multi-Factor Authentication (MFA), sometimes called Two-Factor Authentication (2FA), requires users to verify their identity using two or more independent factors before gaining access. The factors fall into three categories:

Standard login uses only the first factor (password). MFA adds a second factor — typically a time-based one-time password (TOTP) from an authenticator app or a push notification.

Salesforce’s MFA Requirement

As of February 1, 2022, Salesforce requires MFA for all users who log in directly to Salesforce products. This is not optional — it is a contractual obligation under the Salesforce Trust and Compliance documentation.

Important clarification: If your users authenticate through SSO, MFA at the IdP satisfies the Salesforce MFA requirement. You do not need to enable MFA within Salesforce itself if your IdP already enforces it.

MFA Methods Supported by Salesforce

How to Enable MFA in Salesforce

Step 1: Verify your users have an authenticator method registered.

Go to Setup > Identity > Multi-Factor Authentication and review the MFA settings.

Step 2: Assign the “Multi-Factor Authentication for User Interface Logins” permission.

You can do this via a permission set:

1. Go to Setup > Permission Sets.
2. Create a new permission set (or use an existing one).
3. Under System Permissions, enable Multi-Factor Authentication for User Interface Logins.
4. Assign the permission set to the appropriate users.

Alternatively, enable it on the profile directly.

Step 3: Communicate with your users.

Before enforcing MFA, give users time to register their authenticator. Send clear instructions with screenshots. Run a pilot with a small group first.

Step 4: Monitor adoption.

Use the Identity Verification History report and the Multi-Factor Authentication setup page to track which users have registered and which have not.

Section Note: The MFA requirement applies to direct Salesforce UI logins. API-only users (integrations) are exempt. If you use SSO, your IdP is responsible for enforcing MFA — but you must ensure MFA is actually turned on at the IdP. Salesforce auditors will check.

What Is Okta

Okta is a cloud-based identity and access management (IAM) platform. It is one of the most popular identity providers in the enterprise world and is used by thousands of organizations to manage SSO, MFA, lifecycle management, and API access across their application ecosystem.

Why Okta Is So Common with Salesforce

• Cloud-native: Okta is a SaaS product, just like Salesforce. There are no on-premises servers to manage.
• Pre-built integration: Okta has a first-party Salesforce integration in its catalog. Setup takes minutes, not days.
• Universal Directory: Okta can sync users from Active Directory, LDAP, HR systems, and other sources into a single directory, then provision those users into Salesforce automatically.
• Lifecycle management: When an employee is deactivated in Okta (e.g., on their last day), their Salesforce access is automatically revoked.
• Adaptive MFA: Okta supports a wide range of MFA methods and can adapt requirements based on risk signals (location, device, behavior).

Okta Architecture Overview

┌─────────────────────────────────────────────────────────┐
│                        Okta                             │
│                                                         │
│  ┌──────────────────┐    ┌───────────────────────────┐  │
│  │ Universal        │    │ Application Integrations  │  │
│  │ Directory        │    │                           │  │
│  │                  │    │ ┌────────┐ ┌──────────┐   │  │
│  │  ┌────────────┐  │    │ │Salesforce│ │Google  │   │  │
│  │  │ AD / LDAP  │  │    │ │(SAML)  │ │Workspace │   │  │
│  │  │ Sync       │  │    │ └────────┘ └──────────┘   │  │
│  │  └────────────┘  │    │ ┌────────┐ ┌──────────┐   │  │
│  │  ┌────────────┐  │    │ │Slack   │ │Jira      │   │  │
│  │  │ HR System  │  │    │ │(SAML)  │ │(SAML)    │   │  │
│  │  │ Import     │  │    │ └────────┘ └──────────┘   │  │
│  │  └────────────┘  │    │                           │  │
│  └──────────────────┘    └───────────────────────────┘  │
│                                                         │
│  ┌─────────────────┐     ┌──────────────────────────┐   │
│  │ Authentication  │     │ Lifecycle Management     │   │
│  │ Policies        │     │                          │   │
│  │                 │     │ Auto-provision users     │   │
│  │ MFA, Adaptive   │     │ Auto-deactivate users    │   │
│  │ Policies, Risk  │     │ Attribute sync           │   │
│  └─────────────────┘     └──────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

Okta Terminology

How to Set Up Okta with Salesforce (Step-by-Step)

This section walks through a complete SAML-based SSO integration between Okta (as the IdP) and Salesforce (as the SP). We will also configure user provisioning so that user accounts are automatically synced.

Prerequisites

Before you begin, make sure you have:

• An Okta developer or production account with admin access
• A Salesforce org with System Administrator access
• The My Domain feature enabled in Salesforce (it is enabled by default in all orgs since Winter ‘21, but verify at Setup > My Domain)
• A list of users who should be included in the SSO rollout

Phase 1: Configure the Salesforce Application in Okta

Step 1: Add Salesforce from the Okta Application Catalog.

1. Log in to your Okta admin console.
2. Navigate to Applications > Applications.
3. Click Browse App Catalog.
4. Search for “Salesforce” and select Salesforce.com.
5. Click Add Integration.

Step 2: Configure General Settings.

1. Set the Application label (e.g., “Salesforce Production”).
2. For Custom Domain, enter your Salesforce My Domain URL (e.g., yourcompany.my.salesforce.com).
3. Leave the other settings at their defaults unless you have specific requirements.
4. Click Next.

Step 3: Configure Sign-On Options.

1. Select SAML 2.0 as the sign-on method.
2. Okta will display the SAML configuration details. You will need these later:
   • Identity Provider Issuer — Okta’s entity ID
   • Identity Provider Single Sign-On URL — The URL where Salesforce will redirect users
   • X.509 Certificate — Download this certificate. You will upload it to Salesforce.
3. For Application username format, select Okta username or Email depending on how your Salesforce usernames are structured.
4. Click Done.

Step 4: Download the Okta SAML Metadata.

1. In the Salesforce application in Okta, go to the Sign On tab.
2. Click Identity Provider metadata to download the XML metadata file. This file contains the IdP entity ID, SSO URL, and certificate — everything Salesforce needs.

Phase 2: Configure SSO in Salesforce

Step 5: Upload the IdP Certificate.

1. In Salesforce, go to Setup > Security > Certificate and Key Management.
2. Actually, Salesforce will handle this during SSO configuration. Skip ahead to Step 6 — the certificate is uploaded as part of the SSO settings.

Step 6: Create a Single Sign-On Configuration.

1. Go to Setup > Identity > Single Sign-On Settings.
2. Click Edit and check SAML Enabled. Save.
3. Click New under SAML Single Sign-On Settings.
4. Fill in the following fields:

5. Click Save.

Section Note: The SAML Identity Type setting is critical. If you choose “Federation ID,” you must ensure every Salesforce user has their Federation ID field populated with the value Okta sends in the assertion. If you choose “Salesforce Username,” the assertion must contain the exact Salesforce username. Mismatches here are the number one cause of SSO failures.

Step 7: Configure My Domain to Use SSO.

1. Go to Setup > My Domain.
2. Under Authentication Configuration, click Edit.
3. Check the box next to your new SSO configuration (“Okta SSO”).
4. Optionally, uncheck Login Form if you want to force all users through SSO (be careful — keep at least one System Admin able to log in directly for emergency access).
5. Click Save.

Phase 3: Configure User Provisioning (SCIM)

User provisioning automates the creation and deactivation of Salesforce user accounts from Okta.

Step 8: Enable the Salesforce API in Okta.

1. In Okta, go to the Salesforce application and click the Provisioning tab.
2. Click Configure API Integration.
3. Check Enable API Integration.
4. Click Authenticate with Salesforce. This will open a Salesforce login window — log in with your System Administrator credentials to authorize Okta.
5. Click Save.

Step 9: Configure Provisioning Settings.

1. Under Provisioning > To App, click Edit.
2. Enable the following:
   • Create Users — Okta will create Salesforce users automatically.
   • Update User Attributes — Changes in Okta (name, email, etc.) will sync to Salesforce.
   • Deactivate Users — When a user is deactivated in Okta, their Salesforce account is deactivated.
3. Click Save.

Step 10: Map Attributes.

1. Still on the Provisioning tab, scroll to Attribute Mappings.
2. Map Okta attributes to Salesforce fields:

3. Click Save.

Phase 4: Test the Integration

Step 11: Assign a Test User in Okta.

1. In Okta, go to the Salesforce application and click the Assignments tab.
2. Assign a test user (or a test group) to the application.
3. If provisioning is enabled, Okta will create the user in Salesforce automatically. If not, make sure the user already exists in Salesforce with the correct Federation ID.

Step 12: Test SP-Initiated SSO.

1. Open an incognito browser window.
2. Navigate to your Salesforce My Domain login page.
3. You should see an SSO button (e.g., “Log in with Okta SSO”).
4. Click it. You should be redirected to Okta.
5. Log in at Okta (or if already logged in, you should be redirected back automatically).
6. Verify that you land in Salesforce with the correct user context.

Step 13: Test IdP-Initiated SSO.

1. Log in to Okta.
2. Click the Salesforce tile on your Okta dashboard.
3. Verify that you are redirected directly into Salesforce without a login prompt.

Step 14: Troubleshoot if Needed.

Common SSO issues and their solutions:

Section Note: Always maintain at least one System Administrator account that can log in directly via username and password (not SSO). If your IdP goes down, this is your emergency access. Add this user’s IP to the Login IP Ranges on their profile to lock it down, and do NOT uncheck “Login Form” on My Domain for this admin.

How to Add SSO Authentication to Experience Cloud Sites

Experience Cloud sites need authentication too. Your customers, partners, or community members should be able to log in via SSO — whether through a corporate IdP, a social login provider (Google, Facebook, Apple), or a custom OIDC provider.

Authentication Options for Experience Cloud

Step-by-Step: Adding SAML SSO to an Experience Cloud Site

Step 1: Create the SSO Configuration.

Follow the same steps we covered in the Okta section (Steps 5-6) to create a SAML Single Sign-On configuration. The key difference for Experience Cloud: the Entity ID and ACS URL will be different from your internal org.

The Entity ID for an Experience Cloud site follows this pattern:

https://yourcompany.my.site.com/communityname

The ACS URL is:

https://yourcompany.my.site.com/communityname/login

Make sure your IdP is configured to send assertions to the Experience Cloud ACS URL, not the internal Salesforce ACS URL.

Step 2: Configure the Auth Provider (for OIDC/Social Login).

If you are using OpenID Connect or social login instead of SAML:

1. Go to Setup > Identity > Auth. Providers.
2. Click New.
3. Select the provider type (e.g., OpenID Connect, Google, Facebook, Apple).
4. Fill in the configuration:

5. Click Save.

Step 3: Create a Registration Handler.

The Registration Handler is an Apex class that implements the Auth.RegistrationHandler interface. It tells Salesforce what to do when a user authenticates through the external provider:

• If the user already exists, match them and log them in.
• If the user is new, create a new Contact and User record.

Here is a simplified example:

public class ExperienceCloudRegistrationHandler implements Auth.RegistrationHandler {

    public User createUser(Id portalId, Auth.UserData data) {
        // Check if a user already exists with this email
        List<User> existingUsers = [
            SELECT Id FROM User
            WHERE Email = :data.email
            AND IsActive = true
            LIMIT 1
        ];

        if (!existingUsers.isEmpty()) {
            return existingUsers[0];
        }

        // Create a new Contact and Community User
        Account communityAccount = [
            SELECT Id FROM Account
            WHERE Name = 'Community Members'
            LIMIT 1
        ];

        Contact newContact = new Contact(
            AccountId = communityAccount.Id,
            FirstName = data.firstName,
            LastName = data.lastName,
            Email = data.email
        );
        insert newContact;

        Profile communityProfile = [
            SELECT Id FROM Profile
            WHERE Name = 'Customer Community User'
            LIMIT 1
        ];

        User newUser = new User(
            ContactId = newContact.Id,
            ProfileId = communityProfile.Id,
            FirstName = data.firstName,
            LastName = data.lastName,
            Email = data.email,
            Username = data.email + '.community',
            Alias = data.firstName.substring(0, 1) + data.lastName.substring(0, 4),
            EmailEncodingKey = 'UTF-8',
            LanguageLocaleKey = 'en_US',
            LocaleSidKey = 'en_US',
            TimeZoneSidKey = 'America/New_York'
        );
        insert newUser;

        return newUser;
    }

    public void updateUser(Id userId, Id portalId, Auth.UserData data) {
        User u = new User(Id = userId);
        u.FirstName = data.firstName;
        u.LastName = data.lastName;
        u.Email = data.email;
        update u;
    }
}

Step 4: Enable the Auth Provider on the Experience Cloud Site.

1. Go to Setup > Digital Experiences > All Sites.
2. Click Builder next to your site.
3. In Experience Builder, go to Settings (gear icon) > Authentication.
4. Under Login Page Configuration, you will see the available authentication options.
5. Enable the SSO configurations and Auth Providers you want to appear on the login page.
6. Arrange the order — the first option is the default.

Alternatively, configure this from Experience Workspace:

1. Go to Setup > Digital Experiences > All Sites.
2. Click Workspaces next to your site.
3. Navigate to Administration > Login & Registration.
4. Under Login Page Setup, enable the auth providers and SSO configurations you want.

Step 5: Customize the Login Page.

In Experience Builder, navigate to the Login page. You can customize:

• The layout and branding of the login form
• Which SSO buttons appear and their order
• Whether self-registration is enabled
• Custom login flow components (if you need additional logic during login)

Step 6: Configure Self-Registration (Optional).

If you want external users to create their own accounts:

1. In Experience Workspace > Administration > Login & Registration, enable self-registration.
2. Assign a default Profile and Account for self-registered users.
3. Optionally create a custom Apex registration handler for more control over the registration process.

Step 7: Test the Login Experience.

1. Open your Experience Cloud site URL in an incognito browser.
2. Verify that the login page shows the correct authentication options.
3. Test each login method:
   • Direct username/password login
   • SSO login (SAML or OIDC)
   • Social login (if configured)
   • Self-registration (if enabled)
4. Verify that users land on the correct page after login.
5. Verify that user records are created correctly for new external users.

Section Note: Experience Cloud login pages are highly customizable. You can replace the default login page with a fully custom LWR or Aura page. For enterprise portals, consider pre-populating the login page with the customer’s IdP so they do not have to choose — use URL parameters to auto-select the SSO method.

PROJECT: Set Up Ping Federate with Salesforce

Ping Identity (specifically Ping Federate) is another major enterprise identity provider. Many large organizations — particularly in financial services, healthcare, and government — use Ping Federate for centralized identity management. This project walks you through a complete Ping Federate SSO integration with Salesforce.

What Is Ping Federate

Ping Federate is the core product in the Ping Identity suite. Unlike Okta (which is fully cloud-based), Ping Federate is traditionally deployed on-premises or in a private cloud, although Ping now offers a cloud-hosted version called PingOne.

Ping Federate supports SAML 2.0, OAuth 2.0, OpenID Connect, WS-Federation, and WS-Trust. It is known for its deep configurability and its ability to integrate with complex enterprise identity stores (Active Directory, LDAP, custom databases).

Architecture Overview

┌───────────────────────────────────────────────────────┐
│                 Corporate Network                     │
│                                                       │
│  ┌──────────────┐     ┌────────────────────────┐      │
│  │ Active       │     │ Ping Federate          │      │
│  │ Directory    │────>│                        │      │
│  │              │     │ SAML 2.0 IdP           │      │
│  └──────────────┘     │                        │      │
│                       │ Endpoints:             │      │
│                       │  /idp/SSO.saml2        │      │
│                       │  /idp/SLO.saml2        │      │
│                       └───────────┬────────────┘      │
│                                   │                   │
└───────────────────────────────────┼───────────────────┘
                                    │ SAML Assertion
                                    │ (HTTPS)
                                    ▼
                          ┌──────────────────┐
                          │   Salesforce     │
                          │   (Service       │
                          │    Provider)     │
                          │                  │
                          │  ACS URL:        │
                          │  /login/saml     │
                          └──────────────────┘

Step-by-Step Setup

Phase 1: Gather Salesforce SP Metadata

Step 1: Get Salesforce SAML metadata.

1. In Salesforce, go to Setup > Identity > Single Sign-On Settings.
2. If you already have a SAML SSO config, click on it and note the metadata URL. Otherwise, note the following values (you will enter them in Ping Federate):
   • Entity ID: https://yourcompany.my.salesforce.com
   • ACS URL: https://yourcompany.my.salesforce.com/login/saml (or check the exact URL in your SSO settings)
   • Logout URL: https://yourcompany.my.salesforce.com/secur/logout.jsp

Step 2: Download the Salesforce signing certificate (optional).

If you want Ping Federate to verify signed SAML requests from Salesforce:

1. Go to Setup > Security > Certificate and Key Management.
2. Download the default certificate or create a new one.

Phase 2: Configure Ping Federate

Step 3: Create an SP Connection in Ping Federate.

1. Log in to the Ping Federate admin console (typically at https://pingfederate.yourcompany.com:9999/pingfederate/app).
2. Navigate to SP Connections and click Create Connection.
3. On the Connection Type tab:
   • Select Browser SSO Profiles and check SAML 2.0.
4. On the Connection Options tab:
   • Check Browser SSO.
5. On the General Info tab:
   • Partner’s Entity ID: https://yourcompany.my.salesforce.com
   • Connection Name: Salesforce Production
   • Base URL: https://yourcompany.my.salesforce.com
6. Click Configure Browser SSO.

Step 4: Configure Browser SSO.

1. Under SAML Profiles, enable:
   • IdP-Initiated SSO
   • SP-Initiated SSO
2. Click Configure Assertion Creation.

Step 5: Configure Assertion Creation.

1. Identity Mapping: Select Standard.
2. Attribute Contract: Add the attributes Salesforce needs:
   • SAML_SUBJECT (the NameID — will be mapped to Federation ID or Username)
   • Email
   • FirstName
   • LastName
3. Click Map New Adapter Instance to connect the assertion attributes to your identity source.

Step 6: Configure the Adapter Instance.

1. Select your authentication adapter (e.g., HTML Form Adapter backed by LDAP or Active Directory).
2. Map adapter attributes to assertion attributes:

3. Configure the NameID Format as urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or emailAddress, depending on what Salesforce expects.

Step 7: Configure Protocol Settings.

1. Assertion Consumer Service URL:
   • Binding: POST
   • URL: https://yourcompany.my.salesforce.com/login/saml
2. SLO (Single Logout) Service URL (optional):
   • Binding: POST
   • URL: https://yourcompany.my.salesforce.com/secur/logout.jsp
3. Allowable SAML Bindings: Select POST.
4. Signature Policy: Sign the assertion (required by Salesforce).

Step 8: Configure Credentials.

1. Select or create a Signing Certificate for Ping Federate. This is the certificate Salesforce will use to verify SAML assertions.
2. Export the certificate (you will upload it to Salesforce in the next phase).

Step 9: Activate the Connection.

1. Review all settings.
2. Set the connection status to Active.
3. Save.

Step 10: Export the Ping Federate Metadata.

1. Navigate to Server Settings > Server Settings > Protocol Metadata Export (or use the metadata URL: https://pingfederate.yourcompany.com:9031/pf/federation_metadata.ping?PartnerSpId=https://yourcompany.my.salesforce.com).
2. Download the metadata XML file.

Phase 3: Configure Salesforce

Step 11: Create the SSO Configuration in Salesforce.

1. Go to Setup > Identity > Single Sign-On Settings.
2. Click New under SAML Single Sign-On Settings.
3. You can either upload the Ping Federate metadata file directly (click New from Metadata File) or fill in the fields manually:

4. Save.

Step 12: Update My Domain.

1. Go to Setup > My Domain > Authentication Configuration > Edit.
2. Enable the “Ping Federate SSO” configuration.
3. Save.

Step 13: Populate Federation IDs.

Every Salesforce user who will log in via Ping Federate SSO must have their Federation ID field populated. The Federation ID must match the value that Ping Federate sends in the SAML assertion’s NameID.

To set Federation IDs in bulk:

1. Export users via Data Loader or Reports.
2. Add the Federation ID column (typically the user’s AD username or email).
3. Import the updated records via Data Loader.

Alternatively, use the Salesforce API or a flow to auto-populate Federation IDs based on a known mapping.

Phase 4: Test and Validate

Step 14: Test SP-Initiated SSO.

1. Open an incognito browser.
2. Navigate to your Salesforce My Domain login page.
3. Click the Ping Federate SSO button.
4. Authenticate at the Ping Federate login page.
5. Verify that you are redirected back to Salesforce and logged in.

Step 15: Test IdP-Initiated SSO.

1. Navigate directly to the Ping Federate IdP-initiated SSO URL:

   https://pingfederate.yourcompany.com:9031/idp/startSSO.ping?PartnerSpId=https://yourcompany.my.salesforce.com

2. Authenticate if prompted.
3. Verify that you land in Salesforce.

Step 16: Validate SAML Assertions.

Use a SAML debugging tool to inspect the assertions:

• Salesforce SAML Assertion Validator: Go to Setup > Identity > Single Sign-On Settings and click SAML Assertion Validator. Paste a Base64-encoded assertion to validate it.
• Browser extensions: SAML-tracer (Firefox) or SAML Chrome Panel let you capture and inspect assertions in real time.
• Ping Federate Server Logs: Check server.log for SAML processing details.

Step 17: Roll Out to Users.

1. Start with a pilot group.
2. Communicate the change and provide instructions.
3. Monitor login failures using the Login History in Salesforce (Setup > Users > Login History) and Identity Verification History.
4. Gradually expand to all users.
5. Once stable, consider disabling password login on My Domain (but always keep an emergency admin account).

Troubleshooting Ping Federate SSO

Section Note: Ping Federate is more complex to set up than Okta because it is typically deployed on-premises and requires infrastructure management (load balancing, certificate renewal, high availability). However, it offers deeper customization and is often required in regulated industries where data cannot leave the corporate network. If your organization already has Ping Federate, the integration with Salesforce is straightforward once you understand the SAML exchange.

Best Practices for SSO and Authentication in Salesforce

Planning and Design

1. Choose your identity architecture early. Decide whether Salesforce will be an SP (most common), an IdP (Salesforce can act as an IdP for other apps), or both. Document the decision and the protocols involved.

2. Use Federation ID for user matching. Rather than matching on Salesforce username (which can change), use the Federation ID field. It is purpose-built for SSO and gives you a stable identifier.

3. Implement Just-In-Time (JIT) Provisioning where appropriate. JIT provisioning automatically creates or updates Salesforce user records based on SAML assertion attributes at login time. This reduces the need for a separate provisioning process, but requires that the assertion contains all necessary user attributes.

4. Plan for multiple IdPs. Large organizations often have separate IdPs for employees, contractors, and partners. Salesforce supports multiple SSO configurations — use them.

Security

5. Always enforce MFA at the IdP level. Since SSO centralizes authentication, the IdP is a single point of trust. MFA at the IdP protects all connected applications, including Salesforce.

6. Monitor Login History and Identity Verification History. These reports show who logged in, from where, and how. Set up alerts for unusual patterns (logins from unexpected IPs, failed attempts).

7. Maintain emergency access. Keep at least one System Administrator account with direct login capability. Protect it with IP restrictions and MFA. Document the emergency access procedure.

8. Rotate certificates proactively. IdP signing certificates expire. Set calendar reminders to rotate certificates well before expiration. A sudden certificate expiration means nobody can log in.

Experience Cloud Specific

9. Use Auth Providers for social login. For customer-facing Experience Cloud sites, social login (Google, Apple, Facebook) dramatically reduces friction. Combine it with a robust Registration Handler.

10. Customize the login page. The default login page works, but a branded login page with clear options builds trust and reduces support tickets.

11. Consider passwordless authentication. For Experience Cloud sites, passwordless login via email verification can be simpler than managing passwords for external users.

Operational

12. Test SSO in a sandbox first. Always configure and test SSO in a sandbox before touching production. Salesforce sandboxes can have their own My Domain and SSO configurations.

13. Document everything. SSO configurations involve multiple systems, certificates, URLs, and user mappings. Create a runbook that covers the complete setup, including emergency procedures.

14. Communicate changes to users. SSO changes affect how people log in. Announce changes in advance, provide clear instructions, and have support ready on rollout day.

Summary

What Is Next

In Part 29, we will dive into Org Security Settings in Salesforce — session settings, session management, password policies, event monitoring, transaction security policies, file security, platform encryption, field PII settings, and field audit trail. While SSO and MFA control who can get in, org security settings control what happens once they are inside. See you there.