Authorization Overview
CDT uses role-based access control scoped to organizations. This page explains the model in plain language. For step-by-step UI tasks, see Managing roles and permissions.
The model in three sentences
Every user belongs to one organization. Within that organization, the user is assigned one role. The role determines what the user can do.
Why organizations matter
Permissions are scoped to the user's organization. A self-hosted instance can serve several teams, departments, or partner organizations without their data colliding.
For background, see Concepts → Organizations and multi-tenancy.
Built-in roles
CDT ships with three default roles:
| Role | Default permissions |
|---|---|
| Viewer | Read-only access to all assets in the organization. |
| User | Read everything, plus create, edit, and delete buildings, sites, files, comments, sensors, and infrastructure. |
| Admin | Everything a User can do, plus manage members and edit organization settings. |
The full default permission matrix is on the Permission reference page.
Where permissions are enforced
Permissions are checked in two places:
- Server-side, before every mutation in the API. This is the authoritative check — bypassing the UI does not bypass it.
- Client-side, to hide buttons and disable actions the user cannot perform. This is a UX layer only; do not rely on it for security.
The same Ability object drives both checks, so server and UI never disagree.
What you can do next
| You want to… | Read |
|---|---|
| Add users and assign them a role | Managing roles and permissions |
| See the full permission matrix per role | Permission reference |
| Understand how CASL evaluates rules | Roles, Permissions & CASL |
| Understand multi-tenancy | Concepts → Organizations and multi-tenancy |