Define your access matrix
in under 60 seconds.

Quick-decision grid: RBAC vs ABAC vs PBAC

RBAC is the default starting point. Add ABAC when role explosion sets in (you have 50+ roles to express simple distinctions like "engineer in EU region"). Move to PBAC or ReBAC when access logic involves complex policy or graph-shaped relationships (Google Drive sharing, GitHub repo permissions).

Standard permission verbs (CRUD + extensions)

The read / create / update / delete core (plus list) covers ~80% of business application permissions. Reach for the others when the domain genuinely needs them.

Template 1: SaaS B2B app (4 roles × 8 permissions)

Common starting point for multi-tenant SaaS. Each customer has their own tenant; users inside a tenant have one of these roles.

Owner is exactly one user per tenant. Admin can manage users but not billing (so a fired admin can't remove the credit card). Member is the working role most users have. Viewer is read-only; useful for stakeholders who shouldn't edit.

Template 2: Content management system (5 roles × 10 permissions)

Editorial workflow with draft/review/publish stages.

Mirrors WordPress's role structure. Contributor can write but not publish (Editor must approve). Author can publish their own posts but not others'.

Template 3: E-commerce platform (4 roles × 12 permissions)

Storefront with order management and customer service workflows.

Customer Service can refund and cancel orders but can't adjust inventory directly (prevents fraud). Fulfillment can adjust inventory (mark items as picked/shipped) but can't issue refunds.

Template 4: Internal corporate tool (5 roles × 8 permissions)

Read-mostly internal app with departmental access scoping.

"Dept-scoped" indicates a permission that requires ABAC layering on top of the role; the role grants access only within the user's department, evaluated at runtime against the resource's department attribute.

Template 5: Kubernetes RBAC (4 roles × verbs on resources)

Kubernetes RBAC binds verbs (get/list/watch/create/update/patch/delete) to API resources (pods, deployments, secrets) inside a namespace. This matrix is the source for the rules: block of a Role or ClusterRole. Cells list the verbs granted on that resource.

In Kubernetes the matrix is verbs-per-resource rather than a single boolean. * denotes all verbs (a ClusterRole). developer is a namespaced Role with no access to secrets. ci-deployer gets the narrow patch/update set a CI pipeline needs to roll out images, plus read-only secrets for pulling registry credentials. Each non-empty cell becomes one rules entry: {apiGroups, resources, verbs}.

Template 6: API / microservices roles × OAuth scopes (5 roles × 9 scopes)

For a service-to-service or public API, the "permission" axis is OAuth2 scopes (resource:action) and the "role" axis is client/token type. This matrix is the source for the scopes you stamp into a JWT or grant to an API key.

Each row maps to one OAuth scope string. backend-service is a trusted machine token with near-full access; mobile-app can only write its own user record; partner-api gets a narrow, often rate-limited slice; public-readonly is anonymous read access. Stamp the granted scopes as the scope claim of the access token and check them in middleware.

Markdown (paste-ready for GitHub/wiki)

| Permission | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
| account.read | ✓ | ✓ | ✓ | ✓ |
| account.update | ✓ | ✓ | | |
| billing.read | ✓ | ✓ | | |
...

CSV (paste-ready for spreadsheets)

Permission,Owner,Admin,Member,Viewer
account.read,1,1,1,1
account.update,1,1,0,0
billing.read,1,1,0,0
billing.update,1,0,0,0

JSON (paste-ready for code)

{
  "roles": ["Owner", "Admin", "Member", "Viewer"],
  "permissions": ["account.read", "account.update", "billing.read", "billing.update"],
  "matrix": {
    "account.read":   { "Owner": true, "Admin": true,  "Member": true,  "Viewer": true  },
    "account.update": { "Owner": true, "Admin": true,  "Member": false, "Viewer": false },
    "billing.read":   { "Owner": true, "Admin": true,  "Member": false, "Viewer": false },
    "billing.update": { "Owner": true, "Admin": false, "Member": false, "Viewer": false }
  }
}

NIST RBAC reference (formal model)

For projects that need to align with the NIST INCITS 359-2004 RBAC standard:

Most application-level RBAC implementations operate at RBAC₀ or RBAC₁. Higher levels are typically enforced by enterprise identity systems (Okta, Azure AD) rather than application code.

Worked example: a small RBAC matrix

Take this 3-role × 3-permission matrix on the posts object. The mapping below turns each checked cell into one Casbin policy line.

Each ✓ becomes a p (policy) line of p, role, object, action. Role-to-user assignment lives in separate g (grouping) lines.

model.conf: RBAC grammar (request / policy / role / matchers)

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act

policy.csv: one p line per checked cell, plus g lines for role assignment

# p, role, object, action: one line per checked cell
p, admin,  posts, read
p, admin,  posts, write
p, admin,  posts, delete
p, editor, posts, read
p, editor, posts, write
p, viewer, posts, read

# g, user, role: role assignment (the "g" grouping lines)
g, alice, admin
g, bob,   editor
g, carol, viewer