Learn IAM
Learn IAM

Modeling Permissions & Entitlements

Modeling Permissions & Entitlements

Authorization fails most often at the modeling layer.

If you can’t describe resources, actions, and ownership cleanly, you will end up with:

  • hundreds of roles
  • inconsistent APIs (“admin” means different things)
  • brittle exceptions (“except when…”) baked into code

Start with a resource-action model

Define:

  • Resource types: org, project, repo, document, invoice
  • Actions: read, write, delete, invite, approve, export
  • Scopes of impact: tenant-wide vs project-wide vs object-specific

A good heuristic: actions should map to business outcomes, not UI buttons.

Roles vs attributes vs relationships

  • RBAC: great for stable job functions and coarse control.
  • ABAC: great when decisions depend on data (department, region, risk).
  • ReBAC: great when access is about links (member-of, owns, shares-with).

Many real systems blend them:

  • Use RBAC for admin boundaries.
  • Use ReBAC for product sharing.
  • Use ABAC for conditional constraints.

Entitlements: the “what” you grant

Entitlements can be:

  • a role (coarse)
  • a relationship tuple (fine)
  • a scoped permission (e.g., project:7:editor)

Choose a representation that supports:

  • review (humans can understand it)
  • audit (why does this exist?)
  • revocation (remove it safely)

Pitfalls

  • Using token claims as the source of truth (tokens are snapshots, not databases).
  • Letting every service invent its own permission vocabulary.
  • Not defining “owners” (who can delegate?)

Where to go next