What is Single Sign-On?
Single Sign-On is a process that allows network users to access all authorized network resources without having to separately log in to each resource. Single Sign-On also enables your organization to integrate with an external identity management system or perform web-based single sign-on to Force.com. Single Sign-On enables multiple types of authentication integration, but the most common are:

Use an existing directory of user names and passwords, such as Active Directory or LDAP, for Salesforce users.

Advantage of Single Sign-On
Single Sign-On produces benefits in three main areas – reduction in administrative costs, increased ease of use and better implementation of security schemes.

Reduced Administrative Costs: With Single Sign-On, all user authentication information resides in a central directory, which reduces the need to maintain, monitor and potentially synchronized multiple stores, as well as reducing user support requests around passwords.

Increased ease of use: Each user only has a single username and password which grants them access to corporate resources and Salesforce. Reduced complexity means an easier to use environment that provides seamless access to all resources. Single Sign-On also saves users time, since each individual sign-on process can take 5 to 20 seconds to complete. And removing the extra step of logging into Salesforce can increase user adoption of your Salesforce applications by lowering the barrier to use.

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.

How Single Sign-On Works?
The high-level process for authenticating users via Single Sign-On is as follows:

When a user tries to log in—either online or using the API—Salesforce validates the username and checks the user’s profile settings.

If the user’s profile has the “Uses Single Sign-on” user permission, then Salesforce does not authenticate the username with the password. Instead, a Web Services call is made to the user’s single sign-on service, asking it to validate the username and password.

The Web Services call passes the username, password, and sourceIp to a Web Service defined for your organization. (sourceIp is the IP address that originated the login request). You must create and deploy an implementation of the Web Service that can be accessed by Salesforce.com servers.

Your implementation of the Web Service validates the passed information and returns either “true” or “false.”

If the response is “true,” then the login process continues, a new session is generated, and the user proceeds to the application. If “false” is returned, then the user is informed that his or her username and password combination was invalid.

The input fields in the image should be entered as described in above.

Step 3:

From Setup, click Domain Management | My Domain – Enter a new subdomain name, and click Check Availability. If the name is available, click the Terms and Conditions check box, then click Register Domain.

Step 4:

Test App sign on option should be visible on the login page of the target org. So, we need to enable it in Authentication configuration. From Setup, click Domain Management | My Domain | Edit – Authentication Configuration | Enable Test App. After enable it we can see the Test App link in Salesforce Login page. Click it and once Test App portal shows up, login using Test App Credentials.

Step 5:

To tie External System to SFDC User account, the system admin needs to know the unique id associated with External System ID that gets passed by SAML assertion. As of now, only way to get this is via reading SAML assertion as noted above and this can cause a bad user experience. The best way to approach this issue is via creating new SFDC user account whenever a use wants to setup sync between his or her External System ID and SFDC account. On the context of on-boarding, this means that the user would need to get External System ID first prior to getting SFDC account. Once the user creates External System ID, the user can use login using External System ID feature to create a new SFDC account. If the user go through this route, the federation ID field of newly created user will be auto-populated with the entity from SAML message that is specified in SAML single sign on setting. SFDC provides such option under SAML Single Sign-On Settings. It can be found at the bottom of the page.

To automate sync the External System user to Salesforce we need to write an apex class. And that class must be executed by a user, which user has the permission to create/edit of users.

Sample SOAP Message
As part of the Single Sign-On process, a Salesforce.com server makes a SOAP 1.1 request to authenticate the user who is passing in the credentials. Below is an example of this type of request. Your Single Sign-On service needs to accept this request, process it, and return a “true” or “false” response.