Organization Admin: Single Sign-On

Avatar
Everlaw Support
Follow

 

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

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.

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. 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 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. 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.
  • 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 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
  • 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.
  • Choose Issuance Authorization Rules: Select “Permit all users to access this relying party.”
  • Click through the next two screens; on the Finish screen, select the checkbox to open the Edit Claim Rules dialog.
  • Select Add Rule in the bottom left of the dialog.
  • Under “Claim rule template,” select “Send LDAP Attributes as Claims” and continue to the next page.
  • From the LDAP Attribute and Outgoing Claim Type columns, select E-Mail Address(es) and then select OK.
  • 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:

    • Vavigate 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

    You may see an error message on the login screen after attempting to SSO. Below is a list of common issues.

    • 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 SAM LResponse 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 a 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.

    Have more questions? Submit a request

    0 Comments

    Article is closed for comments.