Salesforce Single Sign-On Flows

Single Sign-On (SSO) flows facilitate user authentication by allowing individuals to utilize their identity from an external system. Within Salesforce, three mechanisms can be employed to accomplish this:

1. Security Assertion Markup Language (SAML), which involves the exchange of signed structured messages, termed SAML requests and assertions, between the identity provider and the service provider through the web browser.
2. OpenID Connect, which leverages OAuth web server or user agent flows to establish a trusted relationship between the parties involved.
3. Delegated Authentication, a method that captures and submits user credentials for authentication via a Simple Object Access Protocol (SOAP) message. This mechanism can prove advantageous for authenticating users accessing systems that do not support other protocols.

Let’s dig into the sequence of messages involved in the SSO mechanisms supported by Salesforce for the aforementioned flows.

Service Provider (SP) Initiated SSO

In the event that Salesforce functions as the Service Provider, the following configurations must be implemented:

1. The “Single Sign-On Settings” within Salesforce should be configured using the values obtained from the Identity Provider (IDP).
2. The certificate provided by the IDP must be uploaded into Salesforce as the identity provider certificate. This certificate is essential for the validation of signatures on incoming SAML responses.
3. Requests from Salesforce will be signed utilizing the selected certificate, allowing for validation by the IDP when required.
4. Assertions encrypted by the IDP are also supported, necessitating the upload of a decryption certificate, which should be designated as the Assertion Decryption Certificate.
5. SAML request bindings can be configured to either HTTP Redirect or HTTP POST, determining whether the initial SAML authentication request is executed as a GET or POST method.
6. Just In Time (JIT) user provisioning may be configured, enabling the automatic creation and update of user records based on the contents of incoming SAML assertions. Salesforce will attempt to match existing user records and will either update the corresponding record or create a new user in real time. Standard provisioning allows the use of assertion attributes that correspond to standard field names for both matching and populating field values. Alternatively, custom logic may be implemented through a dedicated class that adheres to the Auth.SamlJitHandler interface.
7. The IDP must be configured with the Authorization Consumer Service (ACS) URL, also referred to as the “Salesforce Login URL,” and the Entity ID.
8. MyDomain is a prerequisite for Service Provider-Initiated Single Sign-On (SSO), as it facilitates deep linking (allowing access to a specified URL) and OAuth with SAML.

Conversely, when Salesforce acts as the Identity Provider, the following steps must be undertaken:

1. The Salesforce identity provider setup must be activated, and a connected app must be created for each service provider. This should specify the Authorization Consumer Service (ACS) URL and the service provider’s Entity ID, in addition to general SAML configurations that may vary by service provider.
2. User profiles or permission sets must be included in the connected app to authorize accounts for SSO identity.
3. Optionally, SAML request signatures for a service provider can be validated by uploading the service provider’s signing certificate.
4. SAML responses may be encrypted for enhanced security.
5. The Start URL of the connected app is utilized as the Relay State when the app’s icon is selected in the Salesforce app launcher.

These configurations are critical for ensuring optimal functionality of Single Sign-On processes within Salesforce, whether operating as a Service Provider or an Identity Provider.

OpenID Connect (OIDC)

OpenID Connect is widely recognized as the standard and most prevalent protocol for identity verification, operating within the OAuth 2.0 framework. Salesforce facilitates the configuration of OpenID Connect providers as authentication providers for Social Sign-On through a straightforward setup process.

Numerous identity services provide mechanisms for identity verification based on OAuth 2.0, which, while similar, do not completely align with the OpenID Connect specification. Custom authentication providers can be established for these services by extending the Auth.AuthProviderPluginClass with bespoke logic that initiates authentication and retrieves user information, as detailed in the Salesforce documentation.

OpenID Connect is supported by services such as Google and Microsoft and is prominently featured in the pre-configured authentication providers associated with these platforms. Furthermore, several popular OAuth-based identity services that do not fully comply with the OpenID Connect specification are also available as pre-configured options in Salesforce. Notable examples of these services include:

• Facebook Login
• Twitter (Login with Twitter)
• LinkedIn (Member Authorization API and Profile API for user attributes)
• GitHub (which allows the retrieval of a user’s profile information following the acquisition of an access token)

Additionally, a Salesforce organization can function as an OpenID Connect Provider for external applications. In this scenario, either the web server version or an alternative OAuth flow may be employed for authentication and authorization.

Besides Social Sign-On, Salesforce authentication providers can also be utilized to authenticate content providers for Salesforce Files Connect, such as Google or Office 365.

Salesforce manages the client ID and secret for standard authentication providers, including Facebook and Google; however, these credentials may be overridden within the organization if necessary.

Key characteristics of OpenID Connect include the following:

• If a nonce is provided, it is incorporated as an attribute within the ID token, which binds the token to a specific authorization request and helps mitigate the risk of replay attacks that could occur through Cross-Site Request Forgery (CSRF).
• The UserInfo endpoint can be utilized to supply ID claims that are not included in the ID token’s scope, such as the user’s picture, email, website, locale, and phone number.
• The draft OpenID Connect Session Management specification recommends that the relying party regularly verify the session’s continued activity at the OpenID Provider; however, these checks are not conducted in the current implementation of the Salesforce Authentication Provider.
• The OpenID Connect Core specification provides comprehensive details regarding the implementation of this flow.

This structured overview provides clarity on the capabilities and configurations associated with OpenID Connect within the Salesforce environment.

Identity Provider (IDP) Initiated SSO

The security of the IDP-Initiated Single Sign-On (SSO) flow is comparatively compromised when juxtaposed with the Service Provider (SP)-Initiated version. This flow exhibits a heightened susceptibility to Man-in-the-Middle and Cross-Site Request Forgery (CSRF) attacks, as outlined in the references provided below. Consequently, it is imperative to exercise caution and conduct thorough consideration prior to opting for IDP-Initiated SSO.

When Salesforce functions as an Identity Provider (IDP), selecting an SP’s connected application icon from the App Launcher does not engage this flow. Instead, it initiates an SP-Initiated version wherein Relay_State is set to the Start URL.

IDP-Initiated SSO can be utilized in the authentication of canvas applications by selecting the “Identity Provider Initiated” option as the method of initiation for the canvas application. This approach presents the advantage that the SAML response is transmitted, allowing for user authentication without the necessity of the canvas application or service provider first presenting an unauthenticated login page. Such a login page may not support embedding in an iframe, a consideration that is particularly pertinent to Salesforce’s own standard login page and thereby relevant to Salesforce-to-Salesforce canvas applications.

In instances where Salesforce serves as the Service Provider, the general setup considerations and capabilities associated with the Service Provider-Initiated SSO flow remain applicable, with the exception of the My Domain requirement, which is not mandatory in this context.

Delegated Authentication from Salesforce Login

This document outlines a method for utilizing credentials to access applications that do not support Security Assertion Markup Language (SAML) for authentication into Salesforce.

It is important to note that a My Domain configuration is not a prerequisite for this process. The delegated authentication SOAP endpoint must adhere to a specific Web Services Description Language (WSDL), which can be downloaded from Salesforce. Unlike standard procedures, the password is not validated within Salesforce; instead, it is forwarded to the authentication service for verification. Consequently, the Salesforce password policy is not applicable in this context.

The successful implementation of this flow necessitates that the delegated authentication endpoint possesses the capability to process passwords. Furthermore, an administrator has the authority to enable or disable delegated authentication through the Single Sign-On Settings.

The permission labeled “Is Single Sign-On Enabled” determines whether individual users can submit passwords to the delegated authentication service.

Additionally, a useful strategy for SAML migration involves restricting certain users from logging in using their username and password. By enabling delegated authentication and activating the “Is Single Sign-On Enabled” permission, administrators can effectively prevent these users from accessing Salesforce via their passwords.