Single sign-on: 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.
What authorization protocol is used?
We use the OpenID Connect authorization protocol.
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.
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.
Our firm's email domain has changed, how can I update staff's email addresses in bulk?
Firms with SSO enabled cannot edit the email field for staff directly. If you need to update your staff's email addresses in bulk, contact Caseware Support for assistance. We'll need to update the email addresses in Cloud at the same time as you update your Active Directory to ensure that your staff retain Cloud access.
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.
-
Log into Cloud using your Cloud credentials.
-
From the Cloud menu (
), select Settings| Single Sign-On | Identity Provider. -
Select the Edit button(
). -
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.
How can I restrict Cloud access so that staff can only access it from their work computers?
If you want to restrict Cloud access to work computers, consider adding trusted locations to Azure AD. This enables you to restrict access based on IP addresses, such as the office or VPN IP.
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.
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.
-
Log into Cloud using your Cloud credentials.
-
From the Cloud menu (
), select Settings| Single Sign-On | Identity Provider. -
Select the Edit button(
). -
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.
-
Log into Cloud using your Cloud credentials.
-
From the Cloud menu (
), select Settings | Single Sign-On | Identity Provider. -
Select the Edit button(
). -
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.
-
From the left-hand navigation pane in Azure, select Azure Active Directory | App Registration.
-
Select your app, then select Settings | Reply URLs.
-
Select the Context menu button next to your reply URL, then select Delete.
-
Add your reply URL again, then select Save.
AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID
When configuring Azure AD, you may have entered the Client ID in the Client secret field.
-
Verify if the client secret value is correct. If the value was copied as per the instructions, locate the client secrets stored in Azure AD and confirm whether it matches any IDs. If the copied value matches an ID, or you did not copy the client secret value, delete the current secret and create a new one. Ensure that you copy the client secret value.
-
Log into Cloud using your Cloud credentials.
-
From the Cloud menu (
), select Settings | Single Sign-On | Identity Provider. -
Select the Edit button(
). -
Enter the correct information for your identity provider in the Identity provider metadata endpoint, Client ID, and Client secret fields. The Client ID field should match the Application ID, and the Client secret field should match the client secret value from step 1 (not the Secret ID).
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.
