In this article, we cover the following topics:
- How to set SSO policy settings
- How to add and remove users from an SSO policy
- How to reset passwords when using SSO
- How to add new users to your subscription
- How to turn off SSO for your subscription
How to set SSO policy settings
Once you set up SSO in Settings, you can create a new Policy template or edit an existing one on the Policies tab. Single Sign-On will only be enabled for those users who are in the policy group where you enable SSO.
- Go to the Policies tab.
- Select an existing policy where you’d like to enable SSO or create a new one.
- Enable SSO by clicking the toggle under Single Sign-On (SSO) Authentication.
- If you have 2-Step Verification enabled, a pop-up will appear to let you know that this will be handled by your SSO identity provider.
- And you’re done! You’ve just enabled SSO for your selected policy template.
How to add and remove users from SSO policy
To add or remove users from an SSO enabled policy template, you need to navigate to the Users tab. You can add users one-by-one or in batches. On the Users tab, the Authentication column lets you keep track of users’ authentication methods. Here, you’ll be able to see whether they’re using SSO or their own Tresorit password for signing in. This column will only be visible when you have at least one user on an SSO enabled policy.
Adding users to an SSO enabled policy
- Navigate to Users.
- Check the box to select users.
- Click Change template and select an SSO enabled template from the dropdown list.
- The next time the user is active, they’ll have to migrate to SSO to sign in.
Removing users from an SSO enabled policy
- Navigate to Users.
- Check the box to select users.
- Click Change template and select a non-SSO enabled template from the dropdown list.
- The next time the user is active, they’ll have to set up a Tresorit password for signing in.
How to reset passwords when using SSO
If a user in your subscription cannot sign in using SSO, you can reset their Tresorit password. In this case, SSO will be turned off for that user, and a temporary password is generated. The user will be able to sign in to Tresorit using this temporary password. In case the user is still assigned to an SSO enabled policy template, they will be automatically migrated to SSO again once they’ve signed in to Tresorit.
How to add new users to your subscription
Whether you’re adding a user to an SSO enabled policy or a non-SSO policy, the process of inviting new users to your subscription does not change. If you’re inviting a new user directly to an SSO enabled policy, they’ll sign up to Tresorit using SSO right away, without having to create a separate Tresorit password.
📝 Note: After integration, your SSO provider will not take over user provisioning in your Tresorit subscription. You’ll still have to manually add, manage, or remove users from your subscription. Alternatively, you can set up SCIM provisioning for your subscription as well: Introduction to SCIM provisioning
How to turn off SSO for your subscription
To turn off SSO for your subscription, you first need to make sure that all users have migrated from SSO and have a Tresorit password they can use to sign in.
- Navigate to the Policies tab.
- Assign all SSO users to a non-SSO enabled policy template.
See above: How to remove users from an SSO policy - On the Users tab, you can track users’ SSO status.
- Once all users have a Tresorit password, you can disable SSO on the Settings tab.
What happens if you disable SSO while some users are still using it?
For users who haven’t created a password yet when you disable SSO, SSO will remain active until the next sign-in or user interaction.
This will also happen when SSO is disabled in the following scenarios:
- If you disable SSO in Settings without removing users from the policy,
- if a user is removed from the subscription,
- if you downgrade to a plan without SSO,
- if your credit card expires,
- or if you cancel your subscription.
📝 Note: Don’t delete any settings in Azure AD, Google Cloud Portal or Okta before all users have switched to password authentication. This would cause all user accounts without Advanced Control to be lost, without the possibility of being restored.
Still have questions left? Drop us a line