Integrate single sign-on

Cloud supports single sign-on (SSO) with Azure Active Directory (Azure AD). Using SSO with Cloud reduces the number of passwords staff members are required to memorize and helps administrators manage account issues (such as password resets) from a single location.

Note that,

  • Time Desktop is not compatible with SSO. Once SSO is enabled, SSO users will no longer be able to log in to Time Desktop.

  • Currently, SSO is only supported with Working Papers 2017.00.283 or later. If you are using an earlier version of Working Papers, SSO users will not be able to sign in with SSO.

Before you integrate single sign-on, you need to ensure:

  • Staff members in Azure Active Directory are integrated through Microsoft 365. Users with guest accounts in your directory will also be able to use single sign-on.

  • Password expiry is disabled in your firm’s password settings. Although SSO users do not use their Cloud credentials to log in, if password expiry is enabled, they will be unable to log in once their Cloud password expires. To disable password expiry, select No from the Passwords expire drop-down in your firm’s password settings.

Best Practice: We recommend that single sign-on integration is performed by an administrator who is familiar with single sign-on setup in Azure AD.

Enable single sign-on for your firm

In order to integrate single sign-on, you need to activate it in MyCaseWare to enable it for your firm.

Note: There is currently no fee to activate single sign-on.

To enable single sign-on for your firm:

  1. Ensure you have the Admin role or equivalent permissions.

  2. From the Cloud menu (), select Settings.

  3. Select System | Cloud Billing.

  4. Select the link to Go to MyCaseWare.

    Cloud Billing

  5. Select LICENSES from the top menu.

  6. Under your license information, select Site Details.

    Select Site Details on the Licenses page.

  7. Select Activate Single SignOn at the bottom of the Site Details page.

    Select Activate SingleSignOn at the bottom of the Site Details page.

Register a new app for single sign-on in Azure

To integrate Cloud with Azure AD, you must register Cloud as a new app. When registered, you can allow Cloud to access your Active Directory domain.

To register a new app for single sign-on in Azure:

  1. Sign in to your Azure portal. If you have access to more than one portal, select your account in the top-right corner, then select your desired tenant.

  2. Select Azure Active Directory.

  3. From the left-hand navigation pane, select App registrations.

  4. Select New registration.

    Select New registration.

  5. On the Register an application page, enter your registration data:

    • Name: Enter an appropriate name.

    • Supported account types: Select Accounts in this organizational directory only (Default Directory only - Single tenant).

    • Redirect URI: Select Web. You do not need to enter a URL.

  6. After you enter your information, select Register. Your application details are displayed.

  7. Copy your Application ID. You’ll need it to complete the SSO integration process in Cloud.

Generate a client secret

To enable secure communication with your Active Directory domain, you need to generate a client secret. The client secret is used by Azure to authenticate Cloud.

To generate a client secret:

  1. Sign in to your Azure portal.

  2. Select Azure Active Directory.

  3. From the left-hand navigation pane, select App registrations.

  4. Select the correct app from the list.

  5. Select Certificates & secrets from the left-hand navigation pane.

  6. Select New client secret.

    Select New client secret.

  7. Enter an appropriate Key description and select a Duration.

    When your key expires, users will be unable to access Cloud. We recommend selecting Never Expires to prevent unexpected loss of access for SSO users.

  8. Select Add.

  9. Copy your client secret value. You’ll need it to complete the SSO integration process in Cloud.

    Warning: Your client secret will be permanently hidden when you navigate away from the Certificates & Secrets pane. You must have access to your client secret to complete the SSO setup process. If you lose access to your client secret value, you must delete your client secret and generate a new one.

Copy the metadata endpoint

A metadata endpoint provides authorization URLs and other metadata necessary for SSO to function. You’ll use it when you configure SSO in Cloud.

To copy the metadata endpoint:

  1. Sign in to your Azure portal.

  2. Select Azure Active Directory.

  3. From the left-hand navigation pane, select App registrations.

  4. Select the correct app from the list.

  5. Select Endpoints.

    Select Endpoints.

  6. Copy the OpenId Connect metadata document endpoint. You’ll need it to complete the SSO setup process in Cloud.

    Copy the OpenID Connect metadata document endpoint.

Configure optional claims

Before completing the SSO integration process, you need to edit the manifest to include the given_name and family_name claims. When a staff member uses SSO, these claims will provide their first and last name to Cloud.

To configure optional claims:

  1. Sign in to your Azure portal.

  2. Select Azure Active Directory.

  3. From the left-hand navigation pane, select App registrations.

  4. Select the correct app from the list.

  5. From the left-hand navigation pane, select Manifest.

  6. Edit the optionalClaims property as follows:

    "optionalClaims": {
    "idToken": [
    {
    "name": "given_name",
    "essential": true
    },
    {
    "name": "family_name",
    "essential": true
    }
    ]
    },

    Note: You must copy the information above exactly to correctly configure optional claims.

    The configured optionalClaims property.

  7. Select Save.

Generate the reply URL in Cloud

Azure uses your Reply URL to redirect users back to Cloud after they have signed in with Azure.

To generate a reply URL in Cloud:

  1. Ensure you have the Settings Admin role or equivalent permissions.

  2. From the Cloud menu (), select Settings | Single Sign-On | Identity Provider.

  3. On the Identity Provider page, complete the following fields:

    • Identity provider display name: Enter a meaningful name for your identity provider. For example, Azure. This name will be displayed next to your Reply URL to identify it.

      Note: This name cannot exceed 32 characters and can only contain letters, numbers, underscores, plus and minus signs.

    • Identity provider metadata endpoint: Enter your metadata endpoint. To learn more, see Copy the metadata endpoint.

    • Client ID: Enter your Application ID. To learn where to find the Application ID, see Register a new app for single sign-on in Azure.

    • Client secret: Enter your client secret. To learn more, Generate a client secret.

    The Single Sign-On settings page.

  4. Select Add. Your reply URL is displayed.

  5. Select the Copy to Clipboard () button to copy your reply URL. You’ll need to add it to your app in Azure AD.

    Use the Copy to Clipboard button to copy your reply URL.

Set your Reply URL in Azure

After you generate a reply URL, you’ll need to add it to Azure to ensure that users can sign in successfully.

To set your reply URL in Azure:

  1. Select Azure Active Directory | App Registration, then select your app.

  2. Select Add a Redirect URI.

    Select Add a Redirect URI.

  3. Enter your reply URL in the Redirect URI field. To learn more, see Generate the reply URL in Cloud.

  4. Select Save.

Assign authorized staff to use single sign-on

If you want to ensure that only authorized staff within your firm are able to access CaseWare Cloud via single sign-on, you can assign authorized users to your app in Azure. If you want all staff members at your firm to be able to access CaseWare Cloud, you can skip this step and proceed to assign API permissions.

To assign authorized staff:

  1. Select Azure Active Directory | Enterprise Applications, then select your app.

  2. From the left-hand navigation pane, select Properties.

  3. Set User assignment required to Yes.

    Set User Assignment Required to Yes.

  4. Select Save.

  5. From the left-hand navigation pane, select Users and Groups.

  6. Select Add user.

    Select Add User.

  7. Select Users and select each user you want to assign to the application.

    Note: If you have a Premium Microsoft Azure account, you can create user groups and then select the group to grant access to all members of the group. For more information, see Create a basic group and add members using Azure Active Directory.

  8. Select Select when you have added all users who should have access.

  9. Select Assign to allow these users to access the application.

Assign API permissions

Configuring the API permissions will allow CaseWare Cloud to read basic information from Microsoft Azure in order to properly authenticate users.

To assign API permissions:

  1. Select Azure Active Directory | App Registrations, then select your app.

  2. In the left-hand navigation pane, select API permissions.

  3. Select Add a permission.

    Select Add a permission.

  4. Select Microsoft Graph.

  5. Select Delegated permissions.

    Select Delegated permissions

  6. Use the checkbox to select the following permissions:

    • Email

    • Openid

    • Profile

    • User.Read

  7. Select Add permissions.

  8. Select Grant admin consent for Default Directory.

  9. Select Yes when prompted, “Do you want to grant consent for the requested permissions for all accounts in Default Directory?”

    The API permissions are successfully configured.

Test your single sign-on integration

Now that Cloud is integrated with your Active Directory domain, you can test the integration by selecting Go to Single Sign-On from your Cloud sign-in page and completing the sign-in process. If it fails, see Why am I receiving an error message? for more information.

Frequently Asked Questions

This section contains frequently asked questions about integrating single sign-on with Cloud.


How secure is Cloud’s SSO integration?

Any user information which is passed between your identity provider and CWI is encrypted via Secure Sockets Layer (SSL) protocol and signed using JSON Web Encryption. When users are signed into your firm’s identity provider, the user’s identity credentials (login, username and password) are never shared with Cloud. Only the user’s basic profile information (their name and email address) is shared with us to authenticate the user.


Can staff members still sign in using Cloud credentials after SSO is enabled?

After a staff member has used SSO to sign into Cloud, they will only be able to sign in via single sign-on. If a staff member attempts to sign in using their Cloud credentials, an error message is displayed, directing the staff member to use SSO.


After removing my identity provider and re-adding it, some users are unable to sign in. Why?

If you have removed your identity provider and re-added it, users authenticated before the removal will be unable to sign in. For those users to sign in again, create new credentials for them in Azure AD. This process will not be required in future releases.


Can contacts use SSO?

Currently, contacts don’t have the ability to use SSO. The integration of SSO is with a firm’s identity provider and therefore will only support users who are included in the firm’s internal active directory.


We’ve enabled two-factor authentication. What happens if we also enable SSO?

If SSO is enabled for a firm, SSO users will no longer be able to use Cloud’s two-factor authentication feature. This is because it’s best practice for your trusted identity provider to have control of the authentication process. If you want to enable two-factor authentication, we recommend doing so through your identity provider.

Two-factor authentication will still be available for non SSO users.


What happens if I add a staff member’s account to Cloud before I add it to Azure AD?

If you have added a staff account to Cloud but not Azure AD, that user will not be able to sign in using SSO. To allow a staff member to sign in with SSO, add a new user to Azure AD using the email address associated with that staff member’s Cloud account as the user name.


What happens if I log out of my identity provider while I’m still signed into Cloud?

You will remain logged into Cloud as long as your session is active. When your session ends, you will be required to log in to your identity provider again before you can sign in to Cloud using SSO.


A staff member whose account status is Inactive is still able to sign in to Cloud. Why? 

After enabling single sign-on, account access is managed through Azure AD. To prevent a user from accessing Cloud, you must delete their account. To learn more, see How to: Add or delete users using Azure Active Directory.


A staff member whose account has been deleted in Azure AD is still signed in to Cloud. Why?

If you delete a user’s account in Azure AD while they are still signed in to Cloud, they will remain active in Cloud until their session times out or they sign out, after which they will no longer be able to sign in to Cloud.


Why can't I edit account names, email addresses or passwords in Cloud? 

After enabling single sign-on, account names, email addresses and passwords are managed through Azure AD. To learn more, see How to: Add or update a user's profile information using Azure Active Directory.


If our firm’s identity provider is having an outage, how else can users sign into Cloud?

Users will be unable to sign in to Cloud if your identity provider is experiencing an outage. We recommend maintaining an admin account that does not use your identity provider to ensure access to Cloud in case of emergencies.


What happens if my client secret expires?

If your client secret expires, SSO users will no longer be able to log in to Cloud. You must generate a new client secret and update your identity provider information in Cloud.

  1. Log into Cloud using your Cloud credentials.

  2. From the Cloud menu (), select Settings | Single Sign-On | Identity Provider.

  3. Select the Edit button().

  4. Enter the correct information for your identity provider in the Identity provider metadata endpoint, Client ID, and Client secret fields.

We recommend selecting Never expires when generating your client secret to prevent unexpected loss of access for SSO users.


Why am I receiving an error message?

If Cloud or Azure AD is misconfigured, you may see one of the error messages listed below when you attempt to sign in.


We're sorry ... Unexpected error when authenticating with identity provider

When configuring your identity provider, you may have entered an incorrect client secret or client ID.

  1. Log into Cloud using your Cloud credentials.

  2. From the Cloud menu (), select Settings | Single Sign-On | Identity Provider.

  3. Select the Edit button().

  4. Enter the correct information for your identity provider in the Identity provider metadata endpoint, Client ID, and Client secret fields.


AADSTS70001: Application with identifier ... was not found in the directory ...

When configuring Azure AD, you may entered an incorrect identity provider.

  1. Log into Cloud using your Cloud credentials.

  2. From the Cloud menu (), select Settings | Single Sign-On | Identity Provider.

  3. Select the Edit button().

  4. Enter the correct information for your identity provider in the Identity provider metadata endpoint, Client ID, and Client secret fields.


AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application ...

You may have entered an incorrect reply URL in Azure.

  1. From the left-hand navigation pane in Azure, select Azure Active Directory | App Registration.

  2. Select your app, then select Settings | Reply URLs.

  3. Select the Context menu button next to your reply URL, then select Delete.

  4. Add your reply URL again, then select Save.


No available Cloud access licenses. To obtain additional licenses, contact your administrator.

The number of users in your Active Directory domain exceeds the number of available Cloud licenses. When the number of users in your Active Directory domain exceeds the number of available licenses, some staff will be unable to sign in. To permit all staff members to sign in, purchase a license from MyCaseWare for each staff member or contact your local distributor.


Account already exists. User with email ... already exists. How do you want to continue?

This error occurs after a user is removed from Azure and another user is added using the same email address.

To work around this issue, delete the Cloud account associated with the email address displayed in the error message and have the user sign in again using SSO.

This process will not be required in future releases.


The received token is missing the following claims: email required for system access. Please contact your administrator.

The CaseWare Cloud SSO integration is designed to recognize ‘username’ and ‘email’ claims as distinct claims. Our integration requires the ‘email’ claim to work properly. The ‘email’ claim is only provided by guest users and managed users integrated through Office365. If your firm’s users are set up through Office365, please ensure to follow Azure’s instructions to manage the ‘email’ claim through the Office admin portal.


How can I disable SSO for my firm?

If you want to disable SSO for your firm, contact your local distributor.

After SSO is disabled, users can log in using their previous Cloud credentials. Users whose passwords have expired or who have only used SSO to log in to Cloud can use the Forgot your password? link to create a password for their account. If necessary, your firm administrator can also reset passwords for users.