Table of Contents

• Enabling single sign-on using directory service metadata
• Providing your directory service with Everlaw metadata
• Single sign-on and user experience
  • Which users are affected by your SSO authentication setting?
• Configuring single sign-on with ADFS
• Configuring single sign-on with Okta
  • Configuration steps for Okta manual configuration
  • Configuration steps for Okta App Integration
• Troubleshooting SSO login errors

Organization Administrators can configure single sign-on (SSO) for users associated with the organization. Single sign-on enables users to log into Everlaw via their existing directory service (e.g., GSuite, Active Directory, LDAP).

Everlaw SSO uses the SAML 2.0 protocol. Security Assertion Markup Language (SAML) is widely supported. If a platform/program supports SAML, it can be used with Everlaw. 

For example, Everlaw can integrate these platforms (among many others):

• Active Directory (a.k.a. ADFS)
• Azure AD
• Google (a.k.a. GMail, GSuite)
• Okta
• Ping
• Centrify

Everlaw does not support OAuth or OpenID. 

Return to table of contents

Enabling single sign-on using directory service metadata

To enable single sign-on, you first have to download the IDP metadata for your directory service. This is an XML document that tells Everlaw how to communicate with your system. There should be a download link in your directory service’s support center or SAML control panel. This file allows your identity provider (in this case, your directory service) to communicate with your service provider (in this case, Everlaw) to establish a connection so that you can set up single sign-on.

You’ll then upload this metadata to Everlaw by clicking “Upload” on the Security Settings tab of your organization admin dashboard, under SAML Single Sign-On.

Everlaw will validate the metadata once it is uploaded. If the original file cannot be validated, you may upload another version of the file. Once the file is validated, you will be able to choose to enable or require single sign-on on an organization-wide basis. Requiring single sign-on will disable Everlaw’s normal password-based login process for the organization. It is recommended that you initially set the authentication setting to "Optional". Don't select "Required" until you've tested SSO login and know that it is working; otherwise, you risk getting locked out of your account!

If your identity provider has multifactor authentication (MFA), you can switch on "Bypass Everlaw multifactor authentication.”

For more information about the consequences of disabling, enabling, or requiring single sign-on, see the relevant section below.

Return to table of contents

Providing your directory service with Everlaw metadata

In order for SSO to function correctly, you will also need to supply your directory service with Everlaw service provider metadata. You can download this metadata in XML form by clicking “Download Everlaw service provider metadata,” under SAML Single Sign-On. This download link will appear after the IDP metadata has been uploaded.

You should then be able to upload the Everlaw metadata in the directory service’s settings page.

You may additionally need to register Everlaw's Entity ID and Assertion Consumer Service (ACS) URL with your identity provider. To find these values, open the Everlaw metadata file in a text editor.

To find the Entity ID, search for the “EntityDescriptor” element in the xml and locate its “entityID” field. The Entity ID is the value of this field without the double quotes. It should look similar to this: everlaw.com:us-web

To find the ACS URL, search for the “AssertionConsumerService” element in the xml and locate its “Location” field. The ACS URL is the entire URL without the double quotes. It should look similar to this: https://app.everlaw/com/login/saml2/sso/aHR0cHM6Ly9ldmVybGF3LmNvbS9leGFtcGxlYWJjZA

Return to table of contents

Single sign-on and user experience

Enabling or requiring single sign-on affects organization member experience at the time of login, as well as organization members’ ability to change their profile settings.

If single sign-on is disabled:

• Organization members will need to sign into Everlaw using their passwords. Organization members will not be able to log into Everlaw using single sign-on, and will have to authenticate using MFA, if applicable.
• Organization members will be able to change their passwords and toggle MFA authentication from their profile pages.
• Organization members will be able to request password resets.

If you enable single sign-on:

• Organizations members who have been authenticated by your identity provider will be able to log into Everlaw with single sign-on and bypass MFA authentication, if applicable. They can also choose to log in using their Everlaw password.
• Organization members will be able to change their passwords and toggle MFA authentication from their profile pages.
• Organization members will be able to request password resets.
• Organization members who belong to multiple organizations will be able to access projects owned by your organization as long as they have authenticated their account in any way.

If you require single sign-on:

• Organization members will not be able to log into Everlaw using their passwords. Instead, they will be required to use single sign-on.
• Organization members will be able to bypass MFA authentication upon login, if applicable.
• Organization members will not be able to change their passwords and toggle MFA authentication from their profile pages.
• Organization members will not be able to request password resets.
• Organization members who belong to multiple organizations will need to authenticate using your SSO when accessing projects owned by your organization
• Organization members cannot be members of multiple organizations that both require SSO and log in with SSO to each one. Everlaw currently doesn't support this SSO combination. Please note users do not become 'members' of an organization automatically when they are invited to a project owned by that organization. Users are only listed as "members" on the organization either when they have an email domain associated with the org, or the organization admin manually added them to the organization as a user. If a single Everlaw user needs to use the SSO method of multiple organizations, there are two options:

  • Create a new Everlaw account with a different email address domain that won't automatically be associated to the other organization the user needs to use SSO for login. 

  • An organization admin can also remove the user from the organization's "Users" tab (thereby removing them as an official member of their org), and instead be re-invited to the organization's project(s).

For an account that has single sign-on enabled, the organization member can either log in using SSO, by clicking the blue “Log in via [organization name] organization” button, or with their password, by clicking the blue “Log in with password” button. The option to log in through SSO will not appear for users whose organizations do not have SSO enabled, and the option to log in with a password will not appear for users whose organizations require SSO.

Which users are affected by your SSO authentication setting?

Enabling or requiring single sign-on affects only users who are “members” of the organization. This means 

• When SSO is enabled: only organization members can authenticate using your identity provider 
• When SSO is required: only organization members will be required to authenticate using your identity provider

Organization members are displayed on the Users table on the Projects & Users tab of the organization admin page.

 A user can be added as a member of your organization in one of two ways:

1. An organization admin invites a user to the organization by clicking the “Add user” button above the user table, and the user accepts the organization invitation. 
2. A user has a domain associated with the organization and is automatically added as an organization “member.”

Please see our organization and project administration article for more information about adding a user to your organization and associated domain.

Return to table of contents

Configuring single sign-on with ADFS 

The following instructions provide an overview of setting up compatibility between Everlaw single sign-on and your Active Directory. 

To add a Relying Party Trust, follow these steps on each screen of the Add Relying Party Trust Wizard:

1. Select Data Source: Choose “Enter data about the relying party manually.”
2. Specify Display Name: “Everlaw” or similar.
3. Choose Profile: Select ADFS FS radio button.
4. Configure Certificate: No action is necessary here.
5. Configure ACS URL: Select “Enable Support for the SAML 2.0 WebSSO protocol” and provide the ACS URL. To find the ACS URL refer to the instructions in the “Providing your directory service with Everlaw metadata” section above
6. Configure Identifiers: Provide one of the following URLs, according to your instance:
• Everlaw US: everlaw.com:us-web
• Everlaw AUS: everlaw.com:au-web
• Everlaw EU: everlaw.com:eu-web
• Everlaw UK: everlaw.com:uk-web
• Everlaw CAN: everlaw.com:ca-web
7. Configure Multifactor Authentication: Depending on the needs of your organization, you may or may not need to complete this step. Please see your system administrator if you are unsure about configuring multifactor authentication.
8. Choose Issuance Authorization Rules: Select “Permit all users to access this relying party.”
9. Click through the next two screens; on the Finish screen, select the checkbox to open the Edit Claim Rules dialog.
10. Select Add Rule in the bottom left of the dialog.
11. Under “Claim rule template,” select “Send LDAP Attributes as Claims” and continue to the next page.
12. From the LDAP Attribute and Outgoing Claim Type columns, select E-Mail Address(es) and then select OK.
13. Click OK, and then OK again to close the dialog.

 

💡 Tip: Confirm that your identity provider is set up correctly by checking that NameID is mapped to EmailAddress.

 

If you are encrypting the Assertions, the Response must be signed. Therefore, in PowerShell, check if your relying party trust for Everlaw has “SamlResponseSignature” configured to “MessageAndAssertion”. by running the command:

Get-AdfsRelyingPartyTrust -name “Everlaw”

Replace "Everlaw" with the name you chose to name Everlaw's relying party trust.

To encrypt both the Message and Assertion, you can run the command:

Set-AdfsRelyingPartyTrust -TargetName “Everlaw” -SamlResponseSignature “MessageAndAssertion”

To adjust the ADFS trust settings, select your new Relying Party Trust and follow these steps:

1. Click Actions, and then Properties, from the right-hand side.
2. Select Advanced. Under Secure Hash Algorithm, specify SHA-256 and click OK.

If you have further questions about single sign-on through ADFS, contact support@everlaw.com or your office’s IT team.

 

Return to table of contents

Configuring single sign-on with Okta

You can configure SAML either through Okta’s manual SAML setup or through the Everlaw App Integration. The Everlaw App Integration only supports:

• Everlaw US
• Everlaw AUS
• Everlaw EU
• Everlaw CAN
  

Configuration steps for Okta Manual Configuration:

• Navigate to the Okta’s Applications panel and click on “Create App Integration”. Search for “Everlaw”.
• Select SAML 2.0, fill out the General settings form and click “Next”.
• In the SAML Settings tab, you will need to do the following things:
  • Name ID format should be set to “EmailAddress”
  • Input a temporary placeholder for the Single sign-on URL
  • Input a temporary placeholder for the Audience URI

• Go to the “Sign on'' section of the configuration page and scroll down to “SAML Signing Certificates”. Find the certificate that has an “Active” status, select the Actions dropdown, and click “View Idp metadata”. Save the metadata as an xml file by right clicking the page and selecting “Save as…”.

• Go to your Everlaw Organization Admin panel and upload the Okta metadata you just downloaded.

• Go to your Okta’s App configuration settings for Everlaw. Click on the “General” tab and click on the “Edit” button in the SAML settings section.
• Replace the Single Sign On URL with your Everlaw ACS URL
  • Check “Use this for Recipient URL and Destination URL”
• Replace the Audience Restriction with your Everlaw Entity ID
• (See the Providing your directory service with Everlaw metadata section for how to get the ACS URL and Entity ID)

Configuration steps for Okta App Integration:

• Navigate to the Okta’s Applications panel and click on “Browse App Catalog”. Search for “Everlaw”.
• Fill out the General settings form and click “Done”. Make sure you select the correct Environment for your Organization.
• Go to the “Sign on'' section of the configuration page and scroll down to “SAML Signing Certificates”. Find the certificate that has an “Active” status, select the Actions dropdown, and click “View Idp metadata”. Save the metadata as an xml file by right clicking the page and selecting “Save as…”.

 

• Go to your Everlaw Organization Admin panel and upload the Okta metadata you just downloaded.
• Click on “Download Everlaw service provider metadata” to download your Everlaw SP metadata.
• Go to your Okta’s App configuration settings for Everlaw. Click on the “Sign on” tab and click on the “Edit” button in the settings section.
• Under the “Advanced Sign-on Settings” section, fill in the “Customer ID” field with the hash value at the end of the ACS URL found in the Everlaw SP metadata.
  • The ACS URL is the Location value of the AssertionConsumerService element.

Supported features with Okta:

• IDP initiated login
• SP initiated login

Troubleshooting SSO login errors

You may see an error message on the login screen after attempting to SSO. 

• Make sure that your NameID is mapped to the Email Address (so that it can be unique)
• If you are having issues with the Okta Everlaw App Integration, please try the manual setup instead. (See instructions above)
• Double check that the correct metadata is uploaded to Everlaw and that the correct Everlaw SP metadata is uploaded to your directory service.
• If you re-upload a different metadata to Everlaw, you must re-download the Everlaw SP metadata.
• Ensure that the user attempting to log in is a member of the Organization with SAML configured.
• The NameID in the SAML Response must match the username of the Everlaw user.
• Make sure that your directory service settings are set to sign the SAML Response or all of the SAML Assertions.
• If you are encrypting the SAML Assertions, the SAML Response must be signed.
  • E.g. for ADFS, you can sign both the Response and Assertions in powershell with:
    • Set-AdfsRelyingPartyTrust -TargetName “Everlaw” -SamlResponseSignature “MessageAndAssertion”

Your session might enter a bad state when you get an SAML error. You might want to clear your cookies or try an incognito browser if all your configurations are correct but you are still running into issues.

You can reach out to support@everlaw.com if you experience this issue. Please include a screenshot and as much relevant information as you can about how you set up SSO.