From 2946369199349208904c4ce55258d368666eabca Mon Sep 17 00:00:00 2001 From: Satyam Rastogi Date: Fri, 29 May 2026 21:35:18 +0530 Subject: [PATCH] docs(plan8): frame ABAC layer as cosmetic frontend-only (real enforcement is backend, another team) --- docs/superpowers/2026-05-29-MASTER-PLAN.md | 2 +- docs/superpowers/plans/2026-05-29-plan8-abac-routing.md | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/superpowers/2026-05-29-MASTER-PLAN.md b/docs/superpowers/2026-05-29-MASTER-PLAN.md index 194db0c..ba3a810 100644 --- a/docs/superpowers/2026-05-29-MASTER-PLAN.md +++ b/docs/superpowers/2026-05-29-MASTER-PLAN.md @@ -534,4 +534,4 @@ Each plan = one phase, produces working/verifiable software on its own, and is e - **What:** an attribute-based policy engine (subject/resource/action/context attributes; ordered permit/deny; deny-wins; default-deny) generalizing the role/override data; `can(action, resource, ctx)` API; a permission-aware route guard; the Option-B unified route scheme (one human-readable route per feature, role landings only); nav hiding + styled Access Restricted page; Org Settings as policy/attribute editor. - **Why:** ABAC expresses ownership/assignment/territory rules RBAC can't (a rep edits only their projects; a sub sees only theirs) while still covering the simple "deny one admin / one agent read-only" asks — a credible enterprise-access story; folded with the route cleanup it also yields one obvious URL per feature. - **How:** a pure engine in `src/data/abac.js` (`evaluate` deny-wins/default-deny + `compilePolicies` folding the matrix + per-person overrides + resource-aware rules); `usePermissions` keeps `can(module,action)` (engine-backed, back-compatible) and adds resource-aware `canAccess(action, resource)`; a module-gated `ProtectedRoute` + Access Restricted page; resource gates on project detail; nav permission-hiding; then (separately, higher-risk) **consolidate `App.jsx`** to unified routes (with redirects from legacy paths) and strip `basePath` from 4 files. The friendly Org-Settings matrix already configures the engine (no new policy editor). **Phased so the ABAC core (low-risk wow) is shippable before the route-URL consolidation, which is deferrable.** Verify: rep blocked from editing a project they're not on; sub sees only theirs; denied direct-URL → Access Restricted; (Phase C) one route per feature, no `basePath` left. -- **Plan file:** `docs/superpowers/plans/2026-05-29-plan8-abac-routing.md`. **Note:** plan keeps `can(module,action)` + adds `canAccess(action,resource)` (rather than replacing the signature) to avoid breaking existing callers; ABAC engine lives in `src/data/abac.js` (not `utils/permissions.js`). +- **Plan file:** `docs/superpowers/plans/2026-05-29-plan8-abac-routing.md`. **Note:** plan keeps `can(module,action)` + adds `canAccess(action,resource)` (rather than replacing the signature) to avoid breaking existing callers; ABAC engine lives in `src/data/abac.js` (not `utils/permissions.js`). **Cosmetic/frontend-only** — a client-side demonstration of the access model against the mock store; real enforcement is backend (another team), so no auth/session/server policy plumbing. diff --git a/docs/superpowers/plans/2026-05-29-plan8-abac-routing.md b/docs/superpowers/plans/2026-05-29-plan8-abac-routing.md index c4e22cd..08aa784 100644 --- a/docs/superpowers/plans/2026-05-29-plan8-abac-routing.md +++ b/docs/superpowers/plans/2026-05-29-plan8-abac-routing.md @@ -24,6 +24,13 @@ - **Org Settings (`OrgSettings.jsx`):** `AccessControlMatrix` (iterates `PERMISSION_MODULES` × `orgRoles`, toggles via `updateOrgPermissions`) + `AccessControlPersonModal` (per-user overrides). **It already drives the data the engine will consume — so adding modules flows into it automatically.** - **Resource attributes:** project `ownerId`, `subcontractorIds[]`, `teamMembers[].userId`, `contractorId` (NO top-level `salesRepId` — rep is a teamMember with jobRole 'Sales Rep'); kanban lead `assignedAgentId`; sub task `subcontractorId`; **primary `leads` use `assignedTo` (name string) — needs `assignedAgentId` for ABAC.** `filterProjectsForUser` util already exists. +## Cosmetic / frontend-only (read first) + +This entire layer is a **client-side demonstration of the access model**, not a security boundary. The app is frontend-only (mock React-context store, no server — `/api/*` is stubbed). The **real policy enforcement is backend, owned by another team**; Plan 8 only makes the access story *demoable* in the UI: +- The engine, `canAccess`, route guard, nav-hiding, and the Org Settings matrix all run **in the browser against the mock store**. +- **No** backend calls, auth tokens, server policy checks, session validation, or "real" enforcement. Frontend gates are presentational (and bypassable) — that is acceptable and intended for the demo. +- Keep it **proportionate**: convincing, coherent UI behavior (nav hides, edits go read-only, Access Restricted shows, matrix toggles flip the UI live) over hardened security plumbing. Don't build auth/session/server infrastructure. + ## Scope & risk note (read first) - **Phases A–B (ABAC engine + guard + Access Restricted + nav hiding + resource rules)** are **additive and low-risk** — the demo "wow" (realistic enterprise access). They can ship and be reviewed independently.