Article ID: 281
Last updated: 15 Mar, 2016
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:
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.
Confirming Salesforce is "SSO Enabled"
To confirm that the organization has been properly SSO enabled, from the Setup administration panel,
select the Administration Setup -> Security Controls -> Single Sign-On Settings
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:
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.
Authentication providers currently supported:
Integrated Authentication - NTLM / Kerberos (Optional) (On-Premise Version Only)
In addition to delegated authentication an optional Active Directory Integrated Authentication is available.
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:
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.
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:
126.96.36.199/23 East Coast Data Center (set one)
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 188.8.131.52/25 means 2 possible networks in the form of 184.108.40.206 and 220.127.116.11 each having possible 126 hosts i.e total 252 hosts or IP addresses per specified range.
Would you please tell us how we can improve it?
If you would like to add a comment, please do so
Please report the article inaccuracies, grammatical errors, etc.
Article ID: 281
Last updated: 15 Mar, 2016