Authentication

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 topic contains the following sections:

If you are upgrading from a prior version of Relativity, there are some important differences to be aware of. See the following page:

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 don't require additional settings:

  • Default Integrated Authentication provider
  • Default Active Directory provider
  • Default RSA provider

    You may need to set RSA configuration files to the web server prior to users logging in with this method. See RSA configuration for additional details.

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).

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 Authentication and Authentication.