Single sign-on allows users to access all authorized network resources without having to log in separately to each resource. You validate usernames and passwords against your corporate user database or other client application rather than having separate user passwords managed by Salesforce.
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
Authentication Providers are available in: Professional, Enterprise, Performance, Unlimited, and Developer Editions
User Permissions Needed
To view the settings:
“View Setup and Configuration”
To edit the settings:
“Modify All Data”
Salesforce offers the following ways to use single sign-on:
Federated authentication using Security Assertion Markup Language (SAML) allows you to send authentication and authorization data between affiliated but unrelated Web services. This enables you to sign on to Salesforce from a client application. Federated authentication using SAML is enabled by default for your organization.
Delegated authentication single sign-on enables you to integrate Salesforce with an authentication method that you choose. This enables you to integrate authentication with your LDAP (Lightweight Directory Access Protocol) server, or perform single sign-on by authenticating using a token instead of a password. You manage delegated authentication at the permission level, allowing some users to use delegated authentication, while other users continue to use their Salesforce-managed password. Delegated authentication is set by permissions, not by organization.
The primary reasons for using delegated authentication include:
Using a stronger type of user authentication, such as integration with a secure identity provider
Making your login page private and accessible only behind a corporate firewall
Differentiating your organization from all other companies that use Salesforce in order to reduce phishing attacks
You must request that this feature be enabled by Salesforce. Contact Salesforce to enable delegated authentication single sign-on for your organization.
Authentication providers let your users log in to your Salesforce organization using their login credentials from an external service provider. Salesforce supports the OpenId Connect protocol that allows users to log in from any OpenID provider such as Google, PayPal, LinkedIn and other services supporting OpenID Connect. When authentication providers are enabled, Salesforce does not validate a user’s password. Instead, Salesforce uses the user’s login credentials from the external service provider to establish authentication credentials.
When you have an external identity provider, and configure single sign-on for your Salesforce organization, Salesforce is then acting as a service provider. You can also enable Salesforce as an identity provider, and use single sign-on to connect to a different service provider. Only the service provider needs to configure single sign-on.
Implementing single sign-on can offer the following advantages to your organization:
Reduced Administrative Costs: With single sign-on, users only need to memorize a single password to access both network resources or external applications and Salesforce. When accessing Salesforce from inside the corporate network, users are logged in seamlessly, without being prompted to enter a username or password. When accessing Salesforce from outside the corporate network, the users’ corporate network login works to log them in. With fewer passwords to manage, system administrators receive fewer requests to reset forgotten passwords.
Leverage Existing Investment: Many companies use a central LDAP database to manage user identities. By delegating Salesforce authentication to this system, when a user is removed from the LDAP system, they can no longer access Salesforce. Consequently, users who leave the company automatically lose access to company data after their departure.
Time Savings: On average, a user takes five to 20 seconds to log in to an online application; longer if they mistype their username or password and are prompted to reenter them. With single sign-on in place, the need to manually log in to Salesforce is avoided. These saved seconds add up to increased productivity.
Increased User Adoption: Due to the convenience of not having to log in, users are more likely to use Salesforce on a regular basis. For example, users can send email messages that contain links to information in Salesforce such as records and reports. When the recipients of the email message click the links, the corresponding Salesforce page opens automatically.
Increased Security: Any password policies that you have established for your corporate network will also be in effect for Salesforce. In addition, sending an authentication credential that is only valid for a single use can increase security for users who have access to sensitive data.
Using Frontdoor.jsp to Log Into Salesforce You can use frontdoor.jsp to give users access to Salesforce from a custom Web interface, such as a remote access Force.com site or other API integration, using their existing session ID and the server URL.
Identity Providers and Service Providers An identity provider is a trusted provider that lets you use single sign-on to access other websites. A service provider is a website that hosts applications. You can enable Salesforce as an identity provider and define one or more service providers. Your users can then access other applications directly from Salesforce using single sign-on. Single sign-on can be a great help to your users: instead of having to remember many passwords, they only have to remember one. Plus, the applications can be added as tabs to your Salesforce organization, which means users don’t have to switch between programs.
Named Credentials A named credential specifies the URL of a callout endpoint and its required authentication parameters in one definition. To simplify the setup of authenticated callouts, specify a named credential as the callout endpoint. If you instead specify a URL as the callout endpoint, you must register that URL in your org’s remote site settings and handle the authentication yourself. For example, for an Apex callout, your code would need to handle authentication, which can be less secure and especially complicated for OAuth implementations.