Control over who can access the platform — and what they can do once they’re in — is a security and compliance requirement, not an afterthought. The Admin User Management module governs every staff account, every permission grant, and every access policy across the platform. It supports enterprise SSO out of the box, so staff can authenticate through Halo’s existing corporate identity infrastructure without maintaining a separate set of credentials.
This module manages admin and staff principals only. Shopper identity is handled separately by the Customers and Identities module.
Staff Users#
Each admin user has a platform-wide account. An account holds the user’s email, display name, and authentication credentials. Accounts are not store-scoped — a single account can hold roles across multiple stores simultaneously.
Lifecycle#
| State | Description |
|---|---|
| Active | Full access according to assigned roles |
| Suspended | Account exists but login is blocked — roles are preserved |
| Offboarded | Account is soft-deleted — access is revoked and the record is retained for audit purposes |
Password resets can be triggered by a platform admin at any time, forcing the user to set a new password on next login.
Roles#
Access is controlled through store-scoped role grants. A staff member can hold different roles on different stores — for example, ADMIN on one store and CATALOG_EDITOR on another. A role granted on one store confers no access to any other store.
Role grants are managed per user. Granting or revoking a role takes effect on the user’s next request — no re-login is required.
Access Restrictions#
Additional access rules can be applied per user or per role, either platform-wide or scoped to a specific store.
| Restriction | Description |
|---|---|
| IP allowlist | Restrict login and admin access to specific IP ranges |
| Time window | Limit access to defined days and hours in a configured timezone |
| Store scope | Limit which stores a user or role can reach, independently of role grants |
| MFA enforcement | Require MFA for a user or role regardless of the platform default |
MFA (TOTP) is enforced by default for all staff accounts. The platform default can be overridden at the restriction level for specific users or roles where a stricter or looser policy is required.
Federation Sources#
External identity providers can be connected to allow staff to authenticate via SSO instead of platform-managed credentials. Three federation protocols are supported:
| Protocol | Use case |
|---|---|
| SAML 2.0 | Enterprise IdPs (Okta, Azure AD, ADFS) |
| OIDC | OAuth2-based providers (Google Workspace, Auth0) |
| LDAP | Directory services (Active Directory, OpenLDAP) |
Federation sources can be configured platform-wide (applies to all staff) or scoped to a specific store (applies to staff accessing that store). Multiple sources can coexist.
When a federated user logs in for the first time, an account is provisioned automatically with no role grants. A platform admin must assign roles before the new user can access any store.
MFA#
Multi-factor authentication is enforced for all staff accounts by default. Two methods are supported:
| Method | Description |
|---|---|
| TOTP | Time-based one-time password via any authenticator app (Google Authenticator, Authy, etc.). User enrols by scanning a QR code. |
| Email OTP | A one-time code is sent to the user’s registered email address at each login. No app or enrolment required. |
Each user has one active MFA method. Platform admins can set or change the method per account. MFA enrolment status and method are visible per account in the admin interface. A platform admin can reset MFA for a user who has lost access to their authenticator.