Приоритетная модель

Casbin supports loading policies with priority.

Load Policy with Implicit Priority

It's quite simple: the order determines the priority; policies that appear earlier have higher priority.

модель.conf:

[policy_effect]
e = priority(p.eft) || Отклонить

Load Policy with Explicit Priority

Также посмотрите: casbin#550

A smaller priority value indicates a higher priority. If there's a non-numerical character in the priority, it will be placed last instead of throwing an error.

Token name convention

The conventionally used priority token name in the policy definition is "priority". To use a custom one, you need to invoke e.SetFieldIndex() and reload the policies (see the full example on TestCustomizedFieldIndex).

модель.conf:

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

Golang code example:

e, _ := NewEnforcer("./example/priority_model_explicit_customized.conf",
                    "./example/priority_policy_explicit_customized.csv")
// Due to the customized priority token, the enforcer fails to handle the priority.
ok, err := e.Enforce("bob", "data2", "read") // the result will be `true, nil`
// Set PriorityIndex and reload
e.SetFieldIndex("p", constant.PriorityIndex, 0)
err := e.LoadPolicy()
if err != nil {
    log.Fatalf("LoadPolicy: %v", err)
}
ok, err := e.Enforce("bob", "data2", "read") // the result will be `false, nil`

Currently, explicit priority only supports AddPolicy & AddPolicies. If UpdatePolicy has been called, you shouldn't change the priority attribute.

модель.conf:

[request_definition]
r = под, obj, действовать

[policy_definition]
p = приоритет, sub, obj, act, eft

[role_definition]
g = _, _

[policy_effect]
e = priority(стр. ft) || Отрицать

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

политика.csv

p, 10, data1_deny_group, data1, read, deny
p, 10, data1_deny_group, data1, write, deny
p, 10, data2_allow_group, data2, read, allow
p, 10, data2_allow_group, data2, write, allow


p, 1, alice, data1, write, allow
p, 1, alice, data1, read, allow
p, 1, bob, data2, read, deny

g, bob, data2_allow_group
g, alice, data1_deny_group

запрос:

alice, data1, write --> true // because `p, 1, alice, data1, write, allow` has the highest priority
bob, data2, read --> false
bob, data2, write --> true // because bob has the role of `data2_allow_group` which has the right to write data2, and there's no deny policy with higher priority 

Загрузить политику с приоритетом на основе роли и иерархии пользователей

Унаследованная структура ролей и пользователей может быть только несколькими деревьями, а не графиками. If a user has multiple roles, you have to make sure the user has the same level in different trees. If two roles have the same level, the policy (associated with the role) that appeared earlier has higher priority. For more details, also see casbin#833 and casbin#831.

model.conf:

[request_definition]
r = sub, obj, act

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

[role_definition]
g = _, _

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

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

политика.csv

p, root, data1, read, deny
p, admin, data1, read, deny

p, editor, data1, read, deny
p, subscriber, data1, read, deny

p, jane, data1, read, allow
p, alice, data1, read, allow

g, admin, root

g, editor, admin
g, subscriber, admin

g, jane, editor
g, alice, subscriber 

Запрос:

jane, data1, read --> true // because jane is at the bottom, her priority is higher than that of editor, admin, and root
alice, data1, read --> true

The role hierarchy looks like this:

role: root
 └─ role: admin
    ├─ role editor
    │  └─ user: jane
    │
    └─ role: subscriber
       └─ user: alice

The priority automatically looks like this:

role: root                 # auto priority: 30
 └─ role: admin            # auto priority: 20
     ├─ role: editor       # auto priority: 10
     └─ role: subscriber   # auto priority: 10