You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fortress@directory.apache.org by Shawn McKinney <sm...@apache.org> on 2015/08/28 16:22:31 UTC
Re: [Bulk] ARBAC Setup and Permission OUs
> On Aug 27, 2015, at 2:42 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> I would like some help understanding how one would go about setting up the ARBAC side of fortress, with a focus on different individual's responsibilities.
Hello Chris, welcome.
> On Aug 27, 2015, at 2:42 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> Here are some of my assumptions/question when "registering" a new application with fortress:
>
> 1. Assumption: an application developer would be responsible for initially creating the permission objects, permissions, and permission OUs. In our simple case, there would be a single permission OU. The permission checks are needed at development time so that a developer can tied application actions/operations to permissions in fortress.
>
Correct. Developer, Sys or Security Admin
To understand what the designers of the model had in mind, consider the following excerpt taken from their original paper:
http://profsandhu.com/journals/tissec/p113-oh.pdf
"We now introduce the feature of organization structure as a basis for
user/permission pools. Figure 10 shows the role administration concept in the
ARBAC02 model. First, users and permissions are assigned to proper organi-
zation units by the human resources (HR) group and information technology
(IT) group, respectively. The security administration group then assigns the
users and permissions in organization units to regular roles. We do not elab-
orate the functions of the HR and IT groups here, since they are outside the
scope of our role-based security administration. We assume the activities of
these groups are somehow accomplished in an organization. For the purpose of
role administration, we can use different organization structures for user pools
and permission pools. Further, we assume that there is no conflict between these organization structures as they are only used for the purpose of user pool and
permission pool administration."
>
> On Aug 27, 2015, at 2:42 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> 2. Assumption: A fortress super admin would need to create an application super admin role, and assign a user to it. The app super admin role would have the ability to create other sub admin roles that would limit the scope what the admin could do. For example, a sub admin would need to be able to define application roles (RBAC) and grant permissions to the application role, and assign users to the role.
>
Correct again.
>
> On Aug 27, 2015, at 2:42 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> 3. Question: We have cases where we would like to limit the permissions that the sub admin would be able to grant to an application role. For example, one sub admin role would be able to create roles and grant them all permissions (READ, WRITE, DELETE), while another sub admin role would only be able to create roles and grant them a subset of the permissions (READ). Is there a way to limit the permissions that an admin role has access to grant?
>
You would need to break the single perm ou into several sub orgs. The admin who you want to access all would be assigned to an admin role with every ou. The others would be assigned to a subset. Additionally to keep things organized, you could place these into sub-tree structure.
ou1
ou2 ou3
For example admin 1 would be assigned an admin role that has ou1 assigned. This admin would also be granted authority over ou2 and ou3 via inheritance. The other admins would be assigned to either ou2 or ou3 which would provide them authority over one or the other but not both.
>
> On Aug 27, 2015, at 2:42 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> * We have thought about using the OS-Ps to group permissions into groups that could be assigned to the different sub admins, but ran into problems with needing to create duplicate permissions under each OS-P, and the OS-Ps being tied to the permission object, not the permission.
> * Question: Why is the Permission OU tied to the Permission Object, not the Permission?
Perm objects are resources and those resources are under the authority of a particular development organization.
>
> On Aug 27, 2015, at 2:42 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> 4. Assumption: After an application sub admin user sets up the application roles, they would be able to go in and assign users in their respective organizational areas to each of the application roles.
Correct
Re: [Bulk] Re: [Bulk] ARBAC Setup and Permission OUs
Posted by SHAWN E SMITH <se...@psu.edu>.
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
ses44@psu.edu
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
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 <se...@psu.edu> 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
ses44@psu.edu
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
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 <cr...@psu.edu> 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 <cr...@psu.edu> 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
Re: [Bulk] Re: [Bulk] ARBAC Setup and Permission OUs
Posted by Shawn McKinney <sm...@apache.org>.
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 <se...@psu.edu> 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
ses44@psu.edu
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
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 <cr...@psu.edu> 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 <cr...@psu.edu> 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
Re: [Bulk] Re: [Bulk] ARBAC Setup and Permission OUs
Posted by SHAWN E SMITH <se...@psu.edu>.
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
ses44@psu.edu
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: fortress@directory.apache.org
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 <cr...@psu.edu> 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 <cr...@psu.edu> 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
Re: [Bulk] Re: [Bulk] ARBAC Setup and Permission OUs
Posted by Shawn McKinney <sm...@apache.org>.
> On Aug 28, 2015, at 8:01 AM, Christopher Harm <cr...@psu.edu> 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 <cr...@psu.edu> 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
Re: [Bulk] ARBAC Setup and Permission OUs
Posted by Christopher Harm <cr...@psu.edu>.
Hi Shawn,
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?
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.
-Chris
--
Christopher Harm
Penn State University
AIS/ITS
221 Technology Support Building
300 Science Park Road
State College, PA 16803
814-863-3366
----- Original Message -----
From: "Shawn McKinney" <sm...@apache.org>
To: "Fortress Mailing List" <fo...@directory.apache.org>
Sent: Friday, August 28, 2015 10:22:31 AM
Subject: Re: [Bulk] ARBAC Setup and Permission OUs
> On Aug 27, 2015, at 2:42 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> I would like some help understanding how one would go about setting up the ARBAC side of fortress, with a focus on different individual's responsibilities.
Hello Chris, welcome.
> On Aug 27, 2015, at 2:42 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> Here are some of my assumptions/question when "registering" a new application with fortress:
>
> 1. Assumption: an application developer would be responsible for initially creating the permission objects, permissions, and permission OUs. In our simple case, there would be a single permission OU. The permission checks are needed at development time so that a developer can tied application actions/operations to permissions in fortress.
>
Correct. Developer, Sys or Security Admin
To understand what the designers of the model had in mind, consider the following excerpt taken from their original paper:
http://profsandhu.com/journals/tissec/p113-oh.pdf
"We now introduce the feature of organization structure as a basis for
user/permission pools. Figure 10 shows the role administration concept in the
ARBAC02 model. First, users and permissions are assigned to proper organi-
zation units by the human resources (HR) group and information technology
(IT) group, respectively. The security administration group then assigns the
users and permissions in organization units to regular roles. We do not elab-
orate the functions of the HR and IT groups here, since they are outside the
scope of our role-based security administration. We assume the activities of
these groups are somehow accomplished in an organization. For the purpose of
role administration, we can use different organization structures for user pools
and permission pools. Further, we assume that there is no conflict between these organization structures as they are only used for the purpose of user pool and
permission pool administration."
>
> On Aug 27, 2015, at 2:42 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> 2. Assumption: A fortress super admin would need to create an application super admin role, and assign a user to it. The app super admin role would have the ability to create other sub admin roles that would limit the scope what the admin could do. For example, a sub admin would need to be able to define application roles (RBAC) and grant permissions to the application role, and assign users to the role.
>
Correct again.
>
> On Aug 27, 2015, at 2:42 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> 3. Question: We have cases where we would like to limit the permissions that the sub admin would be able to grant to an application role. For example, one sub admin role would be able to create roles and grant them all permissions (READ, WRITE, DELETE), while another sub admin role would only be able to create roles and grant them a subset of the permissions (READ). Is there a way to limit the permissions that an admin role has access to grant?
>
You would need to break the single perm ou into several sub orgs. The admin who you want to access all would be assigned to an admin role with every ou. The others would be assigned to a subset. Additionally to keep things organized, you could place these into sub-tree structure.
ou1
ou2 ou3
For example admin 1 would be assigned an admin role that has ou1 assigned. This admin would also be granted authority over ou2 and ou3 via inheritance. The other admins would be assigned to either ou2 or ou3 which would provide them authority over one or the other but not both.
>
> On Aug 27, 2015, at 2:42 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> * We have thought about using the OS-Ps to group permissions into groups that could be assigned to the different sub admins, but ran into problems with needing to create duplicate permissions under each OS-P, and the OS-Ps being tied to the permission object, not the permission.
> * Question: Why is the Permission OU tied to the Permission Object, not the Permission?
Perm objects are resources and those resources are under the authority of a particular development organization.
>
> On Aug 27, 2015, at 2:42 PM, Christopher Harm <cr...@psu.edu> wrote:
>
> 4. Assumption: After an application sub admin user sets up the application roles, they would be able to go in and assign users in their respective organizational areas to each of the application roles.
Correct