Getting started with Single Sign-On

Single Sign-On (SSO) is a process allowing network users to access all the authorized network resources without logging into each resource individually. Single Sign-On allows validating usernames and passwords against a single secured authentication system such as Microsoft Active Directory or Lightweight Directory Access Protocol (LDAP) implementations. Due to this, when a Salesforce environment is configured to use SSO authentication, the need to manage the passwords of Salesforce user login credentials individually is eliminated. 

Single Sign-On enables multiple types of authentication integrations. All of which allow for:

• Use an existing directory of user names and passwords, such as Active Directory or LDAP, for Salesforce users.
• Allow seamless sign-on to Force.com applications, eliminating the need for explicit user log on actions.

Overview of Single Sign-On
(Click the image to expand it.)

Types of Single Sign-On

The following are the two most common types of Single Sign-On:

• Delegated Authentication
• Federated Authentication

Delegated Authentication

Delegated Authentication is the process of validating user credentials by calling an external Web Service, this Web Service would verify user credentials against a user directory, such as an LDAP (Lightweight Directory Access Protocol) server or a Microsoft Active Directory server.

This means your users would go to login.salesforce.com, enter their Active Directory credentials into the Salesforce login dialog (in the form of user@domain.com) and if the Salesforce profile for this user has SSO enabled, Salesforce makes a call to a pre-defined Web Service to validate the user supplied credentials. The pre-defined Web Service internally validates the request against an existing authentication server (for example, LDAP or AD).  The Web server will then return a true or false response to Salesforce. If the response is true, the user is granted access to Salesforce else the user is informed that the credentials are invalid.

Federated Authentication

Federated authentication is the process of validating user credentials against an Identity Provider such as Microsoft Active Directory Federated Services (ADFS) 2.0 or OneLogin. This process uses SAML 2.0 (Security Assertion Markup Language), an industry standard for secure integrations.

Much like Delegated Authentication, Federated Authentication can validate user credentials using the Salesforce login page. Unlike Delegated Authentication, Federated Authentication can send a SAML assertion to the Salesforce platform in the form of an HTTP POST request from a pre-configured Identity Provider (such as Microsoft ADFS or OneLogin). The HTTP post will contain the user’s UID (also known as the user identification (User ID).  For example, sallysmith@testdomain.com would be considered a UID). This assertion has a limited time validity and is digitally signed from the trusted Identity Provider.

Identity Provider Initiated and Service Provider Initiated are used to implement Federated Authentication.

Identity Provider Initiated

In an Identity Provider-initiated single sign-on scenario, the Identity Provider is configured with links to specific Service Providers or applications. These links actually refer to the local Identity Provider single sign-on service and pass parameters to the service identifying the remote Service Provider. So instead of directly visiting the Service Provider (for example, SalesForce.com), the user goes to the Identity Provider site (for example, OneLogin.com) and clicks on one of the links to gain access to the remote Service Provider. This triggers the creation of a SAML assertion that is subsequently transported to the Service Provider.

In other words, the user is required to authenticate with the Identity Provider (for example, ADFS 2.0, OneLogin) first and then they may access Salesforce or other pre-defined websites or applications. On successful validation the user is redirected to the application, which in our case is the Force.com platform. The Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed before it is placed within a SAML assertion message and sent to the service provider.

The Identity Provider initiated process follows this sequence:

1. User navigates to the Identity Provider’s web page.
2. The IDP web page redirects to the IDP login page.
3. On the IDP login page, the user enters their credentials.
4. On successful validation, the user is again redirected to an IDP web page containing one or more service providers or applications links.
5. The user selects one of the service provider or application links from the IDP web page.
6. On selection, a SAML assertion is sent to the selected service provider or application.
7. The service provider or application processes the SAML assertion.
8. On successful validation of the SAML assertion, the user is granted access to the selected service or application.

For more information, see Figure2.
IDP Initiated Login.
(Click the image to expand it.)

Service Provider Initiated

In Service Provider Initiated login the authentication process starts at the Service Provider (for example, SalesForce.com). The Service Provider sends an authentication request to the IDP. At the IDP, user credentials are verified and an authentication response (SAML Assertion) is sent back to the originating Service Provider. If the SAML assertion is valid, the user is granted access to the Service Provider site or application.

Thus a user would start by clicking a link to the service provider (for example,  a bookmark, mailed link, etc.) and is temporarily redirected to the Identity Provider for authentication, then returned to the link they initially requested i.e. Service Provider or application , which in our case is Salesforce.com or a Force.com application like the RemedyForce Self Service page.

The Service Provider initiated process:

1. User clicks on the provided Salesforce domain link. The user is redirected to the IDP site.
2. If the user is not already authenticated by the IDP, the user is direct to the IDP login page.
3. Once authenticated, the IDP redirects the user to Salesforce along with a SAML assertion.

Salesforce process the SAML assertion and then redirects the user to the requested page. For more information, see Figure3.
SP Initiated Login
(Click the image to expand it.)

Service Provider Initiated SSO vs. Identity Provider Initiated SSO

The IDP Initiated SSO process is initiated by the IDP sending an SAML assertion to the Service Provider.

In Service Provider Initiated SSO, the Service Provider generates an authentication request that is sent to the IDP as the first step in the Federation process and the IDP then responds with a SAML Response. 

For more information, see Figure4.
SP Initiated SSO vs IDP Initiated SSO
(Click the image to expand it.)