Roles and permissions
A role is a fixed map of modules to read, create, update and delete. There are five roles, and SXAccess checks the matrix below on every request.
A role controls what a person may do to the organization: create access rules, invite members, read Activity. It does not control what their devices may reach; that is decided entirely by groups and access rules. Being the owner does not, by itself, let a device reach anything.
Permissions are evaluated per module and operation, and the role is read from the member's record on every request, so a change applies at once. The modules are organization, users (members and service accounts), devices, groups, access_rules (access rules and device requirements) and network_routes (routes and Internet gateways). There are also networks (internal networks with their resources and routing devices), dns (DNS settings), dns_servers, enrollment_keys, api_tokens (access tokens), activity and settings (organization settings). The operations are read, create, update and delete.
The roles
You give someone a role when you invite them (Role in Invite member). To change it later, open People → Members, select the member, set Member role on the Access tab and choose Save Changes. A service account's role is changed the same way, from People → Service accounts.
| Role | How it is defined |
|---|---|
Owner (owner) | Read, create, update and delete on every module, including modules added later |
Admin (admin) | The same, with one exception: the organization module is read-only |
Network Admin (network_admin) | Nothing by default; only the modules listed in the matrix below are granted |
Auditor (auditor) | Read on every module, including modules added later. No writes anywhere |
User (user) | The ordinary member role, with no module permissions at all. While Hide other people's devices from regular members is on (the default, under Settings → Security), a User sees no device list. With it off, they see the devices they enrolled themselves, plus every device that an access rule connects to one of theirs |
What each role may do, by module
R read · CUD create, update and delete · - nothing. Activity can only be read: no role can change or delete it.
| Module | Owner | Admin | Network Admin | Auditor | User |
|---|---|---|---|---|---|
organization | R + CUD | R | R | R | - |
users | R + CUD | R + CUD | R | R | - |
devices | R + CUD | R + CUD | R | R | - |
groups | R + CUD | R + CUD | R + CUD | R | - |
access_rules | R + CUD | R + CUD | R + CUD | R | - |
network_routes | R + CUD | R + CUD | R + CUD | R | - |
networks | R + CUD | R + CUD | R + CUD | R | - |
dns | R + CUD | R + CUD | R + CUD | R | - |
dns_servers | R + CUD | R + CUD | R + CUD | R | - |
enrollment_keys | R + CUD | R + CUD | R | R | - |
api_tokens | R + CUD | R + CUD | R + CUD | R | - |
activity | R | R | R | R | - |
settings | R + CUD | R + CUD | R | R | - |
Modules added later
Each role also declares what happens to a module it has never heard of. Owner and Admin allow all four operations on it, Auditor allows read, and Network Admin and User allow nothing. That is why Network Admin has to list every module it needs explicitly, and why an auditor keeps seeing new things without anyone editing the role.
Blocked members
A blocked member fails every permission check before their role is looked at, and the check also confirms the member belongs to the organization being acted on. A person can hold a different role in each organization they belong to; the one that applies is the role on their membership of the organization being acted on, read afresh on every request.
Rules outside the matrix
A few rules hold whatever the matrix says:
- Access tokens can be created only for yourself, which needs create on
api_tokens(Owner, Admin and Network Admin), or by an owner or admin for a service account. Nobody can list, create or delete another person's tokens. A token lasts 1 to 365 days. - Owner. Only the owner can give the Owner role, and doing so transfers ownership: the previous owner becomes Admin. The owner cannot be blocked or removed, and a service account cannot be Owner.
- Your own membership. Owners and admins cannot change their own role or block themselves, and nobody can remove themselves from the organization.
- Device requirements are governed by
access_rules: whoever may write access rules may write requirements. - Reachable devices.
/api/devices/{deviceId}/reachable-devicesanswers in full only for owners, admins and service accounts. Anyone else gets an empty list for a device that is not their own.