Hey Shawn, I want to go over this with my team before I comment. I just want to ensure we all read it the same way and agree.
Have a great weekend, Shawn "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 814-321-5227 [email protected] ----- Original Message ----- From: "Shawn McKinney" <[email protected]> To: [email protected] Sent: Friday, August 28, 2015 9:30:30 PM Subject: Re: [Bulk] Re: [Bulk] ARBAC Setup and Permission OUs Here are your requirements wrt ARBAC: 1. Ability to assign orgs to permission ops (as opposed to perm objects) 2. Ability to assign multiple orgs to a given perm op. Assumptions: 1. The org constraints are checked during during DelAccessMgr ops canAssign, canDeassign, canGrant, canRevoke. 2. Org constraints are not checked during AdminMgr ops (e.g. lock, unlock, addX, updateX, deleteX, etc..). This JIRA issue goes into more detail: https://issues.apache.org/jira/browse/FC-111?jql=project%20%3D%20FC Am I missing anything? On Friday, August 28, 2015 11:16 AM, SHAWN E SMITH <[email protected]> wrote: 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: view 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. Shawn "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 814-321-5227 [email protected] ----- Original Message ----- From: "Shawn McKinney" <[email protected]> To: [email protected] 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 <[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
