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?
----- Original Message ----- From: "Shawn McKinney" <[email protected]> To: [email protected] Sent: Monday, October 10, 2016 8:23:39 AM Subject: Re: Access Manager Role Filtering > On Oct 9, 2016, at 5:18 PM, Chris Pike <[email protected]> wrote: > > Well, my thinking was that if you moved Perm OU down into the operation, then > the app could use the Perm OU hierarchy to find relevant permissions > > Parent Perm OU = myapp > - Child Perm OU = myapp.1 > - Child Perm OU = myapp.2 > > perm obj name == Customer > perm op name == add > perm op ou == myapp.1 > > perm op name == update > perm op ou == myapp.2 > > So if I queried for all permissions that belong to Perm OU "myapp" (either > directly or from a child OU), I would get the list of permissions relevant to > "myapp". It would then allow delegation of Perm OU myapp.1 and myapp.2 to > separate ARBAC roles. Or you could just create separate permobj trees for each arbac role. That would effect the caller somewhat but why would they what the perm obj / op combination is, as long as it’s meaningful and unique. These changes you’re proposing need to be described within the context of how they will effect the apis like checkAccess, sessionPermissions, canAssign, canDeassign and the others that are dependent on the data structs. And of course we need to remain cognizant of the original model - ARBAC02. We can certainly add to it does but must not take anything away. > > On Oct 9, 2016, at 5:18 PM, Chris Pike <[email protected]> wrote: > > Of course managing the Perm OU hierarchy and managing changes becomes > challenging. Maybe it's worth thinking through the implications of making > Perm OU multi-occuring on the Perm Op... My first question was stated earlier, how can one set of roles be associated with a perm w/ multiple ous? Shawn
