Test and activate single sign-on

What this achieves

Testing checks that Humavera and your identity provider can actually talk to each other. Activating makes single sign-on available, and enforcing it blocks password login for everyone in your organization — which is the point at which a mistake stops being reversible from the inside.

Required role: Administrator.

Before you start

Save the configuration first. The screen states the order: save, then test, then activate from the Status card.

Have a second administrator signed in on another device before you enforce anything. That is not a product feature; it is the practice that turns a lockout into an inconvenience.

Steps

Go to Integrations → SSO.
On the Status card, select Test Connection.
Read the result beside Last tested: — Passed or Failed.
Fix whatever failed and test again.
Select Activate once the test passes.
Sign in as a real user through single sign-on and confirm they arrive with the role you expected.
Only then turn on Enforce SSO under Provisioning & Enforcement, and save.

What each control does

Option	Description
Test Connection	Checks the configuration against your identity provider and records the result against Last tested:.
Activate	Makes the single sign-on configuration live.
Deactivate	Turns it off again.
Enforce SSO	Requires every user in the organization to sign in through single sign-on. Password login is blocked.

Activating and enforcing are two different acts. Activation makes single sign-on work. Enforcement removes the alternative.

This is the sentence to read twice. The screen states it plainly: when Enforce SSO is enabled, all users in the organization must use single sign-on to sign in, and password login is blocked. The warning beside the switch says password login will be disabled for all users and to ensure single sign-on is working before activating.

There is no per-user exemption in the interface. It applies to every user, including the administrator who turned it on.

Example: Priya Raman enforcing single sign-on at HC Corp while an attribute mapping is subtly wrong locks out everyone whose sign-in depends on that mapping — including herself, if she is signed out when she finds out.

What the product does to prevent a lockout

Humavera puts three things between you and that outcome.

Option	Description
Test Connection	Validates the configuration against your provider before anything is live, and records whether the last test passed or failed.
The activation warning	Activating without a passing test raises a confirmation stating that this may lock users out if the configuration is incorrect, and that there is no way to fall back to password login once single sign-on is enforced.
Deactivate	Available on the Status card, so a configuration that turns out to be wrong can be switched off.

Where the test cannot reach your provider from Humavera — a provider only reachable from your corporate network, or a staging setup — the confirmation says you may still activate, but be ready to deactivate quickly if sign-ins fail. Take that literally: stay signed in, on the page, with a colleague trying to sign in on another machine.

Test with a real person before enforcing

A passing connection test proves the two systems can talk. It does not prove that a real employee arrives with the right role, or that your groups claim is the one your provider actually sends.

Activate, have one real person sign in, and check what they got. That single test catches the mapping errors that a connection test cannot see, at a cost of one person’s five minutes rather than everyone’s morning.

Example: at HC Corp, James Whitfield signing in through the new configuration and arriving with no role at all tells Priya Raman the groups claim is wrong — before the switch that would have done the same to all five departments.

What happens next

Once enforced, everyone signs in through your identity provider, and access follows your group mappings on every login. Deactivating single sign-on restores the previous sign-in behaviour, so it is the control to reach for if something is wrong — not a support ticket.

Where auto-provisioning is on, new employees get a Humavera account the first time they sign in, subject to your allowed email domains. Where auto-deprovisioning is on, deactivating somebody in your directory deactivates them here.