> On Aug 28, 2015, at 8:01 AM, Christopher Harm <[email protected]> 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), roleCharlie(E,F) > > 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 <[email protected]> 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. Shawn
