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 SSO is misconfigured, you may see one of the error messages listed below when you attempt to sign in.
Error message: "Please try again later! The server has encountered an unknown error. If the problem persists, contact your administrator."
This issue is most commonly caused by an expired client secret in the SSO provider. An admin user of the firm must update their SSO configuration.
-
Regenerate the client secret. This can be completed through your SSO provider.
-
Log in to Caseware Cloud.
Note: If you cannot login, contact your local distributor and request that they disable SSO for your admin account. Include the following information in your request:
-
The full firm URL
-
The email address of your admin account where SSO should be disabled
-
Written client authorization to disable SSO for the admin account
Once SSO is disabled for the admin account, use the Forgot Password option on the login page to set a new password and login to Cloud.
-
-
Update the SSO configuration in Cloud with the new client secret. This will restore login access for other users.
-
If SSO was disabled for your admin account, log in again using SSO to re-enable it. Alternatively, you may want to leave SSO disabled for your account in case this issue arises in the future.
-
Set reminders/monitoring for the client secret expiry. The firm can prevent future lockouts by rotating the client secret prior to the next expiry date.
Error message: "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.
Error message: "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.
Error message: "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.
Error message: "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).
Error message: "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.
Error message: "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.
Error message: "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.
