[web2py] RBAC and group of role management

[Richard]

Hello,

I would like to know how (if possible) I can manage group access for permission granted by other role. For example, I have group A, that allow user member from it to access func A... But how can I create or represent that all members of group B can grant the access to group A and group C for instance? In web2py the membersphip don't allow to represent that a role is a member of another role... So how to avoid a repetitive assignment by using group assignment?

Thanks

Richard

[Niphlod]

This has been reported before but it just triggers for the next level up in the hierarchy (Group C that manages access to Group B that manages access to Group A).

RBAC as is is a complete and finite tool to manage permission: it enforces (as many other things in web2py) sane defaults, levelling all permissions hierarchies to one level.

The fact that you'd need to code your own "hierarchy of permission upon permission" shouldn't stop you (and frankly, if put on a piece of paper, isn't hard to implement)

Loosely said, you can choose any of two ways:

- have your groups linked by some other external reference, and recursively querying for membership

- manage ephemeral groups that can be flatly queried, basically multiplying permissions flattening the structure

Recursively querying the database to check for permission is really heavy, but if your app needs it, go for it. 

Think, though, that you need to check if a user "X" belonging to only one group, Group A, has access to resource "Z".

In hierarchy-defined groups (the structure more familiar to a human brain), you'd need to traverse all permissions to "Z" (that are only given to Group C), then see if a Group B has access to everything Group C has access to, then if a Group A has access to everything that Group B has access to.

A way to check for the user "X" in one step if has access to "Z" is easy, too, and generally less resource intensive...

When you create resource "Z", you grant access to Group C, AND Group B, AND Group C.

OR, you can assign to user "X" Group A AND Group B AND Group C, and assign "Z" permissions to C only.

Granted, the less resource intensive way NEEDS to plan a "manage permissions" machinery accordingly to your needs, but you need to ask yourself how many times your app assigns/revokes permission and how many times it checks for permissions (and how many times will you feel more comfortable debugging it :-P).

[Richard Vézina]

Thanks for reply Simone, I see the complexity and the limitless recursion that can occur... I guess, I will go with flat group of access which will overlap... My main issue was that I would avoid having two way to assign the same set of permissions... Let say I have tool A, so I create group A, so any users member of group A has access to tool A... That why I would had reuse group A to provide access to tool A to all member of group B, which could also provide access to group C, D, etc. This implies refactoring to RBAC by having auth_membership relation between group and not only user and group which prevent having foreign key for user_id and have a "group_member_id" (sorry no better name) that is kind of duplicated group_id... It would surely break web2py membership verification since web2py surely make the assomption that there is always an user id attach to membership relation which could not be the case.

So, I follow your advice and keep it simple... The only drawback that I see is that I may end with differents groups that provide access to the same ressource... group A above has access to tool/func A and group "Department X" which could have also access to tool A and another set of function at the same time...

Thanks again

Richard

--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Niphlod]

On Tuesday, November 24, 2015 at 3:59:28 PM UTC+1, Richard wrote:

Thanks for reply Simone, I see the complexity and the limitless recursion that can occur... I guess, I will go with flat group of access which will overlap... My main issue was that I would avoid having two way to assign the same set of permissions... Let say I have tool A, so I create group A, so any users member of group A has access to tool A... That why I would had reuse group A to provide access to tool A to all member of group B, which could also provide access to group C, D, etc. This implies refactoring to RBAC by having auth_membership relation between group and not only user and group which prevent having foreign key for user_id and have a "group_member_id" (sorry no better name) that is kind of duplicated group_id... It would surely break web2py membership verification since web2py surely make the assomption that there is always an user id attach to membership relation which could not be the case.

web2py's "has_membership" just checks for group membership. if user "X" isn't member of group A, user is not authorized.