Add priority policy element support

[wndrr101]

Hello,

It seems that I stuck in the middle with trivial issue. Hope you'll help me with a guidance.
Trying to build a model for REST API authorisation with an option to override "parent" permission.

Option 1

Test model:

[request_definition]
r = subj, obj, act

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

[role_definition]
g = _, _

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

[matchers]
m = (g(r.subj, p.subj) || (r.subj == p.subj)) && regexMatch(r.obj, p.obj) && regexMatch(r.act, p.act)

Test policy:

p, alice, /foo/bar/.+/.+baz.+, GET, allow
p, alice, /foo/bar/.+/baz$, GET, deny
p, alice, /foo/bar/.+, GET, allow
p, alice, /foo/bar.+, GET, deny
p, alice, /foo/bar$, GET, allow
p, alice, /foo/.+, GET, deny
p, alice, /foo.+, GET, deny
p, data2_admin, /foo$, GET, allow
p, alice, /.+, GET, deny

g, alice, data2_admin

Test requests:

alice, /zed, GET
alice, /zed, POST

alice, /foo, GET
data2_admin, /foo, GET
alice, /foo-bar, GET
alice, /foo/zed, GET
alice, /foo/bar, GET
alice, /foo/bar-zed, GET
alice, /foo/bar/zed, GET

alice, /foo/bar/*/baz-q, GET
alice, /foo/bar/zed/baz, GET

alice, /foo/bar/*/*baz*, GET
alice, /foo/bar/zed/aaa-baz=val, GET

Everything woks as expected BUT the longest (most precise) rule should be added on top of rules list.
So, "priority" needs to be in place in particular here:

1. p, alice, /foo/bar/.+/.+baz.+, GET, allow
2. p, alice, /foo/bar/.+/baz$, GET, deny
3. p, alice, /foo/bar/.+, GET, allow

for

alice, /foo/bar/*/baz-q, GET ---> true
alice, /foo/bar/zed/baz, GET ---> false

How should be and addition of any new more specific rule handled if there is no option for "numbered insertion" for any new particular rule? For example there is a new REST API endpoint and new authorisation rule needed.
Let's say I need "rule zero on top of existing list"

0. p, alice, /foo/bar/.+/.+baz-q$, GET, deny
1. p, alice, /foo/bar/.+/.+baz.+, GET, allow
2. p, alice, /foo/bar/.+/baz$, GET, deny
3. p, alice, /foo/bar/.+, GET, allow

Should it be done aside of Casbin and then policy reloaded forcibly by Casbin server? Or there is more convenient way?
p.s. actually it is somewhat alike to #290

Option 2

Everything is the same but Effector is "allow-override"

Test model:

[request_definition]
r = subj, obj, act

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

[role_definition]
g = _, _

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

[matchers]
m = (g(r.subj, p.subj) || (r.subj == p.subj)) && regexMatch(r.obj, p.obj) && regexMatch(r.act, p.act)

Test policy:

p, alice, /foo/bar/.+/.+baz.+, GET, allow
p, alice, /foo/bar/.+/baz$, GET, deny
p, alice, /foo/bar/.+, GET, allow
p, alice, /foo/bar.+, GET, deny
p, alice, /foo/bar$, GET, allow
p, alice, /foo/.+, GET, deny
p, alice, /foo.+, GET, deny
p, data2_admin, /foo$, GET, allow
p, alice, /.+, GET, deny

g, alice, data2_admin

Test requests:

alice, /zed, GET
alice, /zed, POST

alice, /foo, GET
data2_admin, /foo, GET
alice, /foo-bar, GET
alice, /foo/zed, GET
alice, /foo/bar, GET
alice, /foo/bar-zed, GET
alice, /foo/bar/zed, GET

alice, /foo/bar/*/baz-q, GET
alice, /foo/bar/zed/baz, GET

alice, /foo/bar/*/*baz*, GET
alice, /foo/bar/zed/aaa-baz=val, GET

With this Effector in place result is different:

alice, /foo/bar/*/baz-q, GET ---> true
alice, /foo/bar/zed/baz, GET ---> true

Second request is improperly (or am I wrong?) rendered to "true" also.
And here I think it would be nice to be able to choose "longest/precise match", that is request

/foo/bar/zed/baz

described more precisely by the

/foo/bar/.+/baz$

regex rule rather than

/foo/bar/.+/.+baz.+

What I try to achieve is that no matter the order of the policy rules examined, most precise rule should be chosen as a result.
or
Ability to re-balance policy rules list during create/update/delete operations with those rules to comply with "priority eft".

Or did I chose effector and matcher in a wrong way?

---

Any input would be appreciated.
Thanks.

---

IssueHunt Summary

closetool has been rewarded.

Backers (Total: $21.00)

• hsluoyz ($1.00)
• $20.00 have been anonymously funded.

Submitted pull Requests

• #714 feat: add priority support(#550)

---

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[hsluoyz]

@wndrr101 very good question. I think Option 1 would be easier. We should add a new column for rules called "priority number". It works very similar to classic firewall rules:

Rules are processed in priority order; the lower the number, the higher the priority. We recommend leaving gaps between rules - 100, 200, 300, etc. - so that it's easier to add new rules without having to edit existing rules.

@nodece @dovics @00LT00 can you do it?

[hsluoyz]

@00LT00 please work on this issue.

[00LT00]

I'm trying to do

[00LT00]

@nodece @wndrr101 Hi, I'm trying to add priorityID for the policy. Now I have some problems.

1. is the new column priorityID optional? front or back?
2. can priority be equal?

[wndrr101]

Hello @00LT00,

Here is my 2c:

1. is the new column priorityID optional? front or back?
   it might be optional on my opinion, if it's optional than req_definition and pol_definition should be created new verb line "num"

[request_definition]
r = num, subj, obj, act

no "num" - no numbered priority

"front or back?"
didn't get what you mean.

2. can priority be equal?
   Don't think so. What would be "choosing function" in this case with same prioriries? It's like now.

---

While I'm using now my own hack for pycasbin (just length sort WHEN saving policy with AUTO_SAVE disabled) I've found one moment worth to consider:
one should also number properly "user's rules" and "group's rules"

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

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

[role_definition]
g = _, _, _

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

[matchers]
m = (((r.sub == p.sub) || g(r.sub, p.sub, r.dom)) && r.dom == p.dom && regexMatch(r.obj, p.obj) \
&& regexMatch(r.act, p.act)) || ((g(r.sub, "root", p.dom) || r.sub == "admin") && r.dom == p.dom)

Test policy:

p, domain1, data2_admin, /foo$, GET, allow
p, domain1, alice, /foo$, GET, deny
p, domain1, root, /foo$, GET, deny
p, domain1, alice, /.+, GET, deny

g, alice, data2_admin, domain1
g, bob, root, domain1

As you can see, Alice is in group data2_admin.
If rules for data2_admin would be (un-)intentionally set before Alice's rules, they would be evaluated first, like in case above.

And here

domain1, alice, /foo, GET
domain1, data2_admin, /foo, GET

first rule would be evaluated as True. But it should be False if we're tend to think that user is more specific than group.
It might be semi-auto like any Group/Role's rules are numbered after User's OR it may be left on dev/admin discretion.

--
thanks

[00LT00]

@hsluoyz @nodece @dovics What do you think about the Group/Role's rules? I feel a little too complicated.

[hsluoyz]

@nodece @GopherJ @xcaptain

[nodece]

@wndrr101 very good question. I think Option 1 would be easier. We should add a new column for rules called "priority number". It works very similar to classic firewall rules:

Rules are processed in priority order; the lower the number, the higher the priority. We recommend leaving gaps between rules - 100, 200, 300, etc. - so that it's easier to add new rules without having to edit existing rules.

@nodece @dovics @00LT00 can you do it?

@00LT00 This is good idea, but I also know it is quite complex, so I recommend starting with #546, because I don't think our data struct of policy can supports the feature.

maybe the best work for you on Summer 2020.

what do you think?

[nodece]

Hello @00LT00,

Here is my 2c:

1. is the new column priorityID optional? front or back?
   it might be optional on my opinion, if it's optional than req_definition and pol_definition should be created new verb line "num"

[request_definition]
r = num, subj, obj, act

no "num" - no numbered priority

"front or back?"
didn't get what you mean.

1. can priority be equal?
   Don't think so. What would be "choosing function" in this case with same prioriries? It's like now.

While I'm using now my own hack for pycasbin (just length sort WHEN saving policy with AUTO_SAVE disabled) I've found one moment worth to consider:
one should also number properly "user's rules" and "group's rules"

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

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

[role_definition]
g = _, _, _

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

[matchers]
m = (((r.sub == p.sub) || g(r.sub, p.sub, r.dom)) && r.dom == p.dom && regexMatch(r.obj, p.obj) \
&& regexMatch(r.act, p.act)) || ((g(r.sub, "root", p.dom) || r.sub == "admin") && r.dom == p.dom)

Test policy:

p, domain1, data2_admin, /foo$, GET, allow
p, domain1, alice, /foo$, GET, deny
p, domain1, root, /foo$, GET, deny
p, domain1, alice, /.+, GET, deny

g, alice, data2_admin, domain1
g, bob, root, domain1

As you can see, Alice is in group data2_admin.
If rules for data2_admin would be (un-)intentionally set before Alice's rules, they would be evaluated first, like in case above.

And here

domain1, alice, /foo, GET
domain1, data2_admin, /foo, GET

first rule would be evaluated as True. But it should be False if we're tend to think that user is more specific than group.
It might be semi-auto like any Group/Role's rules are numbered after User's OR it may be left on dev/admin discretion.

--
thanks

@wndrr101 I guess #496 can solve the question. could you upgrade casbin to v2.10.0 and using e = some(where (p_eft == allow)) || !some(where (p_eft == deny)) as policy_effect?

[issuehunt-oss]

@hsluoyz has funded $1.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[issuehunt-oss]

An anonymous user has funded $20.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.