Skip to main content

Enforce SSO (Single Sign-On) — Behavior and Enablement Guide

Overview

This document explains how the "Enforce SSO" setting works for a tenant, what prerequisites must be satisfied before enabling it, and the role-based behavior and UI implications after it is enabled.

In short:

  • When Enforce SSO is enabled, users are required to authenticate via the configured SSO provider.
  • Admin-type accounts retain the ability to authenticate with a password even when Enforce SSO is enabled.

Prerequisites

Before the tenant can enable Enforce SSO, ensure:

  1. A working SSO configuration exists for the tenant (metadata, client ID/secret, redirect URLs, certificates, etc.).
  2. The SSO provider has been tested successfully for at least one user in the tenant.
  3. Any required tenant-level configuration (example: identity provider configuration) is completed.

If SSO is not configured and an administrator attempts to enable Enforce SSO, the system will reject the change and surface an appropriate error message.

Role-based Behavior

The following describes how different account types are affected when Enforce SSO is enabled.

  1. Admin account type users

    • Can authenticate using both SSO and password at any time.
    • Continue to have access to change password, forgot password, and reset password functionality even when Enforce SSO is enabled.
    • Useful for recovery and administrative operations.
  2. Tenant Administrator role (non-admin account type)

    • Before Enforce SSO is enabled: can log in with password as usual.
    • After Enforce SSO is enabled: password login is blocked (they must use SSO) unless they are also an "admin account type".
    • Tenant administrators are typically the users allowed to enable Enforce SSO in tenant settings. But to disable it, have to contact administrator account type user only.
  3. Regular users (non-admin and not Tenant Administrator)

    • If Enforce SSO is enabled: can only log in using SSO.
    • Change password, forgot password, and reset password functionality is not available.

UI and Feature Implications

When Enforce SSO is enabled for a tenant, the following UI/flows are affected for non-admin users:

  • Change Password: not available (unless the user is an admin account type).
  • Forgot Password / Reset Password: not available for non-admin users.
  • Login Page: password login is removed or not available and only the SSO flow is offered (implementation may vary by deployment).

Admin account type users will still see and can use password-related flows.

Enabling Enforce SSO — Step-by-step

  1. Verify SSO configuration is complete and tested. Do not proceed if your SSO provider has not been configured.
  2. Sign in as a user who has permission to change tenant settings (typically a Tenant Administrator or a special system admin).
  3. Go to Tenant Settings → User Account Settings (or the equivalent settings page).
  4. Locate the "Enforce Single Sign On Settings" and enable it.
  5. The system will validate SSO configuration before saving. If validation fails, an error message will be shown and the setting will not be applied.
  6. After the setting is successfully saved, inform users of the change (recommended).

Validation and Error Handling

  • If no SSO provider is configured, enabling Enforce SSO will fail and the user will see an explanatory error message.
  • If SSO configuration is invalid (bad certificate, redirect URL mismatch, client secret expired), enabling will fail and diagnostics should be examined.
  • Rollback: If you enabled Enforce SSO and need to disable it, sign in as an admin-type account (which remains able to use password login) and toggle the setting off.

Testing Checklist

After enabling Enforce SSO, verify the following:

  • A regular user can authenticate only via SSO (password login disabled).
  • An admin-type user can authenticate via password and SSO.
  • Tenant administrators (if not admin-type) are required to use SSO.
  • Password-related UI (change/forgot/reset) is hidden or disabled for non-admin users.

Rollback Procedure

If you need to revert Enforce SSO:

  1. Sign in with an admin-type account (password login still works for admin-type accounts).
  2. Disable the Enforce SSO toggle from Tenant Settings → Authentication.
  3. Notify users of the change.

Notes

  • Always communicate tenant-wide authentication changes before enforcing SSO to avoid locking out users.
  • Keep at least one admin-type account with a usable password for emergency rollback.

Proactive monitoring and secret rotation

To avoid a situation where no user can sign in due to expired SSO secrets (client secrets, certificates, or tokens), implement proactive monitoring and an operational process for secret rotation and renewal:

  • Monitor SSO secrets and certificates for expiry dates and configure alerts well before expiry (e.g., 90/30/7 days). Use an automated monitoring system or certificate management service when possible.
  • Track client secret expiry, certificate expiry, and any metadata changes from the identity provider (IdP).
  • Establish an automated or manual renewal process that includes:
    • Updating the tenant SSO configuration with the renewed secret/certificate.
    • Verifying the IdP metadata (redirect URIs, keys) after renewal.
  • Keep a dedicated, securely stored record of SSO credentials and their expiry dates.

This document was last updated on September 26, 2025.