Setup Considerations: single sign-on planning

What this achieves

Single sign-on is the most consequential switch a customer throws in this product, because getting it wrong locks people out of the system they would use to report that they are locked out. This page covers the decisions to settle before you configure anything, and what each costs to change later.

Decision 1: whether you will enforce, and when

There are two states, and the gap between them is where all the risk lives.

Option	Description
Activated, not enforced	Single sign-on works. Password login still works. Both routes in.
Activated and enforced	Enforce SSO blocks password login for all users in the organization. Single sign-on is the only way in.

Enforcement is the point of single sign-on for most companies — it is what makes your directory the single authority on who has access. It is also irreversible from the outside: if the configuration is wrong, nobody can sign in to correct it.

Run activated-but-not-enforced for a period. Days, not hours. Let real people sign in through the identity provider and arrive with the roles you expected, and only then enforce.

Example: HC Corp activates single sign-on on a Monday, watches sign-ins through the week, and enforces the following Monday. The cost is a week of two sign-in routes. The alternative cost is five departments unable to work on a Tuesday morning.

Decision 2: how you will avoid a lockout

The product gives you three things. Use all of them.

Option	Description
Test Connection	Validates the configuration against your provider before anything is live, and records whether the last test passed.
The activation warning	Activating without a passing test raises a confirmation stating this may lock users out, and that there is no fallback to password login once single sign-on is enforced.
Deactivate	Turns single sign-on off again from the Status card.

Add one thing the product cannot: a second administrator signed in on a different device, watching, while you enforce. If enforcement goes wrong and you are signed out, that session is the difference between a five-minute fix and a support escalation.

Where your identity provider is only reachable from your corporate network, the connection test may not pass even though the configuration is correct. The interface says as much and lets you activate anyway. That is the case where the second signed-in administrator stops being good practice and becomes the plan.

Decision 3: auto-provisioning

Option	Description
Auto-Provision Users	An account is created the first time somebody authenticates through single sign-on.
Off	Accounts are created in Humavera before anyone can sign in.

Auto-provisioning removes a manual step for every joiner, and it removes a checkpoint. With it on, anyone your identity provider will authenticate gets a Humavera account, subject only to your allowed email domains.

Decide alongside it whether your group-to-role mapping is complete. The interface states that with no mappings, auto-provisioned users are created without a role until you assign one manually — which is a queue of people with an account and nothing to do.

Decision 4: auto-deprovisioning

Auto-Deprovision deactivates a Humavera account when the account is deactivated in your identity provider. That is usually correct: a leaver is removed once, in your directory, rather than in every system.

Understand what it makes your directory responsible for. A person deactivated in error, or a directory hygiene project run without warning, deactivates them here too.

Example: HC Corp deactivating leavers in its directory each month gets clean Humavera access for free. The same company running a bulk clean-up of dormant directory accounts deactivates whoever was on long-term leave.

Decision 5: which domains, and what each list does

Two lists, similar names, different jobs. Getting them confused is a common configuration error.

Option	Description
Allowed Email Domains	Gates which email domains may auto-provision an account. Empty means any domain your provider asserts is accepted. Applies on first login only — tightening it later does not remove existing users.
Email-Domain Login Routing	Decides which domains route a sign-in attempt to your organization’s provider. Globally unique: a domain belongs to one organization only. Empty means people sign in via the workspace name.

Only claim domains you actually control. A routing domain captures every sign-in attempt at that domain.

Think about contractors and subsidiaries before you set the allowed list. A workforce on one domain is easy. A workforce on three, one of which belongs to a supplier, is a decision about who is entitled to an account — and the “applies on first login” rule means the decision is best made before people start arriving, not after.

Decision 6: certificate rotation

A signing certificate expires. When it does, without preparation, every sign-in stops at once.

Next IdP Certificate (rotation) stages the provider’s upcoming certificate. Both the current and the next validate logins while it is set, so the cut-over has no downtime, and metadata import fills it in automatically when the provider publishes two.

Settle who watches for the expiry. Your identity provider team knows the date; the person who administers Humavera often does not. That handover is the whole of the risk.

Where you enabled request signing, you hold a service-provider private key too. The interface states it is encrypted at rest and never returned in plaintext — you cannot read it back from Humavera, so keep your own copy where your organization keeps such things.

What is expensive to change later

Decision	Cost of changing later
Enforcing before testing with a real person	Very high. A wrong mapping becomes an organization-wide lockout, and the only route out is an administrator who is still signed in.
A routing domain claimed in error	Medium. It captures sign-ins at that domain until removed, and no other organization can claim it meanwhile.
Allowed email domains, once people have provisioned	High in effect. Tightening the list does nothing about accounts already created — those are removed one at a time.
Group-to-role mappings	Low to edit, high in effect. Roles refresh on every login, so a mapping change re-applies to everybody it covers.
Turning auto-deprovision on	Medium. Your directory becomes able to deactivate Humavera accounts, including by mistake.
The identity provider itself	High. A new provider means new metadata, new certificates, new mappings, and a second migration of everyone’s sign-in.

What happens next

Configure the provider, complete the attribute and group mapping, and save. Then test, activate, and let it run unenforced while real people sign in. Enforce last, with a colleague signed in on another machine, once you have seen somebody arrive with the right role.