Preparing for Salesforce.com Delegated Authentication Single Sign-on (DA-SSO) For Impersonation

  • Updated
WARNING: The Riva for Salesforce Single Sign-On connection strategy described in this article is not supported for new Riva On-Premise installations.

New Riva On-Premise installations include a new strategy to provide impersonation access into Salesforce: the Standard Impersonation Model. For instructions on implementing the Standard Impersonation Model, see Prepare Salesforce for Riva and Create and test a Salesforce connection.

For current Riva On-Premise installations that use Salesforce Single Sign-On, administrators are encouraged to upgrade their Riva for Salesforce connection setup to the Standard Impersonation Model. For assistance, contact the Riva Success Team.

The procedures in the following article have been deprecated. The information is being retained for clients who have not yet converted to the new Standard Impersonation Model.

 

In order for the synchronization engine to fully comply with user data, profile, role and territory security, the Riva Delegated Authentication - Single Sign-on for Salesforce (Riva DA-SSO) must be configured.  This additional service allows Salesforce.com to "Impersonate" multiple users from a single account and check the validity of user credentials against a server in your environment that confirms login and password information.  After configuring Riva DA-SSO for Salesforce, the Riva server will be able "impersonate" each user's Salesforce account without needing to know each user's password.

There are two versions of Riva DA-SSO for Salesforce: 

  1. Riva DA-SSO as-a-Service:  This service is included free of charge with your Riva for Salesforce license purchase.    
  2. Riva DA-SSO as Software (On-Premise):  An additional charge to install and configure Riva DA-SSO on a server in the customer's environment.

For Riva DA-SSO On Premise, after the environment has been prepared, the customer needs to contact Omni to schedule the installation of the Riva Salesforce.com SSO and Delegated Authentication/Impersonation Provider.  

Riva DA-SSO as a Service and On Premise require that Salesforce Single Sign-on and Delegated Authentication be enabled for Salesforce and for Exchange.  Please refer to How to Enable Salesforce.com Single Sign-On (SSO) for Riva for the steps to configure Riva SSO for Salesforce.

This article discusses how to prepare the environment for the installation of the Riva Salesforce.com SSO Provider:

System Requirements for On-Premise Installation (DA-SSO)

Important Note:  Effective Jan 1, 2016 Salesforce will require secure authentication using TLS 1.1 or 1.2.  TLS 1.0 will no longer be supported.  This mandatory change will modify the default minimum system requirements for Riva On-Premise server and for Riva On-Premise SSO Provider (DA-SSO).

 

New system requirements in effect as of January 1, 2016:

Original system requirements in effect until December 31, 2015:

The Salesforce SSO provider runs as an IIS ASP.NET web application.  If available, it can be deployed to an existing website that already has a valid certificate.  Most Exchange CAS (Outlook Web Access) server already have a valid certificate, deploying the SSO provider to a virtual directory on the CAS server will allow an existing certificate to be used.

For authentication to Active Directory, access to an Active Directory domain controller is required with credentials to search the domain.  Connectivity to the domain controller uses the LDAP protocol and can be configure for SSL (port 636) or non-SSL (port 389).

Confirming Salesforce is "SSO Enabled"

To confirm that the organization has been properly SSO enabled, from the Setup administration panel, 

SFDC-AdminSetup-SecurityControls (2).png

select the Administration Setup -> Security Controls -> Single Sign-On Settings

SFDC-AdminSetup-SecurityControls-SingleSignOn.png

IMPORTANT!!

If the "Delegated authentication" section is missing / not available, contact Salesforce Support to have this feature activated for your organization.  Request that "Delegated Authentication" be enabled.

Once configured the URL for your organization would look like:

https://sf.my-company-name.com/Sso.asmx

https://owa.my-company-name.com/sf/Sso.asmx

https://salesforce.my-company-name.com/Sso.asmx

Note: Riva DA-SSO for Salesforce is complementary to SAML 2.0 which is also supported by Salesforce.  Salesforce does not currently allow SAML-based authentication for any API / WebService Delegated Authentication, Single Sign-on and User Impersonation.  SAML is not supported by Salesforce for this purpose.

Delegated Authentication  (Required)

Once the SFDC organization has been enabled for Single Sign-on (SSO), authentication requests for users configured with SSO are directed to another authentication source, usually Active Directory, LDAP or another web application.  All communication is SSL encrypted.

The delegation of Salesforce authentication to a corporately managed authentication source reduces password related support costs and enforces corporate password policies.  The users' Salesforce.com email addresses must match the Active Directory user principal name (UPN) or email address attributes.

The SSO provider runs as an IIS Web Application created using Microsoft .NET with support for 32-bit and 64-bit architectures. It can be deployed on any existing IIS Web Server and can be deployed in a DMZ.  It is available as a separate application from the standard Riva installation.

Authentication providers currently supported:

  • Active Directory
  • LDAP (eDirectory / OpenLDAP / etc...)
  • SMTP Authentication
  • Web HTTP Authentication
  • Salesforce SSO - Relay to another existing Salesforce SSO Service

Integrated Authentication  -  NTLM / Kerberos  (Optional) (On-Premise Version Only)

In addition to delegated authentication an optional Active Directory Integrated Authentication is available.

For organization that which to remove the double authentication requirements with Salesforce or integrate with a existing web portal, an integrated URL can be designated as being a trusted URL, allowing any user already authentication to the Active Directory environment to be automatically logged into Salesforce.

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 NTLM / Kerberos credentials.  Then, when accessing a URL like http://sf.omni-ts.com/ or http://salesforce/, the user is redirected to Salesforce without having to authenticate.

Internet Explorer natively supports integrated authentication and an 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 would be 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 token based authentication method, password security is increased by never sending the users corporate credentials and password over the Internet to Salesforce.com.

Process Flow Diagram

Because Riva does not know each individual user password, a one-time time-based token authentication method is used.  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, it is locked to being used by the Riva server and the specific user being authenticated.  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: Steps 1 and 2 are only performed by Riva.  When a regular user authentication to Salesforce.com, they will not use a token, they will use their regular network credentials.

Permissions Required for "Admin SSO User" Used by Riva

In order to prevent un-intended uses of the single sign-on provided, the Riva Single Sign-On Provider has two built in requirements.  The user that is configured as the "connection user" on the Salesforce.com connection within Riva must be a member of a profile that has:

  1. API Enabled = ON
  2. Manage Users = ON
  3. Modify All Data = ON

Note: We also recommend that the "Password Never Expires" option be enabled to avoid undue hardship when the password expires and having to re-configure the Riva connection to SFDC.

SFDC - Admin - AdminUser SSO Permissions (2).png

Salesforce.com IP Address Range

To reduce the exposure of the single sign-on provider to the internet, consider white listing the specified ranges of IP addresses *OWNED* by Salesforce.com. It is not leased or shared in any way with any other organizations.

Salesforce.com has an IP address block allocated directly to salesforce.com by the American Registry for Internet Numbers (ARIN).

To provide continuity of service if you utilize IP address security filters, whitelist or otherwise add salesforce.com's IP address space to your list of trusted addresses.

The IP address spaces are as follows:

204.14.232.0/23 East Coast Data Center (set one)
204.14.237.0/24 East Coast Data Center (set two)
96.43.144.0/22  MidWest Data Centers
96.43.148.0/22  MidWest Data Centers
204.14.234.0/23 West Coast Data Center (set one)
204.14.238.0/23 West Coast Data Center (set two)
202.129.242.0/23 Singapore Data Center
182.50.76.0/22  Japan Data Center

To clarify, the "0/25" that you see in the ranges refers to an abbreviated form of Classless Inter-domain routing (CIDR) notation. In essence, this notation is a network number followed by a "/" and a number , the latter number indicates the number of 1's (starting a the left most bit i.e MSB - most significant bit) in the subnet mask i.e the number of bits relevant to a network portion of the IP address. So "/25" means 25 bits constitute the subnet mask of 255.255.255.128, and really 25 bits reserved for network address which is identified by performing bitwise "AND" to the full network number.

For example 204.14.232.0/25 means 2 possible networks in the form of 204.14.232.0 and 204.14.232.128 each having possible 126 hosts i.e total 252 hosts or IP addresses per specified range.

 

 

 
 
 

Was this article helpful?

/

Comments

0 comments

Article is closed for comments.