In today’s environment of hackers and security incidents, as a Salesforce Administrator, we need to ensure that security of our Salesforce org is tight and access to our orgs aren’t wide open. This is extremely important especially where our orgs have PII (personally identifiable information) or PHI (protected health information) data, we don’t want our company to show up in the news as the next company that has leaked customer data.

This is the second article in a 3-part series covering the security options available for configuring Salesforce access. Based on your industry, the level of data stored in Salesforce, the type of users accessing Salesforce, etc., gauge the level of security best suited for your Salesforce org and implement accordingly.

If you missed the first article, you can catch up now.

We will be covering the following in this article:

• Use Case: I Want to Specify How Salesforce Authenticates My Users
• Use Case: I Want Users to Login with SSO, Eliminate the Need to Issue and Reset Passwords
• Use Case: I Want to Increase My Security with 2-Factor Authentication
• Use Case: I Want Users to Access Salesforce With Social Logins

Use Case:  I Want to Specify How Salesforce Authenticates My Users

By default, Salesforce provides users access via its native username and password.

However, that is not your only choice.

You can implement single sign-on for your users, or increase extra security by implementing two factor authentication or even use social signon with Google, Facebook, Amazon, etc. via OpenID connect.

Use Case: I Want Users to Login with SSO, Eliminate the Need to Issue and Reset Passwords

There may be several reasons why you don’t want to use the native Salesforce username/password authentication for use access. You don’t want to deal with the hassle of issuing and managing password resets and users don’t want yet another username/password to an application to remember.

By using single signon, especially within the company’s network, users can be automatically logged into Salesforce, without needing to provide their username/password. When external to the company’s network, users use their company network login to access Salesforce.

Your company may have a centralized LDAP to manage user access so if you delegate Salesforce authentication, when a user is removed from the LDAP system, their access to Salesforce will also be removed.

There are two methods to use for single signon:

• Federated authentication using SAML where authentication and authorization data is sent between the federated services and Salesforce before it allows the user access to Salesforce. Federated authentication using SAML is enabled by default for single signon. Note: This is the most common implementation for single signon.
• Delegated authentication allows for integration between Salesforce and your company’s LDAP server. Delegated authentication is provided by permissions, rather than as an org wide setting. To use this feature, you need to submit a Salesforce case to enable this for your org. Note: For added security, you can enable this feature in your org, but do not provide an end point URL.

We will talk through Single Signon via Federated Services using SAML, since this is the more popular method.

There are two types of logins: SP (Service Provider) initiated and IDP (Identity Provider) initiated.

The SP-initiated login is the authentication process when a user accesses via the custom domain. User’s authentication goes to Salesforce and Salesforce passes the SAML request to the Identity Provider. The Identity Provider validates the SAML request and sends back the SAML assertion. If the SAML assertion is valid, the user is allowed to login.

The IDP-initiated login is the authentication process where the user accesses via the identity provider’s URL (example: <identity provider path>/IdpInitiatedSignOn.aspx?LoginToRp=https://<custom domain>. The request goes to the Identity Provider which validates the user. The Identity Provider passes the SAML assertion for the user onto Salesforce. If a valid SAML assertion is passed to Salesforce, the user is allowed to login.

The below image shows the SP-initiated and IDP-initiated login processes.

Step 1. To set up the Single Signon configuration, go to Setup | Security Settings | Single Sign-On Settings

Step 2. Click on the “New” button in the SAML Single Sign-On Settings.

Step 3. Provide the SSO settings and save changes.

Visit Salesforce’s Help & Training for more information on the SSO setup.

Step 4. Click on the “Download Metadata” button to download the SSO Configuration XML. Send this file to your identity provider to configure on the IDP side.

Step 5. Once configured on the IDP side, go back to the Single Signon Settings screen and check “SAML Enabled” and save changes.

Step 6. Test the SP- and IDP-initiated URLs to ensure both are working.

If they do not, you will need to troubleshoot the issue with your Identity Provider.

(Optional) Step 7. For added security, enable Delegated Authentication and leave the Delegated Gateway URL empty.

Note: Delegated Authentication is a feature that needs to be enabled by Salesforce.

Now, you need to determine whether you want to make your users single sign-on users only, which means these users will not be able to use their Salesforce username/password to log into Salesforce. You can enforce this either at the profile level or via a permission set. You can automate the assignment of the permission set to your users using process builder and visual workflow.

The permission can be found under System Permissions:

Here are some things to consider with SSO:

• You do not want to enforce SSO on your system administrator profile.

As a contingency in the event that SSO is down, you need someone with a Salesforce username/password to be able to log into Salesforce, remove SSO and reset passwords so your users can continue to use the system until SSO is back up. If you enable SSO on the system administrator profile, you will be locked out of the system.

• Apex Data Loader and 3rd party tools do not work with SSO.

If there is a likelihood that there are users sharing the same profile who will use these tools, you may want to consider either creating a non-SSO version of the same profile or create a SSO Enabled User permission set. There are obviously pros and cons for each approach. You will have to determine the one that makes most sense maintenance wise – maintaining two versions of the same profile or managing users who need to be assigned to a permission set. If you choose the SSO Enabled User permission set route, you can automate the removal and reactivation of the permission set.

• You have people external to your corporate network who also use the same profile as corporate users

You’re in a similar situation as the 3rd party tools. Either maintain a non SSO version of the same profile or assign SSO permission sets to corporate users.

• Integration accounts will most likely not have the data sent in the SAML request, such as employee number, so they would not be good candidates for SSO only access.

Use Case: I Want to Increase My Security with 2-Factor Authentication

According to Wikipedia, “two-factor authentication (also known as 2FA) is a technology that provides identification of users by means of the combination of two different components. These components may be something that the user knows and something that the user possesses or something that is inseparable from the user.”

You may have a use case where you need your users to go through multi-factor authentication at all times.

Or, you may have a use case that calls for users to be able to access Salesforce when not on the company network. You want to pose an additional security layer by having 2 factor authentication kick in only when Salesforce detects that they are accessing Salesforce externally.

Both use cases can be solutioned in Salesforce.

Note: To use 2FA, your users will need a mobile device that can scan a QR code and install an authenticator app, such as the Salesforce Authenticator or the Google Authenticator.

For the first use case, you can enable two factor authentication either at the profile level or via a permission set under System Permissions. You have two options, enable 2FA for API logins and interface logins.

For the second use case, we want 2FA to be invoked only when users are accessing Salesforce external to the corporate network. For that, we will need to create Login Flows for each profile this use case applies to.

Winter ’15 introduced new capability called Login Flows. Login flows allow you to completely customize your user’s login experience, collect/update user data during the login process, integrate with different two-factor authentication methods and more.

Rather than create login flows (using visual workflows) from scratch, I’d recommend installing an unmanaged package created by Salesforce of sample login flows: https://na15.salesforce.com/_ui/core/mfpackage/install/InstallPackageLandingPage?p0=04to0000000WA6J

This package contains the following samples:

• Email Confirmation – Send email with a verification code

• SF-TOTP – Time-based One-Time Password two-factor authentication

• Conditional Two-Factor- Skip Two-factor authentication for users who come from a trusted IP address

• Identity Confirmation – Confirm the user identity using email and/or two-factor authentication

• Accept Terms of Service – Have the user agree to to terms before continuing

In our scenario, we will be using the “Conditional Two Factor” login flows.

Step 1. Install the unmanaged Login Flows package in your Salesforce org.

You can find the installed flows under Setup | Create | Workflow & Approvals | Flows.

Let’s take a look at the Conditional Two Factor login flow.

This is a three step process.

1. First it verifies whether the user’s IP address against the IP addresses listed in the Network Access screen.
2. Then, it determines if it is a trusted IP
3. It is not a trusted IP so it invokes the other login flow SF-TOTP.

Let’s take a look at the login flow SF-TOTP

This login flow includes the following steps:

1. Lookup the TwoFactorInfo object for the current user. If the user has not registered a TOTP token, generate a key.
2. Determine if the user is already registered with TOTP or not.
3. If the user is already registered, prompt the user to provide the TOTP token.
4. If the user is not registered, prompt the user to register with a QR code and provide the TOTP token.
5. Verify the TOTP token provided by the user.
6. If the TOTP token is valid, the login flow finishes and the user can log in. If the TOTP token is invalid, the flow sends the user back to Step 2.

Now it’s time to create new login flow(s) for each profile you can to set up for conditional 2 factor authentication.

Step 2. Go to Setup | Security Controls | Login Flows. Click on the “New” button.

Step 3. Provide the User Interface Login Flow connection information and save changes:

• Name: Specify the name, you can use the profile name
• Flow: Select “Conditional_Two_Factor”
• User License: Select the profile’s Salesforce license type
• Profile: Select the profile you want to configure for conditional two factor authentication

Step 4. Repeat steps 2-3 for each profile you want to configure conditional 2FA.

Use Case: I Want Users to Access Salesforce With Social Logins

Make life easier for your users by allowing them to use their social login credentials from external authentication partners, such as Facebook, Google, LinkedIn, etc.

This includes three general steps:

• Configure the service provider website.
• Create a registration handler using Apex.
• Define the authentication provider in your organization.

Refer to this YouTube video on Social Login for detailed steps: https://www.youtube.com/watch?v=D0YUTb-w1Yc&feature=youtu.be