Skip to content

CONCEPT Cited by 1 source

Permissions DSL

What it is

A permissions DSL is a dedicated domain-specific language for expressing authorization rules as data separate from application code. A rule declares at minimum:

  • Effect — allow or deny (with a resolution rule when both apply, typically deny overrides allow — see patterns/deny-overrides-allow).
  • Action(s) / permission(s) — what operation is gated.
  • Resource (type) — what the rule is about.
  • Condition — a boolean expression over attributes of the principal, resource, context.

The contrast class is if user.role == "admin" { allow } scattered through application code.

Why it matters

  • Isolation — adding a new rule doesn't require reasoning about every existing rule. Each rule is locally verifiable.
  • Granularity — rules can be non-hierarchical, context-aware, per-resource-attribute. Hierarchy + escape-flags ("level 300 access, but not level 100 + ignore_link_access: true") produces a matrix that pretends to be a hierarchy; a DSL can express the matrix directly.
  • Auditability — a single corpus of rules, not code scattered across N files.
  • Cross-platform — if the DSL is serializable (ideally as JSON), the same rule runs across services in different languages.
  • Static analysis — a language constrained enough to be parsed mechanically admits automated checks (patterns/policy-static-analysis-in-ci).

Canonical examples

Design axes

  • Hierarchical vs non-hierarchical — Figma's first model was hierarchical integer levels + boolean escape flags; failed because real policies are non-hierarchical.
  • Effect semantics — deny-overrides-allow is the common choice (IAM, Figma, Cedar).
  • Condition language — triples (field op value) composed by and/or/not is a common shape (patterns/expression-def-triples); regex / arbitrary expressions increase expressivity at the cost of analyzability.
  • Authoring surface vs storage format — Figma authors in TypeScript, stores in JSON; Cedar has its own surface syntax compiled to an AST.
  • Built-in vs pluggable data access — policy language should not embed database queries (concepts/data-policy-separation).

Caveats

  • Off-the-shelf permissions engines (OPA, Zanzibar, Oso, Cedar) may fit if the product's policy shape matches the engine's assumptions.
  • A custom DSL is a long-term investment — Figma still maintains three evaluators in three languages plus tooling (debuggers, linters) on top.

Seen in

Last updated · 200 distilled / 1,178 read