Understanding Riva Single Sign-On (SSO) for Salesforce

Salesforce has very stringent access controls on how third party sync solutions integrate with Salesforce.  To enable Riva to sync to multiple Salesforce users, Riva administrators need to:

• Understand Salesforce Single Sign-on - configure Riva to use Salesforce Delegate Authentication - Single Sign-on (DA-SSO), and
• Select the appropriate Riva Configuration - determine to use Riva DA-SSO or have each user be configured with a user-specific Riva connection to Salesforce and a unique Riva sync policy.

Understanding the Salesforce Delegate Authentication - Single Sign-on Feature

To allow the Riva server to sync multiple Salesforce user accounts with a single policy, Riva can be configured to connect to Salesforce using an "admin" level account that impersonates each user's CRM account.  To impersonate Salesforce users, Riva implements Salesforce's "Delegate Impersonation" and "Single Sign-On (SSO) options.  These options must be activated and configured against your Salesforce system and/or individual accounts.  (Note, these options do not replace SAML Single Sign-on.  They are a complement to SAML and provide different functions.)

With SSO enabled and configured, Salesforce will no longer have a separate Salesforce password for each user.  Salesforce will defer the authentication to another system.  When a user accesses his Salesforce account, Salesforce will redirect the authentication by sending a secure tokey to a different  system (most often using Active Directory) to request permission to allow the user to access Salesforce.  This means there is only one password for the end-user to remember.  There is no longer a separate password for Exchange/Active Directory and Salesforce.  When a user changes their Active Directory/Exchange password, that password immediately applies to Salesforce.

This section will discuss:

• Advantages of Salesforce SSO
• How Salesforce SSO Works (technical info)
• Can Riva DA-SSO use SAML if that is already in place?
• Using Integrated Authentication - NTLM / Kerberos (Riva On-Premise SSO Only)

Advantages of SSO

There are several inherent advantages to enabling SSO in Salesforce:

• Reduces the number of passwords that the user needs to remember.  With SSO, the user will use the same login user name and password to access their Exchange mailbox and their Salesforce account.
• Removes the ability for users to change passwords in Salesforce.
• Removes the reliance on Salesforce security tokens.
• When users change their Exchange/Active directory password, the new password immediately applies to Salesforce.

How Salesforce Single Sign-On Works

In order for the Riva synchronization engine to comply with SFDC user data, profile, role and territory security, a Delegate Authentication - Single Sign-on for Salesforce (DA-SSO) provider gateway must be configured.  This SSO provider normally runs as an IIS ASP.NET web application.

The DA-SSO provider generates a Delegated Authentication gateway URL that allows the Riva connection account to Salesforce.com to "Impersonate" multiple users and check the validity of user credentials against a server in your environment that confirms login and password information.  After configuring the DA-SSO Provider for Salesforce into the Riva CRM connection, the Riva server will be able "impersonate" each user's Salesforce account and read/write data to Salesforce without needing to have know each user's password.

To enable impersonation, Salesforce creates and uses a one-time, time-based token authentication method to communicate with Riva.  The token generation process can only be initiated by the Riva server and once the token has been generated, it is only valid for a short time period.  The token is locked to being used by the Riva server and the specific user that is being authenticated.  This token is submitted to Exchange/Active directory which then enables Riva to access the user's Salesforce data.  This is similar to the "security token" used by Salesforce for API access.

The following diagram demonstrates the process that is followed when a synchronization authentication occurs.

Note: In this diagramme, the computer representes the Riva server.  The "Token Generator" is the Riva DA-SSO Provider or pre-existing DA Gateway.  Steps 1 and 2 are only performed by Riva.  When a regular user authenticates to Salesforce.com, they will not use a token, they will use their regular Exchange/Active Directory log on credentials.

Can Riva DA-SSO use SAML if that is already in place?

Riva DA-SSO for Salesforce is complementary to SAML 2.0 which is also supported by Salesforce.  SAML is a SSO option for use with web portals.  SAML is used to provide single sign-on services to users who authenticate to a password controlled web portal that has a link to Salesforce.  After the user authenticates to the web portal, the web portal uses SAML to redirect the user to Salesforce without requiring the user to re-submit his login and password.  Salesforce does not currently allow SAML-based authentication for any API / Web Service Delegated Authentication, Single Sign-on and User Impersonation.  Riva uses Salesforce's API for Web Service-based Delegated Authentication.  SAML and Riva DA-SSO can both be configured at the same time for your Salesforce system.  SAML takes care of SSO for your web browser-based authentication.  Riva DA-SSO takes care of API and Web Service-based SSO for your users.

Using Integrated Authentication - NTLM / Kerberos (Riva On-Premise SSO Only)

In addition to delegated authentication, an optional Active Directory Integrated Authentication is available for the Riva On-Premise SSO Provider server ONLY. 

NTLM / Kerberos authentication can be used to allow your users to be automatically connected to Salesforce (without a login and password prompt) if they are authenticated to a workstation/laptop inside your firewall.  The on-premise version of Riva DA-SSO supports NTLM / Kerberos authentication.  This means a user's Active Directory login credentials are transparently used to authenticate to Salesforce as long as the user is authenticated to an Active Directory aware workstation/laptop from inside your firewall.  For users who connect to Salesforce from outside your firewall, users will receive the standard Salesforce login prompt where they enter their Salesforce login and Active Directory / Exchange password.

An example of this integration would allow any user logged in to a desktop that is a member of an Active Directory domain to access Salesforce using their existing workstation login NTLM / Kerberos credentials.  When a users accesses the "internal" DNS name that is configured for Salesforce, http://sf.omni-ts.com/ or http://salesforce/, the user is automatically redirected to Salesforce without having to re-authenticate.

Internet Explorer natively supports integrated authentication and an optional add-in is available for FireFox.  If the user is using a browser that does not support integrated AD authentication or is not currently authenticated to Active Directory, a standard browser authentication pop-up is displayed requesting Active Directory credentials.  The internet domain suffix must match trusted Active Directory domain names for the NTLM credentials to be automatically sent to IIS.

This integration reduces the overhead caused by the user having to contently re-authenticate to Salesforce and can be used for integration into existing company portals.  Also, because this integration implements a secure token-based authentication method, password security is increased by never sending users' corporate credentials and passwords over the Internet to Salesforce.com.