Roles at a glance
The five fixed roles, what each is for, how much data each one sees, and where access is actually decided.
- Version: 0.4
- Role: admin_user, viewer
CID222 has five roles and the set cannot be extended. Choosing the right one for an account is most of access control; the rest is subtraction. This page is the orientation — who each role is for and how much data it sees. The procedure for narrowing them lives in access control.
The problem
Two different questions get confused. "What may this person change?" is a question about the role on their account. "Which pages should this person be offered?" is a question about the page matrix. Answering the second by editing the first produces an administrator who cannot administer, or a reviewer who can.
How CID222 does it
| Role | What it is for | Data it reads | Mutations |
|---|---|---|---|
superadmin | The appliance owner. The only role that manages accounts and edits the access matrices | Everything | Yes |
admin_user | Day-to-day administration: security policy, detections, compliance, governance, channels, platform operations | Its own account, and the members of the groups it owns | Yes |
normal_user | An end user of the gateway | Only its own data | Its own only |
viewer | A read-only demonstration account | Everything | None — every mutating request is refused globally with READ_ONLY_ROLE |
auditor | An external reviewer signing off evidence | Compliance, governance and audit records across every account, never message content | No |
Two of these are supersets rather than lists: superadmin holds every capability by construction,
and viewer reaches every read while being refused every write by the property of the request
rather than by which endpoints it may call.
Where a decision is actually made
Three independent questions decide whether someone can use a page, and only the third is edited on a screen:
- Does this appliance have the module? The installed licence tier decides. See packages and licence tiers.
- Does the role reach the API behind the page? The role requirement on the controller decides. This is code, not configuration.
- Should the role be offered the page? The page matrix decides, and it can only subtract.
Two deliberate choices worth knowing
viewersees everything and changes nothing. It satisfies any role requirement on a safe HTTP method and is treated as a global reader by the data-scoping services, so it is a demonstration and review account rather than a restricted one. Do not use it to limit what somebody can see.auditoris refused the chat. An auditor holding a chat session would spend the customer's tokens and write rows into the evidence it is signing off, so the chat controller and the two session-creating handlers refuse the role withROLE_NOT_FOR_CHAT. Session reads are untouched.
Limits and known gaps
- The capability model is running in shadow mode. The 70-capability matrix is computed and
compared on every request but enforces nothing; what is enforced today is the role requirement on
the controller plus the page matrix. Read the generated capability table as the design the
decorators are being reconciled against, not as live policy. The comparison is exposed at
/admin/rbac/shadow-report. - An endpoint that declares no role requirement is reachable by any signed-in account. That is a property of a decorator-based model, and closing it in general is what the capability layer was for. The one place it was closed by hand is the chat.
- Fleet administration is superadmin-only. Endpoint-agent fleets carry no ownership column, so
under
admin_userone department could rotate another's enrolment token. The fleet-ownership model that would letadmin_userback in is tracked, not shipped. - Roles are not per-tenant scoped policy. A role decides authority; which tenant's data that authority reaches is decided separately, by scope. See multi-tenancy.
Related
- Roles, capabilities and pages — the generated matrix of every role against every capability and every page.
- Access control — the screen that narrows which pages a role is offered.
- Tenants and users — creating accounts and assigning them a role.
Last updated on