The Relativity hybrid model

With the introduction of RelativityOne, hybrid environments (combining cloud and on-premises instances) are becoming a common deployment scenario. The Relativity hybrid model provides a compelling alternative to on-premises hosting of cases.

Hybrid environment business scenarios:

  • Your organization decided to start migrating older cases to RelativityOne
  • Your firm’s IT department then no longer has to provision more hardware for new cases
  • Simply migrate old cases to RelativityOne to free up infrastructure in your local data center

Relativity hybrid model allows you to start new cases in the RelativityOne instance with benefits such as:

  • Avoiding the hassle of provisioning hardware to support those cases
  • Viewing/accessing cases in a different instance via the Workspace Portal
  • Single sign on across instances when using Workspace Portal (when using OpenID Connect protocol):

Despite the benefits of this hybrid model, RelativityOne is a separate instance with a separate user store and separate credentials. You must manage user credentials across two different systems - a task that can be time consuming and prone to errors.

Note: The following topic provides a comparison of the options for configuring single sign-on (SSO) workflow in hybrid Relativity environments with Okta, Azure AD, and Active Directory Federation Services as identity providers. It also describes how the Workspace Portal and Relativity User and Group Synchronization applications can be used in combination with SSO to create a more seamless Relativity experience across your connected Relativity instances.

This page contains the following sections:

Refer to the following related pages:

Basic high-level workflow for setting up the hybrid model

We recommend the following workflow when setting up the Relativity hybrid model:

  1. Set up single sign-on (SSO) in both your master and duplicate instance to allow you to navigate between these instances without having to use two sets of credentials. See Single sign-on workflow (SSO) overview.
  2. Set up and install Workspace Portal in order to view all your workspaces from a single tab that exists in both your master on-premises Relativity instance and your satellite RelativityOne instance in the cloud. See Workspace Portal.
  3. After installing Workspace Portal, you can set up the Relativity User and Group Synchronization application. See Relativity User and Group Synchronization.

Note: Workspace Portal and User and Group Synchronization applications are only available for RelativityOne and on premise environments running Relativity 9.5.224.9 and above.

Single sign-on workflow (SSO)

Relativity and RelativityOne allow administrators to bridge the gap between on-premises and the cloud using single sign-on (SSO). Relativity supports two authentication protocols for single sign-on:

OpenID Connect is a modern authentication protocol that is gaining popularity. SAML2 is an older but widespread protocol that is common in the enterprise. With support for both protocols, Relativity can support a wide range of single sign-on providers. Single sign-on between Relativity and RelativityOne works by selecting an external identity provider that is shared between the two environments. Examples of identity providers include Azure Active Directory, Okta, Active Directory Federation Services, and even Google.

When single sign-on is configured, the Relativity login page displays a button for the external identity provider. The user attempting to log in simply clicks the button and is redirected to the identity provider’s login page. Upon successful login at the provider, the user is now authenticated and redirected back to Relativity.

Now suppose the user, who is authenticated to on-premises Relativity, wants to access RelativityOne. The user navigates to RelativityOne, perhaps via the Workspace Portal or Federated Instances menu. RelativityOne will automatically forward them to the identity provider login page. Because the user recently logged in, the provider will recognize the browser session and automatically authenticate the user. The user is finally redirected back to RelativityOne and can begin working. From the perspective of the user, she can access many environments while only having to log in once.

Summary of single sign-on solutions

Connecting an Active Directory domain with an external identity provider is a very common approach to single sign-on. In the following section, we review three approaches to using Active Directory for single sign-on with RelativityOne.

Note: You do not have to use Active Directory to take advantage of Relativity single sign-on. If your external identity provider has an up-to-date list of users, you can use that provider for single sign-on. You can even use multiple identity providers spread across different users. For a full description of Relativity’s single sign-on capabilities, consult the Authentication documentation.

Below is a summary of three SSO solutions. These solutions demonstrate some of the ways in which corporations can authenticate to RelativityOne using an existing Active Directory network. Each customer of RelativityOne will have specific network and security requirements that must be considered.

Note: There are many identity providers that can integrate with RelativityOne — too many to list in this document. We encourage you to carefully research the available options before selecting a single sign-on approach.

  • Azure AD Connect - Azure AD Connect is a free tool from Microsoft that lets enterprise customers sync their local Active Directory accounts to the Azure cloud. Administrators can enable single sign-on with a minimal amount of time and infrastructure. Azure AD Connect is installed in the local data center. A synchronization agent runs on the local network, continually pushing changes to Azure Active Directory. Both user accounts and passwords are synchronized to the cloud. Administrators can control which local users are synchronized and how much data is shared with the cloud. See Azure Hybrid identity documentation and review the information on AD Connect.
  • Active Directory Federation Services - Active Directory Federation Services (ADFS) is a service built into Microsoft Windows Server that enables single sign-on. ADFS acts as an external identity provider for Relativity, allowing users to authenticate to the local Active Directory network whether inside or outside the office.
    The ADFS server is installed as a Windows component, connected to the local Active Directory network, and exposed to the internet through the corporate firewall. The public URL to the ADFS server is then configured in Azure Active Directory. RelativityOne is configured to trust Azure Active Directory, and on-premises Relativity is configured to use Integrated Authentication from the local network.
    When a user navigates to RelativityOne, they are automatically redirected first to Azure Active Directory and then to the ADFS server (in this scenario, Azure acts as a pass-thru for authentication). Once the user is redirected to the ADFS server, one of two events will occur. If the user is accessing RelativityOne from inside the corporate network, ADFS will detect that fact and automatically authenticate the user. If the user is accessing RelativityOne from outside the corporate network, a login page will be presented; the user then enters their local network credentials into the ADFS login page, is authenticated against the local Active Directory, and is finally redirected to RelativityOne to complete the login workflow.
  • Okta - Okta AD Integration is a paid tool that connects a local Active Directory network to the Okta cloud. Users can authenticate to Okta using their local AD credentials. The Okta solution works by installing an agent on the local network. This agent securely connects to Okta and listens for authentication requests. To sign in to RelativityOne, users first navigate to the Okta portal. When a user authenticates to the Okta cloud, an authentication request is sent to the on-premises agent. The agent then forwards the request in real-time to the local Active Directory domain controller.
    Note that Okta also supports password syncing similar Azure AD Connect. Okta has many useful products for corporate identity and access management. See Okta SSO documentation for more information.

The following table summarizes some advantages and drawbacks for each of the three presented solutions.

Solution Advantages Drawbacks

Azure AD Connect

 

  • Simple installation and configuration.
  • No changes are needed to the corporate firewall.
  • Azure Active Directory is self-service and easy to get started.
  • User credentials (password hashes) are replicated to Azure Active Directory. Although Microsoft is a secure, well-known identity provider, some organizations may prefer to keep their passwords within the corporate firewall.
  • Note that while the Azure AD Connect tool is free, the subscription to Azure Active Directory is a paid service. Costs will depend on the number of users and the volume of authentication requests.

Active Directory Federation Services

 

  • User credentials never leave the local network.
  • Automatic (no-prompt) login for RelativityOne users on the local network.
  • Many enterprises already use ADFS.
  • More complex to configure and maintain.
  • ADFS must be exposed to the internet. This requires careful firewall planning and monitoring of the ADFS server. Use of a DMZ at the firewall is recommended.

Okta

 

  • Simple installation and configuration.
  • User credentials never leave the local network.
  • No changes needed to the corporate firewall.
  • Because the Okta agent continually connects to the Okta cloud, the corporate internet connection must be highly-available.
  • A disruption in internet service will prevent users from authenticating to RelativityOne because the Okta cloud will not be able to communicate with the on-premises Okta agent.

Setting up single sign-on in Relativity

Note: System admins must assign users at least one authentication method in order for users to log in.

To create and to assign methods, follow these steps.

  1. Create authentication providers. Authentication Providers are instances of an authentication provider type. Each provider type that you plan to use requires creating an instance of that type. See Creating authentication providers for an overview of authentication types or see the following commonly used examples to create and configure your authentication provider with Relativity.
  2. Assign a login method to individual users. You assign an authentication method to each user for them to log in with. Each user must have at least one authentication method in order for them to log in but you may assign multiple methods. See Managing user authentication methods.
  3. Note: To utilize Workspace Portal and User and Group Synchronization applications fully, you must configure SSO authentication for users in both your master and duplicate instance.