Clio Operate can use Microsoft Entra ID to authenticate your users, so they sign in with their Office 365 account instead of a Clio Operate password. To set this up, you register Clio Operate as an application in Microsoft Entra, then add Microsoft Entra to Clio Operate as an identity provider.
Before you start
- Administrator access to Clio Operate, so that you can open the admin console.
- Permission in Microsoft Entra to create an app registration and to grant admin consent if your tenant requires it. See Create an app registration for Clio Operate for the roles.
- The address of your identity server tenant. Your project team provides this.
How Clio Operate secures the connection to Office 365
Authentication uses the industry standard OpenID Connect protocol, so Clio Operate never stores your Office 365 credentials. Your users sign in to Microsoft, and Microsoft issues security tokens back to Clio Operate. Think of these tokens as temporary passes that you can revoke at any time.
Because users sign in to Microsoft rather than to Clio Operate, your existing identity controls still apply. Accounts can have MFA enabled, and Microsoft evaluates each sign-in against your Conditional Access policies in the same way as any other sign-in.
Create the app registration
Follow the article Create an app registration for Clio Operate, using the values in the Authentication row of the table in that article. In summary, authentication needs:
- A redirect URI of type Web, set to the address of your identity server tenant.
- The ID tokens option enabled under Implicit grant and hybrid flows.
- The
User.Readdelegated permission.
You then need three values from the registration: the Application (client) ID, the Directory (tenant) ID, and the OAuth 2.0 authorisation endpoint (v2) from the Endpoints panel.
Add Microsoft Entra as an identity provider in Clio Operate
Clio Operate ships with an identity provider named Sharedo AAD. Add a new provider instead of editing the existing one. If you edit Sharedo AAD and get a setting wrong, nobody can sign in, and you cannot fix it without help from Clio. Leave Sharedo AAD in place, because Clio uses it to sign in when supporting you.
- Open the admin console and navigate to Integrations > Manage Identity Server.
- In the Identity providers panel, select Add Provider.
- Complete the fields described below.
- Select Save. Clio Operate asks whether it can restart the identity server. Select Yes.
Set how the sign-in button appears
Complete the Display settings section to control how users see this provider on the sign-in screen.
| Field | What it does |
|---|---|
| Login Caption | The text on the sign-in button, for example "Sign in with Microsoft". This is the button your users select, so give it a label they will recognise. |
| Icon class and Icon additional styles | The icon shown on the button, and any extra styling. |
| Make primary | Select this to encourage users to choose this provider over the others. |
| Display order | Where this provider appears when more than one is enabled. |
Provider fields
Complete the OpenId settings section.
| Field | What to enter |
|---|---|
| OpenId Authority | The OAuth 2.0 authorisation endpoint, with everything after the tenant ID removed. The result is usually https://login.microsoftonline.com/[tenantId]/
|
| OpenId Client Id | The Application (client) ID from the app registration. |
| OpenId Post logout URL | Where Microsoft returns users after they sign out. See Sign out behaviour below, because the value depends on whether you use seamless sign-in. |
| OpenId Custom Meta URL | Leave blank in most deployments. Use this only to override where the provider publishes its openid-configuration metadata document. |
| OpenId Scopes | Leave blank. Clio Operate then uses openid profile. The openid scope is mandatory and identifies the user. Add other scopes, such as email, only if you need the claims they provide. |
| OpenId Response Types | Leave blank. Clio Operate then uses code id_token, which is the hybrid flow. Set a value only if your provider requires a different response type. |
| Client Secret | Optional. Enter one only if you created a client secret on the app registration. |
Match Microsoft accounts to Clio Operate users
The Advanced settings section tells Clio Operate which claim identifies the user. It has two fields, Identity claim and Name claim.
UPN is the claim most commonly used to match a Microsoft account to a Clio Operate user record, but it is not always present, for example, for guest accounts. You can enter several claims separated by commas, and Clio Operate tries them in order. Entering upn, email matches on upn first, then falls back to email.
Both fields are optional. If you leave Identity claim blank, Clio Operate tries these claims in order: sub, then email, then name, then upn. If you leave Name claim blank, Clio Operate uses name.
Set Identity claim explicitly if you want a specific claim to take precedence. The default order starts with sub, which is a Microsoft-generated identifier rather than something you recognise, so it will not match a Clio Operate user record that you have keyed on a UPN or an email address.
Sign-out behaviour
The value you use for OpenId Post logout URL depends on how users sign in.
- If you do not use seamless sign-in, set it to your Clio Operate instance address.
-
If you do use seamless sign-in, so that being signed in to Office 365 signs users in to Clio Operate with no prompt, set it to your Clio Operate address, followed by
/security/signedOut.
The second case matters. If you use seamless sign-in and set the post-logout URL to the Clio Operate address, signing out does not work: Clio Operate redirects the user to Microsoft, Microsoft signs them straight back in, and they return to Clio Operate still signed in.
Configure a user to sign in with Microsoft Entra
You can add users manually or provision them automatically. See Adding O365 Users to Clio Operate for automatic provisioning with SCIM.
To configure one user manually:
- Open the admin console and navigate to Users > All.
- Create a new user, or open an existing one.
- Open the User Account blade.
- Set Active so that the user can sign in.
- Set Identity Provider to the provider you configured above.
- Set Identity Claim to the value that matches the claim you chose in Advanced Settings. This is usually the user's UPN or email address.
Test the sign-in
- Open your Clio Operate instance in a browser.
- Select the sign-in button for the provider you configured. Its label comes from the Login Caption field.
- Sign in with the user's Microsoft account you configured.
A successful sign-in confirms the app registration, the identity provider and the user's identity claim.
If the sign-in fails, check the following:
- The user is set to Active.
- The user's Identity Claim matches the claim configured on the provider under Advanced settings.
- The redirect URI on the app registration matches your identity server address exactly.
- The provider is enabled in the Identity providers panel.
Turn off password sign-in
Clio Operate provides a built-in identity provider named Local forms based login, which is the username and password sign-in screen. Once Microsoft Entra sign-in works for your users, you can disable it, so that Microsoft Entra becomes the only way to sign in.
- Navigate to Integrations > Manage Identity Server.
- In the Identity providers panel, select Local forms based login.
- Select Disable.
Users then no longer see the sign-in screen, and are signed in without a prompt.
Before you disable it, confirm that every active user has an identity provider and an identity claim set. A user without them has no way to sign in once password sign-in is off.
Related articles
- Create an app registration for Clio Operate
- Adding O365 Users to Clio Operate
- O365 Integration: Overview