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