As a follow up, for a concrete example we have.
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) How do we set that up with respect to the OS-P in fortress? Thanks in advance, (The other) 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: "Christopher Harm" <[email protected]> To: "Fortress Mailing List" <[email protected]> Sent: Thursday, August 27, 2015 5:42:44 PM Subject: ARBAC Setup and Permission OUs 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. 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. 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. 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? * 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? 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. Thanks in advance, Chris -- Christopher Harm Penn State University AIS/ITS 221 Technology Support Building 300 Science Park Road State College, PA 16803 814-863-3366
