access-control-policy-design

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/