Appearance
RBAC (Role-Based Access Control)
Squizy implements a Role-Based Access Control system where permissions are resolved through a layered model: Authorities define granular permissions, Roles group authorities into profiles, and Users are assigned roles. App Tokens have authorities assigned directly. This page explains how the permission resolution works at runtime.
Authority Resolution
Authorities are evaluated at the API level. Every incoming request to /api/{entity} is checked against the authenticated caller's effective authority set. The mapping between HTTP operations and required authorities is:
| Operation | Required Authority |
|---|---|
GET /api/{entity} | {entity}.read |
POST /api/{entity} | {entity}.create |
PATCH /api/{entity}/{id} | {entity}.update |
DELETE /api/{entity}/{id} | {entity}.delete |
POST /api/{entity}/export | {entity}.export |
GET /api/{entity}/{id}/revisions | {entity}.audit |
If the caller lacks the required authority, the API responds with 403 Forbidden.
Effective Permissions
When a user makes a request, Squizy resolves their effective permissions by collecting all authorities from all their assigned roles. For App Tokens, authorities are assigned directly. If any authority grants a required permission, the operation is allowed. There is no authority negation — permissions are purely additive.
How Access Decisions Are Made
When a request reaches a Squizy API endpoint, the following evaluation happens:
- Authentication check: Is the caller authenticated? If not →
401 Unauthorized - Admin check: If the entity is
@AdminOnly, is the caller an admin? If not →403 Forbidden - Authority check: Does the caller have the required authority for the operation? If not →
403 Forbidden - Owner check: If the entity has an
@OwnerField, does the current user own the record (or is admin)? If not, the record is filtered from results
This layered evaluation ensures that authorization is enforced consistently across all entity operations, whether triggered from the UI or directly via the API.
Write vs. Read Authorities
The distinction between write and read authorities affects UI behavior. Fields and actions that modify data are only visible when the user holds the corresponding write authority. Read-only authorities (read, export, audit) never allow data modification.
See Authorities for the full list of auto-generated authorities per entity.