Portal Modules and Role Access

RBAC Matrix documents endpoint-level enforcement (which Keycloak realm role can call POST /v1/eligibility/determine, etc.). This page documents the UI surface — which screens / portal modules each role can access, and what each role can do inside each module.

The endpoint matrix is enforced at the API boundary (Claims::require_* helpers). The portal-module matrix is enforced at the route + render layer of canopy-web (Askama + Alpine.js). Both layers must agree — this page documents the contract.

Six roles per Keycloak realm, matching the endpoint matrix:

Notes:

canopy-portal is a shipped Dioxus 0.7 fullstack application, containerized on port 8090. Per ADR-008 / ADR-026 it authenticates applicants via reference number (HH-… code + passcode, no Keycloak roles) with Redis-primary opaque-token sessions — Postgres-free. The applicant role is mutually exclusive with worker-side roles. Module surface:

The lookup / apply / recover flows behind this matrix are live (Dioxus 0.7 fullstack, reference-number auth, Redis-primary sessions, containerized on 8090); this matrix is the authorization contract those flows enforce.

The matrix above was authored from the documentation-completeness plan’s source-of-truth table. Future portal additions (e.g., post-UAT TANF / Medicaid / CAPS / WIC modules) must add rows here AND update RBAC Matrix. The Antora nav.adoc lists this page under Operations.