Shawn, Completely understand and agree. I apologize in advance for the length of this email. These are big changes and need to have buy in and support before making them. I think we are talking about two separate changes here, which I'll call "ARBAC Role Grouping" and "ARBAC Perm OU Placement". I have looked at the ARBAC02 paper. It is hard to follow, and I believe it has problems. Has the ARBAC02 paper been implemented in any other system? If yes, then I would like to know how they got around these problems, if no, then I don't think we should give it too much credence. I think the "ARBAC Role Grouping" discussion is fairly straight forward, the "ARBAC Perm OU Placement" is complicated.
"ARBAC Role Grouping" User Story: As a fortress super administrator, I want to delegate Role Management (Creation and Permission Assignment) to application owners Current Steps: 1. Create an ARBAC Role (AR1) that has jurisdiction over Perm OU (POU1) and Role Range (RR1) 2. Assign User (U1) into AR1 3. U1 creates new Role (R1) 4. U1 adds Permission (P1) into R1 but is denied since R1 doesn't belong to RR1 Steps After ARBAC Role Group 1. Create an ARBAC Role (AR1) that has jurisdiction over Perm OU (POU1) and Role Group (RG1) 2. Assign User (U1) into AR1 3. U1 creates new Role (R1) with Group of RG1 4. U1 adds Permission (P1) into R1 There was a long email chain back in May / June about this. "ARBAC Perm OU Placement" User Story: As a fortress super administrator, I want to delegate different Permission Operation assignment to different application owners. (i.e. One group can give out account creation, another can give out account reset, and a third can give out both) Current Steps: 1. Create Permission Object (account.create) with Perm OU (POU1) and Operation (do) 2. Create Permission Object (account.reset) with Perm OU (POU2) and Operation (do) 3. Create an ARBAC Role (AR1) that has jurisdiction over Perm OU (POU1) 4. Create an ARBAC Role (AR2) that has jurisdiction over Perm OU (POU2) 5. Create an ARBAC Role (AR3) that has jurisdiction over Perm OUs (POU1 and POU2) 6. U1 adds Permission (account.create.do) into R1 7. U2 adds Permission (account.reset.do) into R2 8. U3 adds Permissions (account.create.do and account.reset.do) into R3 9. Create new Permission Object (account.delete) with Perm OU (POU3) and Operation (do) 10. Update AR2 to add POU3 11. Update AR3 to add POU3 End State: account.create.do -> POU1 account.reset.do -> POU2 account.delete.do -> POU3 AR1 -> POU1 AR2 -> POU2, POU3 AR3 -> POU1, POU2, POU3 Issues / Notes: - A one to one mapping between Permissions and PermOUs - Adding a new permission may require updating many ARBAC roles Steps after Perm OU Move to Operation 1. Create Permission Object (account) with Operations (create with POU1 / reset with POU2) Steps are the same after this point End State: account.create -> POU1 account.reset -> POU2 account.delete -> POU3 AR1 -> POU1 AR2 -> POU2, POU3 AR3 -> POU1, POU2, POU3 Issues / Notes: - Same issues as previous use case Steps after Perm OU Move to Operation and Multi Instance 1. Create Permission Object (account) with Operations (create with POU1 / reset with POU1) 2. Create Perm OU (POU2) and add to account.create 2. Create an ARBAC Role (AR1) that has jurisdiction over Perm OU (POU2) 3. Create Perm OU (POU3) and add to account.reset 4. Create an ARBAC Role (AR2) that has jurisdiction over Perm OU (POU3) 5. Create an ARBAC Role (AR3) that has jurisdiction over Perm OUs (POU1) 6. U1 in AR1 adds Permission (account.create) into R1 7. U2 in AR2 adds Permission (account.reset) into R2 8. U3 in AR3 adds Permissions (account.create and account.reset) into R3 9. Create new Permission Operation (account.delete with POU1 and POU3) End State: account.create -> POU1, POU2 account.reset -> POU1, POU3 account.delete -> POU1, POU3 AR1 -> POU2 AR2 -> POU3 AR3 -> POU1 Sorry for the length, I can try to make some diagrams if you think that would help. Thanks for hearing me out! ~Chris P. ----- Original Message ----- From: "Shawn McKinney" <[email protected]> To: [email protected] Sent: Tuesday, October 11, 2016 2:58:00 PM Subject: Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering) 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
