directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <>
Subject Re: [Bulk] Re: [Bulk] ARBAC Setup and Permission OUs
Date Fri, 28 Aug 2015 17:29:47 GMT

> On Aug 28, 2015, at 8:01 AM, Christopher Harm <> wrote:
> I think that (PSU) Shawn's example better illustrates the problem.  In his example the
permission objects don't fit into an explicit hierarchy.  
>> Given Permissions (A, B, C, D, E, F)
>> and given admin roles with the ability to delegate roleAlpha(A,B,C,D,E,F), roleBeta(A,B,E),
> Permission Object E would need to be duplicated in order to fall under both roleBeta
and roleCharlie.  Or can the Permission Object be mapped into multiple permission OUs?  

Not sure I understand the question.  There is a one-to-one correspondence between a permission
object and a perm org.  There is a many-to-many mapping between an admin role and a perm org.
 Can’t today store multiple perm ous on a single perm object.

> On Aug 28, 2015, at 8:01 AM, Christopher Harm <> wrote:
> Also, I think that I left out some detail in my example.  I would like to propose that
in my example (READ, WRITE, DELETE) were operations on the same permission object.  So given
that a permission object is assigned to a permission OU, it wouldn't be possible (without
duplicating the permission object) to assign READ to one permission OU and READ, WRITE, DELETE
to the other.  

Correct.  We could establish a different convention to create perm objects/perms.  

Given same example we could have:

permobj: A-Read
permou: A-read
operation: exe

permobj: A-Write
permou: A-write
operation: exe

permobj: A-Delete
permou: A-del
operation: exe

This would allow you to control the obj-operation mapping using different orgs per each. 
Or, you could use the same permou across each perms objects, or mix and match as appropriate.

You would have to map the perms differently when calling checkAccess because the object and
operation is concatenated and operation name would always be exe (or whatever you want to
call it).

This is a work-around but I can’t think of any problems wrt to usability or increased complexity
other than having more objects in the tree and a slightly different mapping during runtime.
 Performance would not suffer.

Still not convinced it is right for you but maybe buys us time until we can figure out if
changing the data model to store perm ou on permission operation is appropriate mapping.


View raw message