Priority Model

Casbin підтримує завантаження політик з пріоритетом.

Завантаження політики з неявним пріоритетом

Це досить просто: порядок визначає пріоритет; політики, що з'являються раніше, мають вищий пріоритет.

model.conf:

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

Завантаження політики з явним пріоритетом

Також дивіться: casbin#550

Менше значення пріоритету вказує на вищий пріоритет. Якщо в пріоритеті є нечисловий символ, він буде розміщений в кінці, замість того, щоб викидати помилку.

Конвенція іменування токенів

Конвенційно використовуване ім'я токена пріоритету в означенні політики - "priority". Щоб використовувати своє, вам потрібно викликати e.SetFieldIndex() та перезавантажити політики (дивіться повний приклад на TestCustomizedFieldIndex).

model.conf:

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

Golang приклад коду:

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`

Наразі, явний пріоритет підтримує лише AddPolicy & AddPolicies. Якщо було викликано UpdatePolicy, вам не слід змінювати атрибут пріоритету.

model.conf:

[request_definition]
r = sub, obj, act

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

[role_definition]
g = _, _

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

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

policy.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 

Завантаження політики з пріоритетом на основі ієрархії ролей та користувачів

Успадкована структура ролей та користувачів може бути лише декількома деревами, а не графами. Якщо користувач має декілька ролей, ви повинні переконатися, що користувач має однаковий рівень у різних деревах. Якщо дві ролі мають однаковий рівень, політика (асоційована з роллю), що з'явилася раніше, має вищий пріоритет. Для більш детальної інформації також дивіться casbin#833 та 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 

policy.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

Ієрархія ролей виглядає так:

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

Пріоритет автоматично виглядає так:

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