> On May 11, 2016, at 10:37 AM, Chris Pike <[email protected]> wrote: > > Wanted to start discussing this topic again... > > Issue is that ARBAC maps to role ranges (start node and end node in a tree). > This causes two major problems. > > 1. A new role does not automatically belong to any ARBAC role, so a user may > have the ability to create a role, but unless they are a super admin they > will not be able to assign users or permissions to that role. > 2. Since an ARBAC role can only map to one role range, there is an explosion > of ARBAC role required to manage the RBAC roles. Managing the ARBAC roles > becomes challenging when combined with issue #1.
Agreed, there is a usability problem limiting the effectiveness of the ARBAC02 controls. > > On May 11, 2016, at 10:37 AM, Chris Pike <[email protected]> wrote: > > My proposal is to treat roles similar to how permissions are treated. > Permissions get grouped into Perm OUs and an ARBAC role can be assigned > jurisdiction over many Perm OUs. We would do the same thing for roles and > create Role OUs. So an ARBAC role would point to many Role OUs, and when a > user created a role it would be created in a Role OU which they already had > jurisdiction over. > > The downside is that this violates the ARBAC spec, but given the issues I > described above, I think it is necessary. It also would break backwards > compatibility unless we allow both role ranges and Role OUs. I have a couple of problems with the proposal: 1. Don’t want to break the ARBAC02 model. Whatever we do must remain both backward compatible and compliant. 2. I think adding another ou tree based on roles will make this too complicate to comprehend and manage. I favor a slightly different approach. Would it be possible to use a role grouping mechanism instead? So instead of new roles falling under a particular admin’s jurisdiction using the (proposed) role ous, we add the new role to the role group that corresponds with a particular admin’s domain. > > On May 11, 2016, at 10:37 AM, Chris Pike <[email protected]> wrote: > > I also found this issue that discusses RBAC grouping of roles, so maybe it > plays in somehow (https://issues.apache.org/jira/browse/FC-75). Good eye. This issue was created to support an openstack use case but I think it could be used here as well. That is to say the role grouping mechanism would be a set of RBAC roles and we add a multi-occurring attribute to the admin role that corresponds with these groups. Rather than (always) preventing the new role from being assigned unless it belongs in the admin’s domain, we add a flag that determines if the the system enforces the constraint. That way we are backward compatible with ARBAC02 & we satisfy your use cases. WDYT? Shawn
