Relativity uses several industry-standard technologies, enabling versatile authentication options. It supports local (such as password related) or external (such as smart cards, or external identification providers) authentication methods. You can add and enable each type individually, as well as assigning at least one, and in some instances multiple methods, for each user.

This page contains the following information:

Authentication overview

Review the following sections to learn more about the authentication methods, the object model, and the permissions model supported by Relativity:

Configuring Relativity authentication

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.

Authentication provider settings

Authentication providers may have associated settings that you can configure and applies to all instances of that authentication provider.

Each provider instance has at least one setting: Enabled. If set to Yes, this authentication provider is available. If No, you can't use this method to log in with. To enable an instance both this setting and the Enabled for the Authentication Provider must be set to Yes. If either one is set to No, that method isn't available for the user.

Authentication providers that require additional settings:

  • Default Password provider
  • Default smart card provider
  • OpenID Connect with Microsoft Azure AD - see OpenID Connect with Microsoft Azure AD.
  • SAML 2.0 provider - see SAML 2.0 provider.

OpenID Connect with Microsoft Azure AD

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. Clients can verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User. You can use any provider that supports the OpenID Connect protocol. The examples here use Microsoft Azure AD.

Note: OpenID Connect 1.0 authentication providers are not compatible with Relativity User Load Balancing (RULB).

Using Relativity as an OpenID Connect Provider

Relativity can be set up as an OpenID Connect authentication provider to log users into a different Relativity instance. For example you can set up a Relativity Server environment (primary instance) to act as authentication provider for a RelativityOne cloud instance (secondary instance).

Before you begin:

  • Ensure that the primary instance is set up to use HTTPS.
  • Verify that the secondary instance can resolve the host address of the primary instance.
  • Confirm that the authenticated users are defined in both systems.

SAML 2.0 provider

SAML is an open-standard format for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). As a service provider, Relativity supports SAML IdP-initiated single sign-on (SSO). SP-initiated SSO is not supported. Relativity uses SAML assertions (tokens) to verify the users mapped to the identity provider.

SAML assertions contain information on the identity of the individual who has logged in. Assertions also contain the identity provider issuing the assertion, known in Relativity as the Issuer URL. Each Assertion is typically prepared for a specific receiver, known as the Audience. Assertion protect this information by cryptography signing it. An Assertion is only valid if it is from a known Issuer URL to the expected Audience and correctly signed.

Note: SAML assertions must be cryptographically signed for Relativity to verify their authenticity. Make sure your SAML IdP is configured accordingly.

You can use Relativity with any SAML 2.0-compliant IdP, such as Centrify, Okta, Microsoft Active Directory Federation Service (ADFS), or OneLogin.

Note: SAML 2.0 authentication providers are not compatible with Relativity User Load Balancing (RULB).

The following sections provides the guidelines for integrating Relativity with Okta and ADFS.