Authorization model
CaseBender combines fixed roles, resource-and-action permissions, assignment scope, and TLP checks. A user can have multiple role assignments. Authorization is evaluated by the server for the organization and, where applicable, team involved in the request.- Platform scope uses an unscoped
superadminassignment. - Organization scope associates a role or direct permission with one organization.
- Team scope further associates the assignment with one team in an organization.
- A role supplies a permission template. A direct permission record can add an enabled permission for a user in the applicable organization or team.
A disabled direct permission is not an explicit deny: it disables that direct grant, but it does not remove a permission supplied by a role. Remove or change the role assignment when its template is too broad.
Fixed role catalog
The database seeds the following 20 roles. The capability summary is intentionally high-level; the seeded permission template, assignment scope, and server-side checks determine the effective actions.
Do not create an Integration user role. Programmatic credentials use API key scopes, described below.
Privileged markers
Roles and permissions can be marked privileged for audit and policy handling. This marker does not itself provide a user-facing privilege request or approval workflow. Do not assume that dual approval, session recording, break-glass access, or a particular elevation duration is enforced unless your deployment has separately implemented and validated those controls.Permission evaluation
Permissions use resource-and-action names such ascaseRead, caseUpdate, userRoleAssign, auditLogExport, and apiKeyRotate.
For a scoped request, CaseBender evaluates:
- Active role assignments in the applicable organization and team.
- The permission templates attached to those roles.
- Enabled direct permissions for the user in the scope being evaluated.
- The resource’s TLP level when the operation performs a TLP-aware check.
superadmin is treated as an unscoped all-permissions role. For other users, changing the active organization can change the role and permission set that applies.
TLP ceilings
CaseBender represents TLP as an ordered scale:
A TLP-aware check compares the resource’s value with the maximum role ceiling resolved for that user and request. TLP is an additional restriction: a sufficient ceiling does not grant a missing resource permission or bypass organization, team, or case-access boundaries.
Organization records also carry default and maximum TLP configuration. API keys have their own maximum TLP value. These values are separate from, and do not raise, a human user’s role ceiling.
Cross-team case access
A case can be granted to one user or one team outside its normal ownership boundary. Organization-wide grants are not part of the implemented recipient model.Grant taxonomy
Each grant records who granted it and can include a reason, source entity, and expiration. Expiration is an attribute of any grant, not a separate grant type. Revocation is retained in the grant audit data.
Access levels
The grant level controls cross-team case access. The user still needs any separately enforced permission and adequate TLP access for the requested operation.
API keys are separate from user roles
API keys are credentials owned by a user and optionally associated with an organization, but their authorization uses API scopes such ascases:read, alerts:write, or api-keys:rotate. A key also has its own TLP ceiling and lifecycle controls.
- A user role determines whether the user can create or administer keys and which scopes the interface offers.
- The created key carries its selected API scopes; it is not assigned one of the 20 user roles.
- Wildcard and administrative scopes should be reserved for workloads that require them.
- Key tiers describe rate-limit configuration, not an authorization role.
Related Documentation
- Authentication — MFA, SSO, and session management
- Audit Logging — Access event logging
- Members — User provisioning and role assignment