directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: ARBAC Setup and Permission OUs
Date Fri, 28 Aug 2015 13:52:03 GMT
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),

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

----- Original Message -----
From: "Christopher Harm" <>
To: "Fortress Mailing List" <>
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, 

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

View raw message