--- name: access-control-policy-design description: > USE THIS SKILL whenever any topic related to access control, authorization, permissions, or security policy arises in any form. Triggers include — but are not limited to: RBAC, ABAC, PBAC, ACL, DAC, ReBAC, Zanzibar, OPA, Cedar, Casbin, SpiceDB, OpenFGA, Permify, Oso, Cerbos, Permit.io; any mention of "who can do what", "role", "permission", "policy", "authorization", "multi-tenant access", "least privilege", "Zero Trust", "IAM design", "SaaS permission modeling", "access audit", "compliance access control" (HIPAA, GDPR, SOC2, PCI-DSS, ISO27001); also trigger when designing any new feature that controls what users can see or do, or when reviewing, refactoring, or debugging any auth/authz system. When in doubt — trigger this skill. Access control is architectural and getting it wrong is expensive. --- # Access Control Policy Design — Skill Navigator ## What this skill does Acts as a senior IAM/authorization architect. Covers all major access control paradigms, hybrid composition patterns, policy engines, compliance mapping, implementation code, and decision frameworks for modern apps (SaaS, multi-tenant, microservices, cloud-native). --- ## Core Mental Model (always apply this first) Every access control system answers one runtime question: > **Should subject S perform action A on resource R right now?** Models differ in *how* that decision is made. They are **layers, not competitors**: | Layer | Model | Answers | |-------|-------|---------| | Structure | RBAC | Who are you organizationally? | | Context | ABAC | What conditions apply right now? | | Governance | PBAC | Who controls the rules and how? | | Relationships | ReBAC | How do entities connect to resources? | | Precision | ACL | What's explicitly allowed on this object? | | Delegation | DAC | What has the owner chosen to share? | **Key principle:** Most mature systems use 3–4 of these together, with PBAC as the governance shell wrapping the others. Start simple (RBAC), add layers as complexity demands. --- ## Quick Decision Matrix | Scenario | Recommended Model(s) | Reference File | |----------|----------------------|----------------| | Internal tool, stable job roles | RBAC | `01-rbac.md` | | Multi-tenant SaaS | RBAC + ABAC | `01-rbac.md`, `02-abac.md` | | Healthcare / Finance data | ABAC + PBAC | `02-abac.md`, `03-pbac-opa.md` | | Collaborative hierarchical content | ReBAC | `04-rebac-zanzibar.md` | | Object-level sharing exceptions | ACL on top of RBAC | `05-acl-dac.md` | | Consumer app with owner sharing | DAC + guardrails | `05-acl-dac.md` | | Many microservices, many teams | PBAC (OPA/Cedar) | `03-pbac-opa.md` | | Zero Trust architecture | RBAC + ABAC + PBAC | `06-hybrid-patterns.md` | | SOC2 / HIPAA / GDPR compliance | PBAC + audit trail | `08-compliance.md` | | Early-stage startup (<50 users) | RBAC only | `01-rbac.md` | --- ## Reference Files (load the relevant one per task) ``` references/ ├── 01-rbac.md — RBAC deep dive: design, role taxonomy, anti-patterns, OPA/Casbin code ├── 02-abac.md — ABAC deep dive: attribute schema, OPA Rego policies, XACML, JWT patterns ├── 03-pbac-opa.md — PBAC + OPA/Cedar/Casbin: policy-as-code, engine selection, CI/CD ├── 04-rebac-zanzibar.md — ReBAC/Zanzibar: SpiceDB, OpenFGA, schema design, dual-write patterns ├── 05-acl-dac.md — ACL + DAC: when to use, guardrails, combining with RBAC ├── 06-hybrid-patterns.md — Layered defense, multi-tenant patterns, Zero Trust, evolution arc ├── 07-policy-engines.md — Engine comparison matrix: OPA vs Cedar vs Casbin vs SpiceDB vs Permify ├── 08-compliance.md — HIPAA, GDPR, SOC2, PCI-DSS, ISO27001 — exact mapping + audit schema └── 09-code-examples.md — Ready-to-use code: Python, Node.js, Go across all models ``` **When to load which file:** - User asks about a specific model → load that model's reference file - User asks about implementation / code → load `09-code-examples.md` + model file - User asks about tool/engine selection → load `07-policy-engines.md` - User asks about compliance → load `08-compliance.md` - User is designing multi-tenant or microservices → load `06-hybrid-patterns.md` - User is debugging broken access / role explosion → load `06-hybrid-patterns.md` §Warning Signs --- ## Evolution Arc (how real systems grow) ``` Phase 1 — Early product: RBAC (Admin / User / Viewer). Fast, auditable. Phase 2 — Multi-tenant: RBAC + ABAC (tenant_id attribute, conditional access). Phase 3 — Multiple services: PBAC layer (OPA/Cedar policy engine, decoupled from code). Phase 4 — Collaborative: ReBAC (hierarchical resource ownership + sharing graph). Phase 5 — Enterprise/regulated: Full hybrid — RBAC+ABAC+PBAC+ReBAC, audit logging, access certification, anomaly detection. ``` --- ## Universal Rules (apply regardless of model chosen) 1. **Deny by default** — explicit ALLOW, implicit DENY everywhere 2. **Enforce server-side** — UI hints only; never trust client-side permission checks 3. **Log every decision** — allow AND deny, with subject/action/resource/reason/timestamp 4. **Least privilege** — grant minimum access required; time-bound temporary elevations 5. **Version policies** — treat authorization rules as code: review, test, deploy, roll back 6. **Quarterly access reviews** — permissions rot without active curation 7. **Test both allow and deny** — missing a deny test is a security gap --- ## Warning Signs (diagnose broken access control fast) | Symptom | Root Cause | Fix | |---------|------------|-----| | Role count doubles every quarter | RBAC role explosion | Introduce ABAC attributes | | "We have a role for that" for every edge case | RBAC over-stretch | ABAC conditions | | Different services enforce the same rule differently | Authorization scatter | PBAC engine | | Can't answer "who has access to X?" | ACL sprawl | Centralize with PBAC | | Audit takes days to compile | No central access log | Structured decision logging | | Access doesn't revoke when user changes teams | Role creep | Access certification process | | Sharing causes accidental data exposure | Unbounded DAC | DAC guardrails / boundaries | | One engineer understands all the auth rules | ABAC policy sprawl | PBAC + documentation | --- ## Two-Question Clarity Test **Q1: What will be harder in 6 months — explaining access decisions, or changing them safely?** - Hard to *explain* → ABAC/PBAC + visibility tooling - Hard to *change safely* → PBAC governance layer before system becomes brittle **Q2: Does "same action" need different decisions based on context?** - YES → ABAC is mandatory - NO → Pure RBAC may be sufficient for now ## Online Sources - https://www.loginradius.com/blog/identity/how-access-control-models-work - https://www.openpolicyagent.org/docs/comparisons/access-control-systems - https://www.osohq.com/learn/abac-with-open-policy-agent-opa - https://authzed.com/learn/google-zanzibar - https://authzed.com/docs/spicedb/concepts/zanzibar - https://github.com/openfga - https://auth0.com/blog/how-to-choose-the-right-authorization-model-for-your-multi-tenant-saas-application - https://www.permit.io/blog/authorization-with-open-policy-agent-opa - https://www.styra.com/blog/enforcing-role-based-access-control-rbac-policies-with-opa/