

Relativity uses several industry-standard technologies, enabling versatile authentication options. It supports local, such as password related, or external, such as 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.
If you are upgrading from a prior version of Relativity, there are some important differences to be aware of. See the following page:
Review the following sections to learn more about the authentication methods, the object model, and the permissions model supported by Relativity:
Relativity supports the following authentication mechanisms.
In addition to the above protocols, Relativity has the following additional authentication features:
Relativity provides several tabs or object types that are used to configure authentication. By combining these object types, the system admin is able to control the Relativity login page and authentication options for the users in the environment.
Authentication Provider Type. Each authentication protocol is represented by an Authentication Provider Type object. You can navigate to the Authentication Provider Type tab in Home mode to see all of the environment's protocols and whether they are enabled or not. In Relativity you can disable specific Provider Types that you do not intend to use in your environment. As a best practice you should disable any Provider Types that will not be used.
Note: Users log in to the Relativity Desktop Client (RDC) with the same provider method as they have with Relativity. The RDC supports most Relativity authentication providers, such as password, Integrated Authentication, and OpenID Connect, by displaying the Relativity login page within the RDC as a dialog window. The only provider that does not work with the RDC is SAML because the Relativity’s IdP-initiated SAML does not display the Relativity login page directly.
Authentication Provider. Authentication Providers allow you to configure the specific settings for a login protocol. For example, you can add the Password Provider to your environment to set minimum and maximum password length, password history settings, and more. Some protocols have multiple configuration options, while others have very few. Every instance of Relativity has Default Password
You can add OpenID Connect and SAML 2.0 external identity providers. Unlike the previous five protocols, you can have as many of these Providers as you wish in an environment.
Login Method. The AuthenticationData field on the User page has been replaced with the Login Method associated list. Users can have one or more Login method objects that binds that user to a particular Authentication Provider. For example, if you have a Password Authentication Provider in the environment, the Password Login Method contains the specific password for a given user. If you have Azure Active Directory configured as a Provider, each user's AAD subject identifier would be stored in an associated Login method.
User. The User object still holds the TrustedIPs setting. By setting a TrustedIP for a user, that user will only be able to authenticate with Relativity from that IP range. All other authentication-related fields have been moved from the User object to the Provider and Method objects.
These default object permissions are recommended for managing user 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 Types are Relativity dynamic object (RDOs) types that permit authentication methods for users to log in with. You cannot add or delete provider types, only enable or disable them. By default, provider types are enabled. You enable methods in two places: the authentication provider type tab and the authentication providers tab. To be enabled, the method has to be enabled in both places.
To enable or disable an authentication provider type:
Authentication providers are instances of authentication provider types. You create only the instances of the provider types you need. For example, if you plan to support only password methods, you only have to create an authentication provider for passwords, and not for any other provider types.
Note: Adding a new authentication provider of the same type overwrites the existing ones of the same type.
You may only have one instance of each provider type. The exceptions are for OpenID Provider and SAML 2.0 provided types. You can have multiple instances of those if they have different names.
To create an Authentication Provider:
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.
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 cannot 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 is not available for the user.
Authentication providers that do not require additional settings:
You may need to set RSA configuration files to the web server prior to users logging in with this method.
Authentication providers that require additional settings:
Note: The following non-alpha-numeric characters are not allowed: \, ", <, >, £ in passwords.
The example below illustrates the relationship between the two settings and the login screen.
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).
(Click to expand.)
Click App registrations.
(Click to expand.)
(Click to expand.)
Copy the Application (client) ID.
(Click to expand.)
(Click to expand.)
Trim the oauth2/v2.0/authorize from the URL. For example:
https://login.microsoftonline.com/8a3fa923-3223-4978-9d4d-fa012e19898b/oauth2/authorize https://login.microsoftonline.com/8a3fa923-3223-4978-9d4d-fa012e19898b/
Review the following list of settings that display on the Authentication Provider form. You can configure or update these settings based on your authentication needs.
The identity provider responds with the claims associated with the scopes that you request. In other words, the scopes translate into claims that you can use.
The identity provider sends an identity token to you, which contains the claims for your selected scopes. When you request only the OpenID scope, then sub is used as the claim type. It often represents a unique identifier for the user within your system. If you are using Azure AD, then see Microsoft identity platform ID tokens for a full list of token identifiers.
Log in to Azure AD and navigate to the application you created earlier, if you have closed the window.
Click Authentication.
(Click to expand.)
Add your Redirect URL from the Relativity Authentication Provider.
Note: Leave the Type as Web.
Complete the scenario that matches the value you selected for OAuth2 Flow.
Click Certificates & Secrets.
Click New client secret.
Click Add.
Copy the client secret value.
Navigate back to the Authentication Provider in Relativity.
Click Edit.
Paste the value for Client Secret with the value from step 4.
Click Save.
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:
To configure an OpenID Connect provider for Relativity:
After you save the OAuth2 client, note the generated value of the Client Id. This is required to set up the authentication provider in the secondary instance.
You have now configured a Relativity environment to serve as an authentication provider for another Relativity instance.
SAML is an open-standard format for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). Relativity uses SAML assertions (tokens) to verify the users mapped to the identity provider.
You can use Relativity with any SAML 2.0-compliant IdP, such as Centrify, Okta, Microsoft Active Directory Federation Service (ADFS), or OneLogin.
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 protects 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.
The following sections provides the guidelines for integrating Relativity with Okta and ADFS.
This is an example of configuring Okta.
Initial configuration:
Note: Audience URI is case-sensitive. Specifying /relativity instead of /Relativity can break your authentication.
Next, set up the SAML 2.0 authentication provider in Relativity:
You have now set up your Relativity instance to list for SAML 2.0 assertions at a given endpoint on your server, the Redirect URL.
Next, finish setting up the SAML IdP in Okta:
You have now configured Okta to send SAML 2.0 assertions to your Relativity instance, and Relativity is set up to verify the SAML assertions.
Note: You must also assign Okta users to the SAML application, and then map the users to SAML login method in Relativity. When configuring the login method, you must specify the user's email in the SAML2 Subject field, if you select Email as the application user name in Okta. For more information, see Managing user authentication methods.
You can also configure ADFS as a SAML 2.0 authentication provider for Relativity.
Note these terminology difference between Relativity and ADFS:
ADFS | ||
---|---|---|
Audience | Relying Party Identifiers | https://relativity.example.com/Relativity |
Redirect URL | End-Point URL | https://relativity.example.com/Relativity/Identity/<random string> |
Issuer URL | Services Trust End-Point (SAML) | http://<adfs-service>/adfs/services/trust |
SAML Subject Name | Claim Type | Name ID, E-Mail Address, UPN. Leave blank in Relativity SAML Provider configuration. |
n/a | Claim Rules | Incoming, Transformation, Outgoing Claim Rules. See below. |
When setting up claim rules, you must send Name ID as default claim type for Relativity. Use these guidelines:
Why was this not helpful?
Check one that applies.
Thank you for your feedback.
Want to tell us more?
Great!