User Management

The User Management page is where administrators create, edit, deactivate, reactivate, and reset passwords for everyone who logs into the appliance. Roles, authentication method (local password vs SSO), and per-user session timeouts are set here.

You reach the page at Settings > User Management in the sidebar. The page is admin-only: operators and viewers do not see it in the sidebar and cannot reach it by direct URL — the API rejects them.

Page Layout

A header with a Create User button, a filter row, then the user table with top and bottom pagination.

+--------------------------------------------------------------------+
|  Users                                            [+ Create User]  |
+--------------------------------------------------------------------+
|  [Search users...]   [All Roles ▾]   [ ] Show inactive    [⟳]       |
+--------------------------------------------------------------------+
|  Pagination (page, total, page-size)                                |
+--------------------------------------------------------------------+
|  User                | Role     | Status  | MFA      | Last Login | |
|----------------------|----------|---------|----------|------------|-|
|  claude              | admin    | Active  | Enabled  | 2 min ago  |⋯|
|  alice [SSO]         | operator | Active  | Disabled | yesterday  |⋯|
|  bob                 | viewer   | Inactive| Disabled | Never      |⋯|
+--------------------------------------------------------------------+
|  Pagination (same as top)                                           |
+--------------------------------------------------------------------+

Filter Controls

Control	Purpose
Search	Free-text match against username (and email if present).
Role filter	Show only admins, only operators, only viewers, or all.
Show inactive	When unticked (default), only active users are shown. Tick to include deactivated accounts.
Refresh	Re-queries the user list.

Pagination

The page-size options are 25 / 50 / 100 / 250. Pagination appears both above and below the table for long lists.

Columns

Column	Description
User	Username and email (if set). An SSO badge marks users authenticated externally rather than by local password.
Role	One of `admin`, `operator`, `viewer`, shown as a coloured pill.
Status	Active or Inactive. Inactive users cannot log in.
MFA	Enabled or Disabled. Reflects whether the user has set up a TOTP authenticator.
Last Login	Timestamp of the last successful login, or Never.
Actions	Per-row icons: edit, change password, deactivate (active users) or reactivate (inactive users).

Inactive rows are dimmed.

Roles

Three roles, in a strict hierarchy. Higher roles include the permissions of all lower roles.

Role	Level	What it can do
Viewer	1	Read-only access to all monitoring data: dashboard, device history, device details, alarms, reports. Cannot apply actions, cannot edit configuration, cannot manage users.
Operator	2	Everything a viewer can do, plus apply actions (block, throttle, monitor, allow, cleanup), trigger analyses, edit automation rules, manage prompts on automation rules, edit configuration that is not admin-only.
Admin	3	Everything an operator can do, plus user management, license upload, terminal/console access, support backchannel control, IP restrictions, data retention edits, and Prometheus scrape-token management.

A role check is hierarchical: if a route requires operator, both operators and admins pass; viewers do not.

What Admin-Only Means in Practice

A non-exhaustive list of features that require admin:

This User Management page.
License management (chapter 37) — upload, delete, view installation binding.
Advanced administration and vendor-support controls.
IP restrictions on the API.
Data retention overrides.
Prometheus scrape-token CRUD (chapter 40).

Operators handle the day-to-day enforcement and analysis work; admins handle infrastructure and identity.

Authentication Methods

Every user has an authentication method: local password or external SSO.

Method	What it does	Email required?
Local	The user logs in with a password stored in the appliance database.	Optional.
External (SSO)	The user logs in through an OAuth2/OIDC provider — Google, Keycloak, generic OIDC.	Required, and must match the SSO provider’s email.

The authentication method is the first field in the create/edit form. It can be changed on an existing user, but the system warns you first:

Local → External: the user must use SSO next login; their local password is preserved in the database but ignored.
External → Local: the user is forced to set a new password on next login.

The SSO badge on the user list marks external users at a glance. See Authentication (chapter 29) for the OAuth2 provider configuration that has to be in place before external auth can be used.

Creating a User

Click “Create User” in the top-right.

The Create User modal opens with these fields in order:

Field	Required	Description
Authentication Method	yes	Local or External. Determines which downstream fields appear.
Username	yes (3–50 chars)	Letters, digits, underscore, dot, hyphen. Immutable after creation.
Email	required for External, optional for Local	Must match the SSO provider email for External users.
Role	yes	Admin / Operator / Viewer.
Session Timeout (minutes)	optional	Per-user idle-timeout override. `0` = use system default.
Password	required for Local create	Subject to the password policy below.
Confirm Password	required for Local create	Must match.

A short “Role Permissions” note at the bottom of the form summarises the three roles for the operator creating the user.

Password Policy

When the appliance has a password policy in effect, the modal shows the requirements inline (minimum length, uppercase, lowercase, digits, special characters) and validates each constraint as you type. The shipped default policy is:

Constraint	Default
Minimum length	8
Require uppercase letter	yes
Require lowercase letter	yes
Require number	yes
Require special character	yes
Max age	unlimited
Reuse history	none

Admins can change the policy under Settings > Security. The policy applies to local users only — external users authenticate against their SSO provider, which enforces its own password rules.

Session Timeout

Per-user session timeout overrides the system-wide idle timeout (chapter 30). Use 0 for the default. The form helpfully converts your number into hours / days / years below the field so you can see at a glance what 525600 actually means (one year).

This timeout is idle time, not absolute session lifetime. A user actively clicking through the GUI resets the timer on each request.

Editing a User

Click the pencil icon on any row.

The same modal opens with the user’s existing values pre-filled. The username field is disabled — you cannot rename a user. Email, role, authentication method, and session timeout can all be changed.

Changing the authentication method opens an additional confirmation step (see “Authentication Methods” above) explaining what the user will see on their next login.

Click Save Changes to persist. The change takes effect immediately; existing sessions for the edited user are not invalidated, but the new role applies the moment the user reloads the page or the next API call is made.

Changing a Password

Click the key icon on any row.

A separate modal handles password changes. The form has:

Optional current password (admins changing someone else’s password skip this).
New password — subject to the password policy.
Confirm new password.

For local users, the new password is hashed and stored. The user’s next login uses the new password. Active sessions remain valid; the appliance does not force a logout on a password change initiated by an admin.

For external (SSO) users, the password field is preserved but ignored. Use this modal only as a fallback if you plan to flip the user back to local authentication.

Deactivating a User

Click the trash icon on an active row.

Deactivation is a soft delete. The confirmation modal explicitly says “Deactivate” rather than “Delete” — confirming sets the user’s active flag to false. They cannot log in, but their audit trail, sessions history, and actions history are preserved.

Active sessions are not invalidated automatically by deactivation. If you need to kick a deactivated user out immediately, terminate their sessions from the Active Sessions page (chapter 30).

A deactivated user disappears from the default user list (you must tick Show inactive to see them). Use this to retire accounts cleanly without losing their history.

Reactivating a User

Tick “Show inactive” to reveal deactivated users, then click the curved-arrow icon on the row.

Confirmation re-enables the account. The user’s password, role, and email are preserved exactly as they were at deactivation. They can log in immediately.

If you want to reset other attributes — change role, change auth method — open the edit modal after reactivation.

Hard Delete

The GUI does not expose a hard delete.

Every account that was ever active is preserved in the database for audit traceability. Deactivation is the only “remove” workflow exposed through the GUI. If a user’s audit data must be erased (e.g. for compliance reasons) that operation is done at the database level by a system administrator with shell access — not from this page.

MFA (Multi-Factor Authentication)

MFA is enrolled and managed from the user’s own Profile page, not from this page.

The User Management table shows whether each user has MFA enabled, but the admin cannot enrol another user’s authenticator app — the secret has to be scanned on the user’s own device.

The administrator’s lever here is the MFA Required for Roles setting under Settings > Security: when a role is on that list, users with that role cannot complete a login without an MFA factor. New users with such a role are forced through MFA enrolment at first login.

To reset a user’s MFA (e.g. when they lose their phone) an admin opens the edit modal and clears the MFA fields, or runs the MFA reset action exposed there. The user is required to re-enrol at their next login.

Recovery for the last admin. If the only admin loses access (forgotten password, lost MFA), there is a local recovery path that runs on the appliance host. Plan for this before you need it.

Licence-Aware Seats

The licence may cap the number of concurrent users.

When the appliance licence has a max_users field set, that number caps simultaneous sessions, not total user accounts. You can create as many user accounts as you like; only the count actively logged in at any moment is counted toward the cap.

Behaviour when the cap is hit:

Non-admin users attempting to log in are rejected with a “session limit reached” error.
Admin users are never blocked by the cap — this is a deliberate safety net to prevent a misconfigured licence from locking the only operator out of the system.
The cap is enforced against the live sessions table; users who log out (or whose sessions time out) free a slot immediately.

A licence with max_users = 0 means unlimited. See License Management (chapter 37) for the licence-status page that shows the current cap and current usage.

OAuth-Linked Users

External users are created and managed the same way as local users, with two differences.

Auto-provisioning. If the configured OAuth provider has user-creation enabled, a successful SSO login for an unknown email can auto-create the user with a configured default role. The default role for unmatched users is set per provider under Settings > Authentication.
Role mapping. Some OAuth providers can return group claims. The provider configuration includes a role_mapping table that translates external groups to internal roles (e.g. admin-group → admin). Users whose group matches an entry are promoted automatically on first login.

In both cases the resulting account is identical to one you would create by hand. It shows on the user list with the SSO badge, can be edited like any other, and can be deactivated or reactivated normally. You cannot change an SSO user’s password locally in any way that takes effect — their provider is authoritative.

To force an SSO user to use a local password instead, edit the user and switch the auth method to Local. The system will prompt them to set a password on next login.

Authentication (chapter 29) — login flow, OAuth2 provider configuration, password policy details.
Sessions and Audit Log (chapter 30) — viewing and terminating active sessions, reading the audit trail of every user action.
License Management (chapter 37) — the licence file that may cap concurrent users.