Prioritätsmodell

Casbin unterstützt Laststrategien mit Priorität.

Richtlinie mit Priorität laden implizit

Es ist ganz einfach, die Ordnung bestimmt die Priorität, die Politik früher erschienen hat höhere Priorität.

model.conf:

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

Richtlinien mit Priorität explizit laden

Siehe: casbin#550

The smaller priority value will have a higher priority. If there's a non-numerical character in priority, it will be in the last, rather than throw an error.

Token name convention

The priority token name in policy definition is "priority" conventionally. A customized one requires invoking e.SetFieldIndex() and reload policies (full example on TestCustomizedFieldIndex ).

model.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 failed 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`

Nun unterstützt explizite Priorität nur AddPolicy & AddPolicies, falls UpdatePolicy aufgerufen wurde, sollten Sie das Prioritätsattribute nicht ändern.

model.conf:

[request_definition]
r = sub, obj, act

[policy_definition]
p = Priorität, sub, obj, act, eft

[role_definition]
g = _, _

[policy_effect]
e = priority(p. ft) || lehne

[matchers]
m = g(r.sub, p. ub) && 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

anfragen:

alice, data1, write --> true // für `p, 1, alice, data1, write, write allow` hat die höchste Priorität
bob, data2, read --> false
bob, data2, write --> true // für bob hat die Rolle von `data2_allow_group` welche das Recht hat, Daten zu schreiben, und es gibt keine leugnen Richtlinie mit höherer Priorität 

Richtlinien mit Priorität basierend auf Rolle und BenutzerHierarchie laden

Die geerbte Struktur von Rollen und Benutzern kann nur mehrere Bäume und nicht Graphen. Wenn ein Benutzer mehrere Rollen hat, müssen Sie sicherstellen, dass der Benutzer das gleiche Level in verschiedenen Bäumen hat. Wenn zwei Rollen die gleiche Ebene haben, hat die Politik (die Rolle korrespondierend) eine höhere Priorität. weitere Details siehe casbin#833casbin#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 

Anfrage:

jane, data1, read --> true // jane steht ganz unten. Die Priorität ist also höher als der Editor, admin und root
alice, data1, lesen --> true

Die Rollenhierarchie wie folgt:

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

Die Priorität automatisch folgendermaßen:

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