directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Harm <>
Subject ARBAC Setup and Permission OUs
Date Thu, 27 Aug 2015 21:42:44 GMT
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, 

Christopher Harm 
Penn State University 
221 Technology Support Building 
300 Science Park Road 
State College, PA 16803 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message