Let’s think of the permission in its most basic as a mapping between object and operation.
For example: permission object name == Customer permission operations == add, update, delete And now lets add the app domain, permou to the mix: permission object ou = app123 It makes sense that an ou would be associated to the permission object which is an entity that needs to be protected within an application's domain, e.g. app123. But what happens when we move that ou down into the perm ops? perm obj name == Customer perm op name == add perm op ou == app123 perm op name == update perm op ou == app456 perm op name == delete perm op ou == app789 So we’re saying here that an app within domain 123 has a permission to add, an app in domain 456 can update, and so forth. What happens when we have an app in domain 456 that needs to also call add? Do we add another operation for that under the same parent? What would this do to the access mgr apis like check access and session permissions - would then need to now accept the perm ou as a paramter? Or do we make the permou multioccuring, what then happens to the roles associated with that operation? Now let’s consider the object identity, which can be associated with the permobj. What would then happen when we have multiple perm ous associated with the children - how can they all have the same object identity? Shawn > On Oct 9, 2016, at 9:20 AM, Chris Pike <[email protected]> wrote: > > 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.
