RBAC Capability Foundation

Kontext

Stávající autorizace (DbAuthorizator) byla triviální: přihlášen = může vše. Pro produkční helpdesk nasazení potřebujeme granulární řízení přístupu — agent nesmí vidět tickety jiného tenantu, admin má jiná práva než agent.

Uvažované varianty:

A) Trivial role check — role=admin/agent/client, statický if/else

B) Hierarchical RBAC s capability-first modelem — atomické capability, scope, dědičnost

C) Policy-based (OPA, Casbin) — flexibilnější, ale výrazně komplexnější pro aktuální scale

Rozhodnutí

Implementace

Klíčové soubory:

• phinx/db/migrations/ — RBAC tabulky (rbac_role, rbac_capability, rbac_role_capability, rbac_person_role, rbac_group, rbac_group_member, rbac_group_role, rbac_scope, rbac_access_type, rbac_assignment_log)
• app/Service/RbacService.php — runtime autorizace, per-request cache přes v_person_effective_capabilities
• app/Presenters/BasePresenter.php — inject RbacService, metoda checkCapability()

Použití:

$this->checkCapability('p21.ticket.resolve', $ticketId);
$this->checkCapability('p21.ticket.admin');

V šabloně:

{if $rbacService->hasCapability('p21.rbac.admin')}...

Důsledky

Pozitivní:

• Granulární per-tenant oprávnění bez změny schématu při přidání nových modulů
• Auditní log všech přiřazení (rbac_assignment_log)
• v_person_effective_capabilities cachováno per-request → minimální DB overhead

Negativní / rizika:

• Stávající uživatelé nemají žádné role → po nasazení migrace nikdo nic neuvidí dokud se nepřiřadí role
• Admin musí mít system_admin roli přiřazenou manuálně v DB nebo přes budoucí Admin UI

Mitigace:

• Při první migraci přidat INSERT INTO rbac_person_role pro seed admin uživatele
• DbAuthorizator zůstává aktivní — přechod na requireCapability() je postupný per-presenter