SSO stands for Single-Sign-on, a session and user authentication service that permits users to use one set of login credentials to access all of their SaaS applications. The user can sign into the LawVu application using the corporate username and password credentials.

SAML is an extensible markup language (XML) standard that facilitates the exchange of user authentication and authorisation data across secure domains. SAML-based SSO services involve communications among the user (You), an identity provider (Client’s IT system) that maintains a user directory, and a service provider (LawVu).
​

System for Cross-domain Identity Management (SCIM) is a standard for automating the exchange of user identity information between identity domains, or IT systems. It’s specification is designed to make managing user identities in cloud-based applications and services easier. Once setup the SCIM endpoints on both sites can exchange information to create, read, update and delete users in the cloud application.
​

Just in Time (JIT) Provisioning is a SAML protocol-based method that is used to create users the first time they log in to an application via an identity provider. This method can be used if SCIM is not available but there are certain limitations with JIT compared to SCIM.

Account automation (creation and removal) is not possible with JIT. In order to create an account, the user must successfully log in to LawVu. Additionally, the legal team administrator has the responsibility of disabling a user's account within the LawVu platform to prevent it from being assigned as a resource in the future. As long as the user's account remains active in LawVu, it can be assigned to contracts and matters.

Please note that there is a difference between the login initiated from the client’s system (identity provider) and the login initiated from the Lawvu login screen (service provider). The main difference between identity-provider-initiated SSO and service-provider-initiated SSO is where users start the login process. IdP-initiated login requests start in the identity provider (Office365/OKTA etc.), whereas SP-initiated login requests begin in the application users want to access.

If a user is already logged into their corporate identity provider (Office365, OKTA, etc.) and is presented with a list of application icons, then in most cases, no further login prompt will be presented to the client. The LawVu homepage will simply appear once selected.

If the user initiates the login from the LawVu login page (https://go.lawvu.com) they will be required to enter their email address, which triggers the system to forward the login request to their corporate identity provider (O365, OKTA, OneLogin, etc.).

The LawVu platform facilitates the configuration of multiple identity providers, where each configured domain directs users to the corresponding identity provider's login points. Any existing multi-factor authentication (MFA) details implemented by each provider will be utilised during the authentication process. The company's platform does not intervene with these MFA procedures; instead, it seamlessly hands over authentication to each domain's SAML authentication and their respective multi-factor authentication setups.

SAML 2.0 for user authentication

SCIM 2.0 for user provisioning (automatic user creation, update and deactivation)

IMPORTANT: If you cannot achieve the automatic creation and deactivation of users in your LawVu account by utilising SCIM provisioning, our technical implementation team can assist by supporting Just in Time (JIT) user provisioning through SAML claims.

OKTA clients: Please ensure your OKTA instance includes the Lifecycle management license to support SCIM.

While we've had successful SSO configurations with clients using an on-prem ADFS server, we want to inform you that LawVu does not officially support ADFS. However, our team is more than willing to provide the necessary SAML details to your IT department for configuration and testing purposes.

We may be able to support custom solutions for clients provided they adhere to the industry standards of SAML2.0 and SCIM2.0.

In this mode, SSO is fully disabled, and only LawVu platform accounts are permitted to log in, bypassing any SSO settings. If an account was previously synchronised and SSO is subsequently disabled, the user must reset their password to access LawVu.

This mode enables both SSO and non-SSO accounts to log in. Accounts that have received an SSO flag through SCIM or Just-in-Time provisioning will trigger the SSO flow. Accounts without the flag will be prompted for a platform username and password.

The enforced mode offers the highest level of security by requiring login through the configured identity provider. It is recommended after the configuration is finalized. Non-SSO accounts are locked out in this mode.

To increase security and avoid malicious access, every aspect of SSO implementation must be coupled with identity governance. LawVu recommends using two-factor authentication (2FA) or multifactor authentication (MFA) with SSO to improve security. Please talk to your IT to check if your organization can use or already uses 2FA/MFA.

Please be advised that the integration of Single Sign-On (SSO) entails the utilization of your company's identity provider for the administration of Multi-Factor Authentication (MFA/2FA), superseding the functionality of the LawVu platform in this regard.

Please ensure the user account has a unique ID set inside your identity platform and below mandatory SAML claims are all configured. It is required for the JIT process to uniquely identify the user account, which requires the uniqueID to be part of the SAML request so any changes to email or name can be accepted by our endpoint.

Please ensure you have provided all domains for whitelisting. If a domain is not whitelisted in our system, then login for this account with the unlisted domain will fail. Please contact our support team to whitelist domains.

Furthermore, please ensure the user's account has been authorised to access the LawVu application via your Single Sign-On (SSO) solution. In situations where Just-In-Time (JIT) is employed, and the user's account in LawVu remains active despite not being granted access through SSO, such scenarios should be considered.

If your organization employs Azure Active Directory (Azure AD) for user authentication via Single Sign-On (SSO), there may be a potential misalignment between the users' User Principal Names (UPN) and primary email addresses. Refer to our AzureAD guide for steps to address and mitigate such issues.

If your organisation removes a user account from your identity provider and then creates a new account for that user, the unique ID will change. The SCIM protocol stores this unique ID in our database, and a change is not permitted. In this case, you'll need to contact our support to manually remove this unique ID from our system to allow a full update on this user's account. You might encounter entries in your SCIM log that refer to "external ID change not allowed" or similar messages.

LawVu’s SSO technical capabilities are very flexible, and the below questions will help your I.T. team better understand the requirements and supported features.

Does LawVu support authentication through SAML 2.0 using an Identity Provider such as Okta/Azure/OneLogin?

Yes. LawVu provides support for popular identity providers such as AzureAD (Office365), OKTA, OneLogin, Google, Sailpoint, and JumpCloud. It's worth noting that LawVu's support is not restricted to the mentioned providers only, as any IDP that supports SAML2.0 and SCIM2.0 can be supported by LawVu.

OKTA clients: please ensure your OKTA license includes the Lifecycle management to utilize SCIM user provisioning.

Does LawVu provide instructions on how to configure SSO on the platform?

Yes, LawVu can provide guides for AzureAD, OKTA, OneLogin and a generic guide for compatible SAML & SCIM configurations.

Can the LawVu platform work in a mixed/hybrid mode allowing users to be able to sign in with and without SSO authentication?

Yes, LawVu has the capability to facilitate a hybrid/mixed configuration, which permits the utilisation of both Single Sign-On (SSO) and LawVu-stored usernames/passwords for authentication into the LawVu system. It's essential to note that configuring SSO in a hybrid mode is not advisable. However, there could be specific scenarios where hybrid access is necessary and requested by the client. Should such a situation arise, the technical team at LawVu can activate hybrid mode for your account.

Opting for hybrid mode allows local accounts to log in while bypassing your SSO identity provider. It poses the risk of your IT department having no control over local LawVu users, resulting in two sources for user control access for your organisation. It's essential to highlight that LawVu does not oversee these accounts either. Once a local user account is created in LawVu, it remains active even if the user leaves their own organisation, and the only way to prevent access is to disable the account in LawVu manually. Thus, the client’s LawVu administrator ensures that non-SSO accounts within LawVu are deactivated if not used.

In this case, a hybrid mode approach may be required, but it is highly recommended to utilise our Vendor Spend Management in this situation to ensure the highest level of security and keep your Single Sign-On (SSO) enforced. By using the Vendor Spend Management, you will also have complete control over granting access to your individual matters and contracts to collaborate.

Highlighting the security risk:

Opting for hybrid mode allows local accounts to log in while bypassing your SSO identity provider. It poses the risk of your IT department having no control over local LawVu users, resulting in two sources for user control access for your organisation. It's essential to highlight that LawVu does not oversee these accounts either. Once a local user account is created in LawVu, it remains active even if the user leaves their own organisation, and the only way to prevent access is to disable the account in LawVu manually. Thus, the client’s LawVu administrator ensures that non-SSO accounts within LawVu are deactivated if not used.

Does LawVu support SCIM 2.0 for user provisioning?

Yes, this standard is fully supported.

Please be advised that the integration of Single Sign-On (SSO) entails the utilisation of your company's identity provider for the administration of Multi-Factor Authentication (MFA/2FA), superseding the functionality of the LawVu platform in this regard. Once SSO has been enabled, any MFA/2FA requests are handled by your identity provider and not the LawVu platform.

Does LawVu support permission-based role provisioning through SCIM?

Yes, LawVu supports role provisioning through AzureAD and OKTA.

Please note that enabling SCIM role provisioning will disable the ability to change and assign roles within the LawVu platform. The legal team member with administrative access usually does this task manually in LawVu. Please liaise with your legal team and clarify how roles should be assigned in LawVu before configuring the next step.

Yes, this standard is supported. Please note that with JIT there are certain limitations. Even though it is possible to create users through JIT provisioning after a successful login, it is not possible to disable a user’s account in LawVu via JIT.

Obsolete accounts must be manually disabled by the client's administrator within LawVu under the user management section. If this is delayed, there can be confusion. Once a user's account has been disabled by IT in the company's system, then login to LawVu will be denied. However, the person who left will still have an active account in LawVu and will also appear as an assignable resource under Matters and Contracts.

Does LawVu support multiple domains on the same Lawvu instance?

Yes, LawVu supports multiple login domains on the same account. Please ensure that, with SSO in place, all required domains are whitelisted by the LawVu technician.

Does LawVu support multiple identity providers under the same LawVu instance?

Yes, LawVu supports multiple IDPs under the same account. For instance, the LawVu team can configure user provisioning and login from Office365 and OKTA under the same LawVu account. This is sometimes required if the corporate organisation has multiple providers from different regions or if a mixed user login is needed after a merger.

Do I have to enter my email and password again to access LawVu?

That depends on the login flow. Please see the above paragraph about login flows.

Can I still manage users in LawVu with SSO in place?

No. Once SSO is implemented, all users are centrally managed by your organisation's IT team through a secure system, which ensures a single point of control over user access within your organisation.

No, the SSO login process through Outlook or any other add-in is precisely the same as through the website or your identity provider.

No. Adding attributes is currently not supported.
​

When does the application disable or revoke user access?

Once a user is removed from the client's identity provider SSO group through the utilisation of the SCIM protocol, they are marked for deactivation in Lawvu. Please note the above limitations if JIT is used, where a user cannot be disabled in Lawvu.

​Following de-provisioning or manual disabling of a user's account, are users retained within the system?

Users are maintained in the system to preserve a historical record of their participation in matters and/or contracts. However, they are disabled to prevent future association with matters and/or contracts.

Before you report a problem, can you please check provided guides and help articles. If the issue continues, then please reach out to our support team.