Custom role permission enforcement #83

New Issue

claude · 2026-03-17T19:14:53+01:00

claude commented

2026-03-17 19:14:53 +01:00

Context

The RBAC model supports custom roles (system = false) with a scope field (e.g., monitoring:read, config:write). However custom roles currently have no effect on authorization — only the four system roles (AGENT, VIEWER, OPERATOR, ADMIN) are enforced by SecurityConfig and @PreAuthorize.

The spec notes this is "for future permission expansion."

Requirements

Permission model

Define a set of granular permissions (e.g., agents:command, search:write, config:read, config:write, diagrams:read)
Map system roles to default permission sets (VIEWER gets read permissions, OPERATOR adds command permissions, ADMIN gets all)
Custom roles can grant additional permissions beyond the base system role

Enforcement

Evaluate permissions in SecurityConfig or a custom AccessDecisionVoter / method security
Custom roles assigned to a user (directly or via group) grant their scope permissions additively
No permission negation — permissions only grant, never deny

API

GET /api/v1/admin/permissions — list all available permissions
Permissions displayed on role detail page in RBAC UI

UI

Role create/edit form: multi-select for permissions (scopes)
Role detail: show granted permissions

Notes

This is a significant architectural change — consider whether the current 4-role model is sufficient for the near term
May want to start with a fixed permission catalog rather than fully dynamic permissions
The scope field on roles already exists in the schema — could be repurposed or replaced with a join table

## Context The RBAC model supports custom roles (`system = false`) with a `scope` field (e.g., `monitoring:read`, `config:write`). However custom roles currently have **no effect on authorization** — only the four system roles (AGENT, VIEWER, OPERATOR, ADMIN) are enforced by `SecurityConfig` and `@PreAuthorize`. The spec notes this is "for future permission expansion." ## Requirements ### Permission model - Define a set of granular permissions (e.g., `agents:command`, `search:write`, `config:read`, `config:write`, `diagrams:read`) - Map system roles to default permission sets (VIEWER gets read permissions, OPERATOR adds command permissions, ADMIN gets all) - Custom roles can grant additional permissions beyond the base system role ### Enforcement - Evaluate permissions in `SecurityConfig` or a custom `AccessDecisionVoter` / method security - Custom roles assigned to a user (directly or via group) grant their scope permissions additively - No permission negation — permissions only grant, never deny ### API - `GET /api/v1/admin/permissions` — list all available permissions - Permissions displayed on role detail page in RBAC UI ### UI - Role create/edit form: multi-select for permissions (scopes) - Role detail: show granted permissions ## Notes - This is a significant architectural change — consider whether the current 4-role model is sufficient for the near term - May want to start with a fixed permission catalog rather than fully dynamic permissions - The `scope` field on roles already exists in the schema — could be repurposed or replaced with a join table

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: cameleer/cameleer-server#83