In this blog post I am going to share my experience on SSO (Single Sign On) implementation in Salesforce. It will provide details on Single Sign On and Configuring SAML settings for Single Sign On. It will help in configuring the salesforce organization to use single sign on.

OVERVIEW AND SCOPE

Single sign-on allows users to access all authorized network resources without having to log in separately to each resource. Users can validate usernames and passwords against their corporate user database or other client application rather than having separate user passwords managed by Salesforce.

IN SCOPE

The project which I implemented provided the following functionalities enabled for users:-

• Federated authentication using Security Assertion Markup Language (SAML)
• Establish a SAML identity provider and gather information about how they will connect to Salesforce. This is the provider that will send single sign-on requests to Salesforce

The main functionalities expected from this development are:

• With single sign-on, users only need to memorize a single password to access both network resources or external applications and Salesforce
• Any password policies that have been established for your corporate network will also be in effect for Salesforce
• 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.

OUT OF SCOPE

The following components and features will be deemed out of scope:

• Delegated authentication single sign-on

SOLUTION APPROACH

1.1            CURRENT AS IS PROCESS

Currently users access all authorized network resources with having to log in separately to each resource. Users need to manually log in to Salesforce every time the need arises. Any password policies that has been established for the corporate network, is not in effect for Salesforce.

1.2            TO BE PROCESS

Federated authentication using Security Assertion Markup Language (SAML) allows us to send authentication and authorization data between affiliated but unrelated Web services. This enables us to sign on to Salesforce from a client application.

Diagram 1: To-Be-Process

Diagram 2: How Federated Authentication Works

Now lets see how does federated authentication works as shown below-

CONFIGURING FORCE.COM FOR SSO

Steps:

• Login into your Force.com org and click Setup -> Security Controls -> Single Sign-On Settings. The screen should initially look like the following.

• Click the Edit button and then check the SAML Enabled checkbox.
• We will upload the Verification Certificate file received from the Identity Provider by clicking on the ‘Choose File’ in the Identity Provider Certificate. We would need to configure the identity provider to get the Federation ID value. This Federation ID attribute value will be mapped to Force.com user’s Federation ID attribute. Enter this value in the Attribute Name.

We need to enter the Issuer. This is often referred to as the entity ID for the identity provider.

If our Salesforce organization has domains deployed, specify whether to use the base domain (https://saml.salesforce.com) or the custom domain for the Entity ID. This information must be shared with the identity provider.

• After saving the settings, a Force.com Login URL is generated. We have to use this URL as the salesforce Login URL for our Identity provider.

CONFIGURING THE FORCE.COM USER

Since SSO is enabled we will see a new field on the user details page called, “Federation ID”. Edit the user details and enter the unique value for the Federation Id. Once we save the user, setting up federated authentication is complete and we are ready to test our SSO solution.

BEST PRACTICES FOR FEDERATED SSO

 1) We may choose to add a unique identifier to the Federation ID field of each Force.com user, or extend your user database schema (for example, Active Directory) to include the Force.com username as an attribute of a user account. Be careful if you assume that all corporate email addresses map directly to Force.com usernames. Users may have inadvertently used their corporate email address in a different org (i.e., free or developer org).

2) System Administrators should not be SSO-enabled as they will be locked out during outages.

3) Notify users that password resets for Force.com applications are no longer done from the Salesforce interface.

Kindly share this post if it helps you and if you have any questions, please feel free to post a comment.