Auth & Security · 07 Fine-Grained Permissions

Four groups of facts, one decision

"Editors may edit drafts in their own department during office hours" — that rule needs all four.

SUBJECT

id 8 · role editor
dept sales · grants []

ACTION

edit

RESOURCE

owner 7 · dept sales
status draft

ENVIRONMENT

time 11:00
(also: IP, device…)

→

POLICY · first match wins

✓ admin → anything

✗ publish without grant

✗ published → read-only

✓ same dept can read

✓ owner edits own draft

✓ editor · same dept · 9–18h

✓ granted publisher · same dept

· default deny

→

ALLOWeditor, same dept, office hours

at 22:00 → DENYdefault deny

RBAC

ABAC

decides on

role only

subject + action + resource + context

rule example

moderators delete posts

editors edit own-dept drafts, 9–18h

complexity

tiny map

policy you must test

use when

coarse, app-wide access

rules depend on the data or the moment

A policy is a list of rules, checked in order

Each rule matches or doesn't; the first match decides; nothing matching means no.

internal/authz/policy.go

type Req struct {
    Sub Subject   // id, role, dept, grants
    Act string    // "read", "edit", "publish"
    Res Resource  // owner, dept, status
    Now time.Time // environment
}

type Rule struct {
    Name  string
    Match func(q Req) bool
    Allow bool
}

var policy = []Rule{
    {"publish needs explicit grant", func(q Req) bool {
        return q.Act == "publish" &&
            !slices.Contains(q.Sub.Grants, "doc:publish")
    }, false},
    {"owner edits own draft", func(q Req) bool {
        return q.Act == "edit" && q.Sub.ID == q.Res.OwnerID
    }, true},
    // … 5 more rules
}

func Decide(q Req) (bool, string) {
    for _, rule := range policy {
        if rule.Match(q) {
            return rule.Allow, rule.Name
        }
    }
    return false, "default deny"
}

go run ./demos/07

asha  edit    draft     @11:00 → ALLOW  (owner edits own draft)
ravi  edit    draft     @11:00 → ALLOW  (editor, same dept, office hours)
ravi  edit    draft     @22:00 → DENY   (default deny)
omar  edit    draft     @11:00 → DENY   (default deny)
ravi  publish draft     @11:00 → DENY   (publish needs explicit grant)
lead  publish draft     @11:00 → ALLOW  (granted publisher, same dept)
asha  edit    published @11:00 → DENY   (published docs are read-only)
omar  read    published @11:00 → DENY   (default deny)

go run ./demos/07order · same rules, "read-only" moved below "owner edits"

asha  edit    published @11:00 → ALLOW  (owner edits own draft)
# one swapped line — and a published doc is editable again

→Deny rules go first. Order is part of the policy — the second run proves it.

→Explicit grants (doc:publish) give one user a power their role doesn't have — store them in a user_permissions table.

→Return the rule name with the decision and log it — "why was I denied?" becomes answerable.

✓The table above is your test suite: one row per case, run on every change.

Three layers, each asking a narrower question

Most APIs need RBAC and ownership; add ABAC only where a rule depends on the data.

Role / permissionMay this kind of user do this at all?

RequirePerm · 05

OwnershipIs this particular row theirs?

OwnerOrAdmin · 06

AttributesGiven its state and the moment — still yes?

Decide(q) · 07

→Layers 1–2 fit in middleware. Layer 3 usually needs the loaded resource, so it runs in the service.

→Keep every check in one authz package — never scattered if user.Role == … in handlers.

TASK

Write — and break — a policy

Implement the 7 rules and the 8 cases above as a table-driven test.
Add: "nobody edits after a doc is archived". Where must it go in the list?
Swap two rules on purpose and watch which test fails.

Four groups of facts, one decision

A policy is a list of rules, checked in order

Three layers, each asking a narrower question

Write — and break — a policy

Session 07 in four lines