Optimization for IAM-like policies #1689

CharlesPhilippeLabbe · 2026-01-23T15:31:57Z

CharlesPhilippeLabbe
Jan 23, 2026

Hello,
I'm trying to design an AWS IAM like system where we have a set of resources which you can "allow" or "deny" for certain roles and users.

My Initial was this:

Initial Option: Model

[request_definition]
r = sub, dom, obj, act

[policy_definition]
p = sub, obj, act, eft

[role_definition]
g = _, _, _ # Roles permission
g2 = _, _ # Data group
g3 = _, _ # Action group

[policy_effect]
# Allow as soon as there one rule allowing
#e = some(where (p.eft == allow))
#Deny as soon as there is one rule denying
e = some(where (p.eft == allow)) && !some(where (p.eft == deny))

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

Initial Option: Policy

# sub/perm, resource, action
p, perm:instance:list, /instance, READ, allow
p, perm:instance:delete, /instance/{name}, DELETE, allow
p, perm:instance:describe, /instance/{name}, READ, allow
p, perm:instance:create, /instance/{name}, POST, allow

p, perm:service:list, /service, READ, allow

p, perm:proxy:read, /proxy/{name}/*, READ, allow
p, perm:proxy:write, /proxy/{name}/*, WRITE, allow
p, perm:proxy:crashes, /proxy/{name}/crashes, READ, allow
p, block:proxy:crashes, /proxy/{name}/crashes, READ, deny

# Adding wild cards in the group does seem to add a lot of time when users grow
#
#g, role:instance:admin, perm:instance:*, *
#g, role:service:admin, perm:service:*, *
#g, role:proxy:admin, perm:proxy:*, *
#
g, role:instance:admin, perm:instance:list, *
g, role:instance:admin, perm:instance:delete, *
g, role:instance:admin, perm:instance:describe, *
g, role:instance:admin, perm:instance:create, *

g, role:service:admin, perm:service:list, *

g, role:proxy:admin, perm:proxy:read, *
g, role:proxy:admin, perm:proxy:write, *

g, role:instance:viewer, perm:instance:list, *
g, role:instance:viewer, perm:instance:describe, *

g, role:service:viewer, perm:service:list, *

g, role:proxy:viewer, perm:proxy:read, *
g, role:proxy:viewer, block:proxy:crashes, *

g, user:admin, role:instance:admin, *
g, user:admin, role:service:admin, *
g, user:admin, role:proxy:admin, *

g, user:alice, role:instance:admin, orgA
g, user:alice, role:service:admin, orgA
g, user:alice, role:proxy:admin, orgA

g, user:alice, role:instance:viewer, orgB
g, user:alice, role:service:viewer, orgB
g, user:alice, role:proxy:viewer, orgB

g, user:bob, role:instance:viewer, orgB
g, user:bob, role:service:viewer, orgB
g, user:bob, role:proxy:viewer, orgB

g, user:nancy, role:proxy:admin, orgA

g3, POST, WRITE
g3, PUT, WRITE
g3, PATCH, WRITE
g3, DELETE, WRITE

g3, OPTIONS, READ
g3, HEAD, READ
g3, GET, READ

g3, READ, ANY
g3, WRITE, ANY

I find it's not ideal because I would need to duplicate every p to have one for deny and one for allow.

So My second option is this:

Tentative Option; Model

[request_definition]
r = sub, dom, obj, act

[policy_definition]
p = sub, obj, eft, dom

[role_definition]
g = _, _, _ # Roles permission
g2 = _, _, _ # Data group
g3 = _, _ # Action group

[policy_effect]
# Allow as soon as there one rule allowing
#e = some(where (p.eft == allow))
#Deny as soon as there is one rule denying
e = some(where (p.eft == allow)) && !some(where (p.eft == deny))

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

Tentative Option; Policy

#
p, role:instance:admin, perm:instance:list, allow, *
p, role:instance:admin, perm:instance:delete, allow, *
p, role:instance:admin, perm:instance:describe, allow, *
p, role:instance:admin, perm:instance:create, allow, *
p, role:service:admin, perm:service:list, allow, *
p, role:proxy:admin, perm:proxy:read, allow, *
p, role:proxy:admin, perm:proxy:write, allow, *
p, role:instance:viewer, perm:instance:list, allow, *
p, role:instance:viewer, perm:instance:describe, allow, *
p, role:service:viewer, perm:service:list, allow, *
p, role:proxy:viewer, perm:proxy:read, allow, *
p, role:proxy:viewer, perm:proxy:crashes, deny, *
# sub/perm, resource, action
g2, /instance, perm:instance:list, GET
g2, /instance/{name}, perm:instance:delete, DELETE
g2, /instance/{name}, perm:instance:describe, GET
g2, /instance/{name}, perm:instance:create, POST
g2, /service, perm:service:list, GET
g2, /proxy/{name}/*, perm:proxy:read, GET
g2, /proxy/{name}/*, perm:proxy:write, POST
g2, /proxy/{name}/crashes, perm:proxy:crashes, GET


g, user:admin, role:instance:admin, *
g, user:admin, role:service:admin, *
g, user:admin, role:proxy:admin, *

g, user:alice, role:instance:admin, orgA
g, user:alice, role:service:admin, orgA
g, user:alice, role:proxy:admin, orgA

g, user:alice, role:instance:viewer, orgB
g, user:alice, role:service:viewer, orgB
g, user:alice, role:proxy:viewer, orgB

g, user:bob, role:instance:viewer, orgB
g, user:bob, role:service:viewer, orgB
g, user:bob, role:proxy:viewer, orgB

g, user:nancy, role:proxy:admin, orgA

Both work, but the first one is significantly (at least 8 times) faster for a few thousand checks. Is there a way for me to optimize option 2 or am I better off going with my initial design?

tlyyxjz · 2026-08-30T05:25:50Z

tlyyxjz
Aug 30, 2026

Hi! IAM-style allow/deny is one of the most common things people get stuck on with Casbin — I've been there too. Good news: you don't have to duplicate every p rule to support deny.

With a single eft field you can make deny override allow:

[policy_definition]
p = sub, dom, obj, act, eft

[policy_effect]
e = priority(p.eft) || deny

Then your policies become clean single rows:

p, alice, org1, doc:123, read, allow
p, alice, org1, doc:123, read, deny   # deny just wins

If you later need priority tiers (e.g. a global deny that always wins over a role allow), add p_priority as the last column and give deny rules a higher number.

The other common option — when deny should always win and you don't need priorities — is:

e = some(where (p.eft == allow)) && !some(where (p.eft == deny))

Either way you avoid the duplication you were worried about.

Out of curiosity (and because I'm collecting real-world config pain for a side project): would a small tool that lets you describe a rule in plain words — e.g. "user can read docs, role editor can write, banned team always denied" — and then auto-generates a correct model.conf + sample policy you can run & validate be useful to you? That's exactly the kind of thing I'm considering building, and it'd help to know what's been the hardest part for you and whether you'd actually use it. 🙂

0 replies

tlyyxjz · 2026-08-30T10:28:50Z

tlyyxjz
Aug 30, 2026

Great question — this is exactly the class of tradeoff people hit when building IAM-style models on Casbin, and your 8x measurement is a good tell. It's not that either model is "wrong"; the gap comes from one structural choice.

Why option 1 is faster

The dominant cost in a matcher is the g() graph lookup (role/domain inheritance is a BFS over the role graph). keyMatch5 / globMatch, by contrast, are just string/glob matching — no graph involved. With a few thousand policies, every g() you add to a row multiplies that cost across the whole scan.

Option 2 also makes obj a graph dimension via g2(r.obj, p.obj, r.act), so every row pays two graph lookups (g(sub) + g2(obj)) before it can reject a non-matching object. Option 1 keeps obj on keyMatch5 — cheap string matching with * / [...] wildcards — so a non-matching path is rejected on a string compare. That's where your 8x comes from.

A secondary factor: short-circuit order. Option 1 runs g3(r.act,p.act) (low-cardinality action space, prunes cheaply) before g(...). Option 2 leads with globMatch(r.dom,p.dom), but most of your rows have dom = *, so that predicate passes unconditionally and you fall straight into g() + g2().

Recommended model

Keep roles/domains on g, but move obj back to a matching function, and order predicates cheap-and-selective first:

[request_definition]
r = sub, dom, obj, act

[policy_definition]
p = sub, obj, act, eft

[role_definition]
g = _, _, _    # domain-scoped user -> role
g3 = _, _      # action mapping (HTTP -> CRUD)
# drop g2 entirely

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

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

Why this order: keyMatch5(r.obj, p.obj) is cheap and highly selective on paths, so it prunes most rows before any graph lookup; g3 on act is cheap (small action space); the expensive domain-scoped g() runs last, only on rows that already matched path + action. This keeps option 1's speed while avoiding the deny duplication you didn't like in option 2.

One structural warning about deny

Your effect mixes allow and deny. That's what prevents an early exit: a deny anywhere means the engine must scan every matching policy before it can conclude, so you lose part of the short-circuit win no matter how you order the matcher. If your IAM can express "deny by absence, allow explicitly", you can often drop the deny rows and use e = some(where (p.eft == allow)) — the fast early-exit path. Keep a hard deny only for cases that must override everything (e.g. your block:proxy:crashes).

Small note, happy to expand if useful. As a side project I'm exploring a small validator/generator that would flag this exact tradeoff ("obj shouldn't be a role-graph dimension — use a path matcher") while you're writing a model, and generate a working model from a plain description. If you'd use something like that, I'd welcome your input on the experience — I posted a short research thread at #1751.

1 reply

CharlesPhilippeLabbe Sep 10, 2026
Author

Great, thank you for the answer. I'll have to test it out when I have time.

Navigation Menu

Uh oh!

Optimization for IAM-like policies #1689

Uh oh!

{{title}}

Uh oh!

Replies: 2 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

Optimization for IAM-like policies #1689

Uh oh!

CharlesPhilippeLabbe Jan 23, 2026

Replies: 2 comments · 1 reply

Uh oh!

tlyyxjz Aug 30, 2026

Uh oh!

tlyyxjz Aug 30, 2026

Uh oh!

CharlesPhilippeLabbe Sep 10, 2026 Author

CharlesPhilippeLabbe
Jan 23, 2026

Replies: 2 comments 1 reply

tlyyxjz
Aug 30, 2026

tlyyxjz
Aug 30, 2026

CharlesPhilippeLabbe Sep 10, 2026
Author