Best Practices and Tips for Implementing Single Sign-On

Salesforce offers a set of best practices that you can follow when implementing delegated authentication, federated authentication using SAML, single sign-on (SSO) for portals, and SSO for Sites.

Available in: both Salesforce Classic and Lightning Experience

Federated Authentication is available in: All Editions

Delegated Authentication is available in: Professional, Enterprise, Performance, Unlimited, Developer, and Database.com Editions

Customer Portals and partner portals are not available in Database.com

User Permissions Needed
To view the settings:	View Setup and Configuration
To edit the settings:	Customize Application AND Modify All Data

Salesforce offers the following ways to use SSO.

Federated authentication using Security Assertion Markup Language (SAML) lets you send authentication and authorization data between affiliated but unrelated web services. You can log in to Salesforce from a client app. Salesforce enables federated authentication for your org automatically.
Delegated authentication SSO integrates Salesforce with an authentication method that you choose. You can integrate authentication with your LDAP (Lightweight Directory Access Protocol) server or use a token instead of a password for authentication. You manage delegated authentication at the permission level, not at the org level, giving you more flexibility. With permissions, you can require some to use delegated authentication while others use their Salesforce-managed password.
Delegated authentication offers the following benefits.
- Uses a stronger form of user authentication, such as integration with a secure identity provider
- Makes your login page private and accessible only behind a corporate firewall
- Differentiates your org from all other companies that use Salesforce to reduce phishing attacks
You must contact Salesforce to enable delegated authentication before you can configure it on your org.
Authentication providers let your users log in to your Salesforce org using their login credentials from an external service provider. Salesforce supports the OpenID Connect protocol, which lets users log in from any OpenID Connect provider, such as Google, PayPal, and LinkedIn. When an authentication provider is enabled, Salesforce doesn’t validate a user’s password. Instead, Salesforce uses the user’s login credentials from the external service provider to establish authentication credentials.

In addition, you can also configure SAML for use with portals as well as for Sites.

Delegated Authentication Best Practices

Consider these best practices when implementing delegated authentication SSO for your org.

Your org’s implementation of the web service must be accessible by Salesforce servers, so you must deploy the web service on a server in your DMZ. Remember to use your server’s external DNS name when entering the delegated gateway URL in the Delegated authentication section in Salesforce. From Setup, enter Single Sign-On Settings in the Quick Find box, then select Single Sign-On Settings.
If Salesforce and your system can’t connect, or if the request takes longer than 10 seconds to process, the login attempt fails. The user gets an error message indicating that the corporate authentication service is down.
Namespaces, element names, and capitalization must be exact in SOAP requests. Wherever possible, generate your server stub from the WSDL file to ensure accuracy.
For security reasons, make your web service available by TLS. A certificate from a trusted provider, such as Verisign or Thawte, is required. For a list of trusted providers, contact Salesforce.
The IP address that originated the login request is sourceIp. Use this information to restrict access based on the user’s location. Also, the Salesforce feature that validates login IP ranges applies to SSO users. For more information, see Restrict Where and When Users Can Log In to Salesforce.
You might need to map your org’s internal usernames to your Salesforce usernames. If your org doesn’t follow a standard mapping, try extending your user database schema (for example, Active Directory) to include the Salesforce username as an attribute of a user account. Your authentication service can then use this attribute to map back to a user account.
We recommend that you don’t enable SSO for Salesforce admins. If your Salesforce admins are SSO users and your SSO server has an outage, they have no way to log in to Salesforce. Make sure that Salesforce admins can log in to Salesforce so that they can disable SSO if problems occur.
We recommend that you use a Developer Edition account or a sandbox when developing a SSO solution before implementing it in your org. To sign up for a free Developer Edition account, go to developer.salesforce.com.
Make sure to test your implementation with Salesforce clients, such as Salesforce for Outlook, Connect for Office, and Connect Offline. For more information, see Single Sign-On for Salesforce clients.

Federated Authentication Using SAML Best Practices

Consider these best practices when implementing federated SSO with SAML for your org.

Get the Salesforce login URL from the Single Sign On Settings configuration page and enter it in the corresponding configuration parameter of your identity provider. Sometimes, the setting is called the recipient URL.
Salesforce allows a maximum of 3 minutes for clock skew with your IDP server. Make sure that your server’s clock is up to date.
If you can’t log in with SAML assertion, check the login history and note the error message. Use the SAML Assertion Validator on the Single Sign On Settings configuration page to troubleshoot.
Map your orgs internal usernames and Salesforce usernames. To map the names, you can add a unique identifier to the FederationIdentifier field of each Salesforce user. Or you can extend your user database schema (for example, Active Directory) to include the Salesforce username as an attribute of a user account. Choose the corresponding option for the SAML Identity Type field, and configure your authentication service to send the identifier in SAML assertions.
Before allowing users to log in with SAML assertions, enable the SAML org preference and provide the necessary configurations.
Use the My Domain feature to prevent users from logging in to Salesforce directly, and give admins more control over login policies. You can use the URL parameters provided in the Salesforce Login URL value from the Single Sign-On Settings configuration page with your custom domain.
For example, if the Salesforce Login URL is https://login.salesforce.com/?saml=02HKiP...

you can use https://yourDomain.my.salesforce.com/?saml=02HKiP...
We recommend that you use a Developer Edition account or a sandbox when testing a SAML SSO solution. To sign up for a free Developer Edition account, go to developer.salesforce.com.
Sandbox copies are made with federated authentication with SAML disabled. Any configuration information is preserved, except the value for Salesforce Login URL. The Salesforce Login URL is updated to match your sandbox URL, for example https://yourInstance.salesforce.com/, after you re-enable SAML. To enable SAML in the sandbox, from Setup, enter Single Sign-On Settings in the Quick Find box, then select Single Sign-On Settings; then click Edit, and select SAML Enabled.
Your identity provider must allow you to set the service provider’s audience URL. The value must match the Entity ID value in the SSO configuration. The default is https://saml.salesforce.com.

SSO for Portals Best Practices

Customer Portals and partner portals are not available for new orgs as of the Summer ’13 release. Use Communities instead. For more information about SSO and SAML for Communities, see “Configuring SAML for Communities” in the Salesforce Help. If you continue to use portals, be aware of these requirements.

Only SAML version 2.0 can be used with portals.
Only Customer Portals and partner portals are supported.
Service provider initiated login is not supported.
Both the portal_id and organization_id attributes are required. If only one is specified, the user receives an error.
If both the portal_id and organization_id attributes are populated in the SAML assertion, the user is directed to that portal login. If neither is populated, the user is directed to the regular SAML Salesforce login.
More than one portal can be used with a single org.

SSO for Sites Best Practices

Only SAML version 2.0 can be used with Sites.
Only Customer Portals and partner portals are supported.
Service provider initiated login is not supported.
The portal_id, organization_id, and siteUrl attributes are required. If only one is specified, the user receives an error.
If all the portal_id, organization_id and siteUrl attributes are populated in the SAML assertion, the user is directed to that Sites login. If the siteUrl isn’t populated and the other two are, the user is directed to the portal login.
More than one portal can be used with a single org.

SSO Login Settings Tips

You can set a user permission to prevent users from using a Salesforce username and password. For example, use this permission when you configure users to use an authentication provider for single sign-on, and want them to use that authentication provider, only. Assign these users, or the profile for these users, the “Is Single Sign-On Enabled" user permission. If the “Is Single Sign-On Enabled" permission is not available in your org, contact Salesforce and ask Support to enable the delegated authentication feature.
In this case, you don’t have to configure delegated authentication for your org. However, you need the delegated authentication feature to enable the “Is Single Sign-On Enabled" permission for users or profiles.
System administrators should always be able to log in to Salesforce, even if single sign-on is enabled for their accounts. For example, if your third-party authentication provider has an outage, the administrators need a way to log in to Salesforce. And, if an authentication provider has an outage, the system administrators may configure other users to log in to Salesforce.