Authentication & Access Control
OmniWeb is the single front door to the entire network, so access control is one of its most important responsibilities. It uses JWT-based login, fine-grained role-based access control (RBAC) over every element, SSH-key login for host access, and a unified audit trail spanning the portal and the hosts it manages.
This area is broken into focused pages:
In This Section
- Login & JWT Sessions: How operators log in, how the JWT works, token lifetime, and how a single login spans Grafana, Loki, and Homer.
- Role-Based Access Control (RBAC): Per-element, per-method permissions; how to grant them; and how they are enforced.
- SSH Key Login: Managed hosts fetch each user's SSH public key live from OmniWeb (AuthorizedKeysCommand), so host access is granted/revoked centrally.
- Audit Logging: The three layers of audit: portal request audit, SSH-login audit, and command audit.
The Access Control Model
OmniWeb layers four controls. A request must pass each before it reaches an element, and the whole chain is recorded.
| Layer | What it controls | Page |
|---|---|---|
| Authentication | Who you are, proven by a signed JWT | Login & JWT |
| Authorisation (RBAC) | What you may do, per element type and HTTP method | RBAC |
| Host access | Who may SSH where; keys served live from OmniWeb | SSH Key Login |
| Audit | What actually happened, across portal and hosts | Audit Logging |
Why It Matters
Because OmniWeb proxies every element, Grafana dashboard, Loki query, and Homer session, this single access-control chain governs the entire operational surface of the network. There is one place to grant access, one place to revoke it, and one trail that records who did what, on the portal and on the underlying hosts.
One trail for everything: API requests, logins, SSH logins, and permission changes, with user, element, method, result, and source IP. See Audit Logging.
Start with Login & JWT Sessions.