ACLs can become very complex and cumbersome to manage with a growing number of subjects, activities, or objects. Role-based access control models add roles as an additional abstraction level. In a role-based access control model, subjects are assigned to (multiple) roles. The permissions to perform certain activities or use certain objects are assigned to roles instead of assigning them directly to subjects. Thus, the management of a subject’s permissions is confined to assigning users to appropriate roles. This also simplifies common operations like adding a subject or changing a subject’s responsibilities. Further roles can inherit permissions from other roles.
The following code defines an RBAC model, where role r1 dominates r2 and therefore in- herits its permissions. This right propagation must be enabled manually using the method setRightsPropagation. The relations between roles are specified by a RoleLattice ob- ject, whose inner representation is a graph with the role names as nodes.
// Role definition with their relations
RoleLattice lattice = new RoleLattice(Arrays.asList("r1", "r2"));
lattice.addRelation("r1", "r2");
// RBAC model definition
RBACModel rbac = new RBACModel("RBAC", base, lattice);
rbac.setRightsPropagation(true);
rbac.setRoleMembership("r1", Arrays.asList("sub_1", "sub_3"));
rbac.setRoleMembership("r2", Arrays.asList("sub_2"));
rbac.setActivityPermission("r1", "act_1","act_2");
rbac.setActivityPermission("r2", "act_3");
rbac.setObjectPermission("r1", "obj_1", DataUsage.WRITE);
rbac.setObjectPermission("r1", "obj_3", DataUsage.READ,DataUsage.CREATE);
rbac.setObjectPermission("r2", "obj_2", DataUsage.DELETE);
rbac.isAuthorizedForObject("sub_1", "obj_2", DataUsage.DELETE);
// returns true
rbac.isAuthorizedForTransaction("sub_1", "act_3");
// returns true
System.out.println(rbac);
The code above produces the following output.
subjects: [sub_2, sub_1, sub_3] transactions: [act_2, act_1, act_3]
objects: [obj_3, obj_2, obj_1]
roles: [r1, r2]
Role transaction permissions:
r1: [act_2, act_1, act_3]
r2: [act_3]
Role object permissions:
r1: [obj_3, obj_2, obj_1]
r2: [obj_2]
role assignments:
r1: [sub_1, sub_3]
r2: [sub_2]
At the top, the SOA base is shown, which has been extended by roles. Afterwards the roles’ permissions on transactions and objects are listed and at the end, the assignment of subjects to roles can be found.
The graphical dialogue ACModelDialog can also be called for creating and editing an RBAC model. This is done using the following code:
RBACModel m = ACModelDialog.showDialog(null,"RBAC",ACModelType.RBAC,base);
The resulting user interface for editing the RBAC model can be seen in Figure 2a. When clicking the button with the label Edit role lattice a new window opens, in which one can add and remove roles and specify inheritance relations between them (see Figure 2b).
-
(2a) Dialogue for editing RBAC with preview of the access control model.
(2b) Dialogue for editing roles and the inheritance hierarchy among them.
Figure 2: Dialogue for editing RBAC models in SEWOL.
Since the checkbox Propagate rights along lattice is selected and r1 dominates r2 in
Figure 2b, the role r1 inherits permissions for activity act 3 and object obj 2 from r2.