Implement cross-domain role inheritance: g, admin, developer, domain1, domain2

[rrasulzade]

Hi there,

I'm building an RBAC system with domains. There are some constraints: Users are admins associated with permissions in an organization. Each organization can have multiple partner organizations. Once a partnership is established, admin users in both organizations will need to have permission to access the resources of the partner organization. The desired behaviour is to give permissions to existing admin users in orgA to access the child orgB domain.

For example, let's say Alice and Eve have super_admin roles in orgA. OrgB is a sub-organization of orgA. In this scenario, how can I give developer role to Alice and Eve to access orgB data in the most efficient way?

p, role::admin, data1, read
p, role::developer, data1, write

g, role::super_admin, role::developer, *
g, role::super_admin, role::admin, *

g, alice, role::super_admin, domain::orgA
g, eve, role::super_admin, domain::orgA
g, bob, role::super_admin, domain::orgB
g, chris, role::admin, domain::orgB 

I'm trying not to introduce new rules explicitly for Alice and Eve. Because if orgA has dozens of admins and sub-organizations then it'll cause an overhead to assign new permission to each admin for each child organization. Also if any of the admins decide to delete their account, it'll be an expensive operation to clean up all policy entries for those users. So I'm trying to minimize user to policy mapping in casbin rules database.

---

IssueHunt Summary

Backers (Total: $0.00)

Become a backer now!

Or submit a pull request to get the deposits!

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]

@nodece @GopherJ @dovics

[nodece]

@rrasulzade Please upgrade latest version then read the https://casbin.org/docs/en/rbac#use-pattern-matching-in-rbac.

[rrasulzade]

thanks @nodece yes, I'm aware of the new domain pattern matching feature and that's how I'm using

g, role::super_admin, role::developer, *
g, role::super_admin, role::admin, *

But my question isn't about modelling the given policy example above. It's related to cross-domain access. The challenge I'm facing is how to assign external roles to members of domain::orgA (Alice and Eve) to give permission to access domain::orgB once orgB and orgA become partner organizations? Also need to keep in mind the constraints I have above

[dovics]

@rrasulzade Currently, Casbin does not support inheritance relationships between domains, This feature may require adding the new model syntax and needs to be discussed. maybe yuo can try using /orgA/orgB instead

[hsluoyz]

@rrasulzade we can use g, admin, developer, domain1, domain2 to declare that the admin role in domain1 will inherit the permissions of the developer role in domain2.

[hsluoyz]

Can anyone take this issue? @nodece @GopherJ @techoner @BetaCat0 @00LT00 @dovics @438561537 @yahoo17

[rrasulzade]

@hsluoyz I introduced a term group to collect all admin users of a certain organization (domain). Using rbac hierarchy and domain matching features, I can create partnership connections between domains. I defined these groups under global domain with *, so using KeyMatch2 can connect 2 different domains through a globally accessible group. There's a certain naming format for the group as well, so I can easily look it up and generate dynamic cross-domain inheritance, i.e group::domain1::admins
This will temporarily solve my cross-domain issue but it'd be great if Casbin can support this implicitly.
Please take a look at the example below.

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

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _, _

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

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

p, role::admin, data1, read|write
p, role::admin, data2, read|write
p, role::developer, data3, read|write
p, role::developer, data4, read|write
p, role::partner, data1, read
p, role::partner, data4, read

g, role::superadmin, role::developer, *
g, role::superadmin, role::admin, *

g, alice, role::superadmin, domain1
g, bob, role::admin, domain1

# create a collection of admins in domain1 
# defined under global domain, so other domains can access it
g, alice, group::domain1::admins, *
g, bob, group::domain1::admins, *

g, carol, role::superadmin, domain2
g, frank, role::superadmin, doamin3

# give permissions to all admins in domain1 access domain2 and domain3
# by inheriting globally defined admin group
g, group::domain1::admins, role::partner, domain2
g, group::domain1::admins, role::partner, domain3

[hsluoyz]

@closetool

[issuehunt-oss]

@gaessaki has funded $45.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.

[twgcode]

When will this feature be released
#723

[hsluoyz]

@closetool @tangyang9464 plz work on this

[Sefriol]

I have talked about this problem a couple of times. However, I think almost the best solution comes from incorrect policy configuration:

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

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

[role_definition]
g = _, _, _
g2 = _, _

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

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

p, admin, global_domain, data1, (read|write)
p, admin, sub_domain, data2, (read|write)
p, admin, sub_domain2, data3, (read|write)

g, alice, admin, global_domain
g, bob, admin, sub_domain
g2, global_domain, sub_domain
g2, sub_domain, sub_domain2

Where incorrect lines are g2s, (wrong order definition).

Now, if we query this configuration with following:

alice, global_domain, data1, read --> true
alice, global_domain, data2, read --> true
alice, global_domain, data3, read --> true
bob, sub_domain, data1, read --> false
bob, sub_domain, data2, read --> true
bob, sub_domain, data3, read --> true

which is actually what we almost want. However, user always needs to query from the domain which he/she is an admin and try to query domain resource.

However, I am unsure if this method is corrupt otherwise. The benefits are:

1. Absolute minimum amount of policy rows required (less maintenance)
   1. Only domain roles need to be defined and domain hierarchy
2. quite simplistic model (easy to understand)

This is the feature that needs to be implemented. It's the defacto way of how these kinds of policies are usually used. Domain hierarchy is quite pointless otherwise if it does not mean anything. I think every other way would require much more maintenance.

[Sefriol]

Now that I have thought about it more, I think the original idea of having "partner" domains is flawed. If you want to have links in between domains, those should be done through domain hierarchy (i.e. g2). In my opinion, this hierarchy should also flow down the roles from the parent domain (role hierarchy, not the role access policies), you should not be required to define these hierarchies every time you add a new child domain or add a new role!

g, admin, developer, domain1, domain2 is hard to understand and is huge management overhead. I do not think it's the right solution!

[issuehunt-oss]

@gaessaki has cancelled funding for this issue.(Cancelled amount: $45.00) See it on IssueHunt