SSO (SingleSignOn) Help Guide

IMPORTANT: Please note that our support team is not able to create user accounts on your behalf. With SSO in place, your company will have an internal workflow for creating new accounts and granting access to new staff.

During the implementation stage, you may still be able to invite users into the application. Your LawVu administrator will have the necessary permissions and tools to invite users into LawVu.

Please verify with your administrator that your LawVu account exists. Ensure you are using the correct email for login. Depending on the user creation method chosen by your IT department, account creation may take some time. Therefore, it's crucial to check with your LawVu admin and confirm that your account has been successfully created.

Please ensure you have provided all login 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.

It's possible that your certificate has expired. Typically, signing certificates have a lifespan of 3 years and must be renewed before expiration. If you're experiencing login issues potentially caused by an expired certificate, the first step is to check with your IT department, as they manage certificates and can verify the expiration. Once confirmed, provide the new certificate to our support team for updating. It is crucial to provide the certificate in the BASE64 format.

When communicating about certificates or sensitive information, ensure it's done from a secure email address that verifies your domain. For security reasons, our support team will not be able to process any updates that do not come from a registered email in the LawVu system.

The user account might not exist yet in LawVu when the user tries to log in. Please check your directory to see if an account exists with the correct username/email.

If your organisation 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 Name (UPN) and primary email address. Refer to the below guide extracted from our AzureAD guide for steps to address and mitigate such issues.

Please note: If you have a requirement to use the primary email address instead of the pre-configured UPN as the login then please follow this article.

Under Single-Sign-On and Attributes and Claims, please remove the below "user.mail" claim.

If your organization has Single Sign-On (SSO) in place, all password resets must be managed through your identity provider (e.g., O365, Okta, Google, etc.) and not through the LawVu platform.

Here's what you need to do:

With SSO enabled, password reset processes are handled within your identity provider's system. This means that the LawVu platform does not manage any password resets when SSO is in use.

If you need to reset your password, contact your IT department or refer to your organization's password reset policies.

It's important to follow your organization's security policies and procedures when resetting passwords or managing your account credentials.

With Single Sign-On (SSO) enabled, user invites are disabled within the LawVu platform. To add more users, please follow these steps:

Reach out to your IT department or system administrator to add new users to the LawVu platform.

User management, including adding new users, is now controlled through your identity provider (e.g., O365, Okta, Google, etc.) and not through LawVu.

The LawVu support team does not have access to your identity platform and is unfortunately unable to help. For further assistance, please contact your IT support team.

With SSO in place, all user updates including email addresses are handled through the SCIM provisioning system or during a successful login when JIT is utilized. Therefore, manual adjustments to accounts are generally unnecessary.

In rare cases, a manual email update may be required, but this should only be considered as a last resort.

Manually updating an email address can interfere with the automatic user provisioning process between your IDP and the LawVu endpoints, potentially causing further issues.

Before requesting an email change, ensure that all troubleshooting steps from this article below for SCIM and JIT have been thoroughly checked on your end.

While our support team can assist with manual changes, troubleshooting and identifying the root cause of the failed update is mandatory. If the underlying issue persists, provisioning will likely fail again in the next cycle, and a manual adjustment will only provide a temporary rather than a permanent solution.

The first step is to confirm that provisioning has indeed started and is running. In Entra ID, you can verify this by checking the provisioning settings here:

User provisioning may fail if any of the required attributes are missing from a user account. This is especially common when provisioning test or service accounts that have not been set up with a first name or last name.

To prevent this, make sure that all the necessary user attributes are included in your SCIM (POST or PATCH) request.

As the next step, review your provisioning logs. Any accounts that fail to provision will likely generate an entry in the logs, providing valuable insights for troubleshooting. Our support may also request you to check these logs first, as any issues will initially be recorded on your end. The reason why an account update fails will be provided in your logs.

If you have created a new account for the same person after their return from maternity leave or an extended vacation, this will generate a new identifier in your system. This unique identifier is used by SCIM to recognize accounts in the app. However, our system still retains the old identifier, preventing the account from being found during the sync cycle.

In this case, you must contact our support team for further troubleshooting and to remove the stored ID. Please ensure you provide the user's email address when investigating specific accounts.

If a user account was previously created but then deactivated (due to parental leave, business unit change, long vacation, etc.) and now needs to be reactivated, please ensure you are re-enabling the existing account and not creating a new one in your identity provider platform.

If a new account is created, the uniqueID will have changed, and this cannot be updated in LawVu as it will not find a matching user, causing the provisioning to fail. Please contact our support team for assistance.

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.

The NameID format must be set to email or emailaddress and is a mandatory claim in the SAML response.

Please note that if the email is chosen as the unique identifier, there will be issues updating a user's account if that email changes in the future.

The EntraID JIT claim settings should look like the below example when using the UPN as the username (nameID).

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.

Your SAML signing certificate has an expiration date and must be updated on time to ensure business continuity.

Using the SSO Self Service portal, you can directly update your certificate in LawVu. If your certificate has already expired and you need support to regain access, please ensure your IT team provides the certificate in the following format:

Please note that Metadata URL's in the XML format containing multiple SSO details and certificates will not be accepted by our support team. You must provide a single certificate so our team can update without delays.

In certain situations, it may be necessary to provision a user on-demand. This allows an IT administrator to manually sync an individual user or group into the application.

Doing so ensures that the user or group is fully updated with the latest attributes and status within the application.

If you've been instructed to perform this action and you are using Azure/EntraID, then please follow the steps outlined in the relevant Microsoft article.

If on-demand provisioning or push is not available, try removing the user from the assigned application, wait a moment, and then re-add them. In most cases, this will trigger an update from your identity platform into the app.

Please note: The steps above apply only if SCIM is in place. For JIT (Just-In-Time) provisioning, there is no sync cycle and updates are applied at the time of a successful login.

If you encounter any issues with a user update or login, it is always best to check your provisioning logs first.

This ensures that the identity provider site has been reviewed, as it typically contains the most comprehensive and detailed logs in the event of a failure.

Once you confirm whether a SCIM user update was successful or failed, LawVu can then check the application-side logs to compare outcomes.

This process helps pinpoint the issue more accurately and ensures faster resolution times.

If you have checked your SAML Sign-In logs at your identity provider, then please note that the logs you are viewing are from your identity provider site and not LawVu. This is a common point of confusion for administrators.

What you're seeing is a successful login at your Identity Provider (IdP). However, LawVu logs or any other cloud appplication, are maintained separately on the serivce provider site and are not visible at your end.

If a user account is disabled in LawVu as was the case here you will not see a failed login attempt to the LawVu application in Azure logs.

To clarify:

Please ensure your SCIM provisioning is running. Check your provisioning logs for any errors or try a provision on demand.

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.