Chris, what you are proposing is not trivial and will require a bunch of work. That being said I want to make sure that your use case is broadly applicable before we commit a bunch of work and possibly break existing functionality.
Which is why I am playing the skeptic here so bear with me... *** So we are saying the role groups have now become a necessary part of your model? If ‘no’ what then becomes of this use case wrt multi-occurring permous? How do we ensure that we don’t introduce inconsistencies to how it works today? As long as we’re asking open ended questions… Have you exhausted all possibilities of the existing model? To answer this question let’s walk away from the contrived use case and move into one that is relevant. Describe a use case you are facing today that won’t work with current model but will with this proposed change. One more request. Have you looked at the ARBAC02 paper? Maybe there is something there that we have missed that will help. How does your change fit in with the original model. Does it compliment or detract? I guess what I am trying to say is let’s make sure the existing model is broke before we invent a new one. If we change it, we own it, and are forever on the hook for the ‘why’ rather than just sending a link to the model and saying we do that. Thanks, Shawn > On Oct 11, 2016, at 12:08 PM, Chris Pike <[email protected]> wrote: > > AR1 could only revoke R1, R2, and R3 if it's role range (or role group, which > we plan on adding to add to ARBAC roles) allowed. > > Role Groups: RG1, RG2, RG3 > > Roles: R1 (RG1), R2 (RG2), R3 (RG3) > > AdminRoles > AR1 - P01 / RG1 > AR2 - P02 / RG2 > AR3 - P01, P02, P03 / RG3 > > Only someone in AR1 could remove "sleeper" from R1 > Only someone in AR2 could remove "sleeper" from R2 > Only someone in AR3 could remove "sleeper" from R3 > > > > > ----- Original Message ----- > From: "Shawn McKinney" <[email protected]> > To: [email protected] > Sent: Tuesday, October 11, 2016 9:35:30 AM > Subject: Re: Access Manager Role Filtering > >> On Oct 11, 2016, at 7:24 AM, Chris Pike <[email protected]> wrote: >> >> Not sure if I understand your questions about how can one set of roles be >> associated with a perm with multiple OUs. The Perm OUs are just an ARBAC >> thing correct? > > Yes, but there are semantics here that need to be understood. > > This discussion is too complicated in the abstract. We need use cases. > > For example: > > Roles: R1, R2, R3 > > Perm OUs : P01, P02, P03 > > AdminRoles > AR1 - P01 > AR2 - P02 > AR3 - P01, P02, P03 > > Perms > PermObj: foo > op: fighter: ous:(P01), roles(R1) > op: eater: ous:P02), roles:(R2) > op: sleeper: ous(P01, P02, P03) roles(R1, R2, R3) > > So we have 3 perms, the first two are typical, the last one, foo.sleeper is > not as it has multiple perm ous associated with it. > > Now let us consider the operation: > boolean canRevoke(Session session, Role role, Permission perm) throws > SecurityException > > Any administrator that has any of the adminroles listed could revoke any of > foo.sleeper’s roles. e.g. admin AR1, could revoke R1, R2 and R3. Is that > desirable behavior? > > Shawn
