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
- Single sign on across instances (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:
We recommend the following workflow when setting up the Relativity hybrid model:
- 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.
- Set up and install Workspace Portal to your Relativity Server instances in order to view all your workspaces from a single tab that exists in both your master Relativity instance and your satellite RelativityOne instances.
- Set up the Relativity User and Group Synchronization application. See Relativity User and Group Synchronization.
Note: The User and Group Synchronization applications is only available for RelativityOne and on premise environments running Relativity 126.96.36.199 and above.
Note: Workspace Portal is only available for on premise environments running Relativity 188.8.131.52 and above.
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 - use this protocol if you plan to connect multiple instances
- SAML 2.0 - this protocol is not compatible with connecting multiple instances
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
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
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.
Azure AD Connect
Active Directory Federation Services
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.
- 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 providersfor an overview of authentication types or see the following commonly used examples to create and configure your authentication provider with Relativity.
- 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.
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.