Role-Based Access Control (RBAC)
Being authenticated tells OmniWeb who you are. RBAC decides what you may do. Access is granted at a fine grain — per element type, per HTTP method — which maps directly to the real operations an operator performs: view, modify, or delete.
← Authentication & Access Control · ← Operations Guide
Permission Levels
Each element type can be granted to a user at one of three levels. The level is expressed as the set of HTTP methods the user may use against that element through the proxy:
| Permission | Methods allowed | What the operator can do |
|---|---|---|
| Read-only | GET | View data only — no changes |
| Read-write | GET, POST, PUT, PATCH | View and modify — e.g. add a subscriber, edit a route, change a QoS rule |
| Full | GET, POST, PUT, PATCH, DELETE | Everything, including deletion and clearing sessions |
Because permissions are keyed to HTTP methods, they line up exactly with the generic editing model: an "Add" form is a POST, an "Edit" is a PUT/PATCH, and a "Delete"/"clear" is a DELETE.
Per-Element Granularity
Permissions are assigned independently per element type. A user can hold different levels on different elements:
In this example Jane can clear UPF sessions, can view but not change the HSS, can add SMSC routes, and cannot see the OCS at all. This lets you give, say, a dataplane engineer full control of the UPF while keeping subscriber data read-only.
Administrators
Administrators have full access to all element types automatically. The admin role is also what grants access to user and permission management. Keep the number of administrators small, and prefer specific per-element grants for everyone else.
Managing Roles & Permissions
Permissions are managed under Settings → Permissions. For each user you choose, per element type, whether they have read-only, read-write, or full access (or none).
How Enforcement Works
RBAC is enforced in two complementary places:
- In the UI — controls for actions you cannot perform are not shown. If you only have read access to the HSS, you will not see Add/Edit/Delete buttons there.
- In the backend — every proxied request is re-checked against your permissions server-side. Even a request crafted to bypass the UI is rejected if your role does not permit that element/method.
This "defence in depth" means the UI is a convenience, not the security boundary — the backend proxy is.
Settings → Permissions — select a user, then grant a level (read-only, read-write, or full) per element type.
Good Practice
- Least privilege — grant the lowest level that lets someone do their job; widen only when needed.
- Read-only by default for elements an operator only needs to observe.
- Reserve Full (DELETE) for those who genuinely need to clear sessions or remove records.
- Few admins — use targeted per-element grants instead of handing out admin.
Related
- Login & JWT Sessions — authentication that RBAC builds on.
- Common Operations — how permissions shape the everyday UI.
- Audit Logging — both permitted and denied actions are recorded.