Organization Admin: Single Sign-On

 

Table of Contents

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). They will not have to maintain a separate username and password for Everlaw.

Everlaw SSO uses the SAML 2.0 protocol. 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 Security Assertion Markup Language (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.

saml2.png

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

saml1.png

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.

You should then be able to upload the Everlaw metadata in the directory service’s settings page (different directory services may have different requirements).

You may additionally need to register Everlaw's Entity ID and ACS URL with your identity provider. The relevant IDs and URLs are as follows:

Everlaw US:

Entity ID: everlaw.com:us-web
ACS URL:  https://app.everlaw.com/saml/SSO

Everlaw AUS:

Entity ID: everlaw.com:au-web
ACS URL: https://app.everlaw.com.au/saml/SSO

Everlaw EU:

Entity ID: everlaw.com:eu-web
ACS URL: https://app.everlaw.eu/saml/SSO

Everlaw UK:

Entity ID: everlaw.com:uk-web
ACS URL:  https://app.everlaw.co.uk/saml/SSO

Everlaw CAN:

Entity ID: everlaw.com:ca-web
ACS URL: https://app.everlaw.ca/saml/SSO

Return to table of contents

Single sign-on and user experience

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

If single sign-on is disabled:

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

If you enable single sign-on:

  • Users 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.
  • Users will be able to change their passwords and toggle MFA authentication from their profile pages.
  • Users will be able to request password resets.
  • Users 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:

  • Users will not be able to log into Everlaw using their passwords, nor will they create a password when they are invited to Everlaw. Instead, they will be required to use single sign-on.
  • Users will be able to bypass MFA authentication upon login, if applicable.
  • Users will not be able to change their passwords and toggle MFA authentication from their profile pages.
  • Users will not be able to request password resets.
  • If you disable single sign-on, users will need to create an Everlaw password.
  • Users who belong to multiple organizations will need to authenticate using your SSO when accessing projects owned by your organization
  • Users 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 user 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.

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 URL: Select “Enable Support for the SAML 2.0 WebSSO protocol” and provide one of the following URLs, according to your instance:
  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.

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

What to do if you see an "Error validating SAML" message

You may see a message that says "The SAML request contained a NameIDPolicy that was not satisfied by the issued token." It's likely that your identity provider is not set up correctly. The most common configuration mistakes are having an incorrect ACS URL or not mapping NameID to EmailAddress. 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. 

Have more questions? Submit a request

0 Comments

Article is closed for comments.