directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <>
Subject Re: [Bulk] ARBAC Setup and Permission OUs
Date Fri, 28 Aug 2015 14:22:31 GMT

> On Aug 27, 2015, at 2:42 PM, Christopher Harm <> 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 <> 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:

"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 <> 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 <> 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.

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 <> 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

Perm objects are resources and those resources are under the authority of a particular development

> On Aug 27, 2015, at 2:42 PM, Christopher Harm <> 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. 

View raw message