directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [Bulk] Re: [Bulk] ARBAC Setup and Permission OUs
Date Fri, 28 Aug 2015 18:15:46 GMT
Let me try to provide a more specific example from one of our real use cases.

We have an application that is called the digital identity management center (DIMC).  

It has permissions such as:
lock account
change data
lock wireless
reset password

We want to delegate the ability to create roles and assign permissions to the roles based
on organization.

The Accounts Office (Help Desk) should be allowed to grant any permission to it's staff.
The Security Operations group should be able to grant the ability to view, lock account, and
lock wireless
Human Resources should have the ability to view and lock accounts (but only for faculty/staff
not students) 

Each of those offices will have their own admins.  

What we're trying to figure out is how to most affectively organize that.

My concern with what you've written below (again assuming I understand it) is that once we
get 50 systems with 100 permissions each applied across 10000 users it might start to be challenging.

I hope this helps describe what we're trying to do.


"The programmer … works only slightly removed from pure thought-stuff.
He builds his castles in the air, from air, creating by exertion of the imagination."
— Fred Brooks

Shawn Smith
Director of Software Engineering
Administrative Information Services

----- Original Message -----
From: "Shawn McKinney" <>
Sent: Friday, August 28, 2015 1:29:47 PM
Subject: Re: [Bulk] Re: [Bulk] ARBAC Setup and Permission OUs

> 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