It's interesting that you bring up pushing Perm OU down to Perm Operation... We had discussed doing this a while back to support separating delegation of permissions. For example, separating read vs. write delegation on an object. Why is this an invalid state?
----- Original Message ----- From: "Shawn McKinney" <[email protected]> To: [email protected] Sent: Sunday, October 9, 2016 10:00:04 AM Subject: Re: Access Manager Role Filtering > On Oct 9, 2016, at 8:49 AM, Shawn McKinney <[email protected]> wrote: > > Need to think about the implications of that. First, the perm entity now > carries an ou attribute. Perhaps that can be accomplished during the create > by reading the parent’s ou value. But if the parent ever changes its ou, > possible on updates, it would have to push the new ou down to its children. > > Not too bad, but there may be other hidden difficulties. > > Another idea is to move the ou from permobj to the perm entity altogether, > but that would impact other arbac funcs. Maybe for the good, but need to > kick that idea around some more. WRT idea #1 - The ou attribute must be immutable from the perspective of the child and mutable for the parent. Otherwise values could get out of synch with children being associated with varying ou values which can’t happen. WRT idea #2 - Moving the ou value down to the permission would allow same condition as above, children with same parent having differing ous which is an invalid state. So I’m taking this idea off the table.
