Role Based Access Control (RBAC) [1] is a standardized model to indirectly assign permissions to users by user roles. We follow the proposal of Chae and Shiri [2] to additionally introduce a hierarchy of object classes in addition to the hierarchy of user roles along which permissions are inherited. This makes sense, since e.g. in file systems the inheritance of permissions along the directory tree is common. Different formalizations are suitable for RBAC, especially Description Logics has been proposed multiple times in literature. Description Logic (DL) [3] systems provide their users with inference services that deduce implicit knowledge from the explicitly represented knowledge. The proposal by Chae and Shiri [2] is based on DL but has several flaws, which we want to fix with this paper. The authors apply essential properties of DL in a wrong way and do not respect DL semantics, do not use ABox assertions correctly, miss a discussion of the open world assumption and get wrong results with their running example. For a more detailed discussion of these issues, please refer to [4].
We decided to formally model RBAC-CH by means of a DL, and a crucial modeling
issue is which DL constructors are needed in order to decide which DL is used in our
approach. On the side of the concept constructors, we essentially need only the
constructors of ALC, i.e. top and bottom, conjunction, disjunction, negation, and
existential and value restrictions (we do not need number restrictions). Moreover, we use the
“fills” constructor P : a (= ∃P.{a}) [
The ontology consists of ABox and TBox. The user role hierarchy, the object class hierarchy and permissions of user roles to object classes are defined in the TBox. The assertions of user individuals to user roles as well as object individuals to object classes are defined in the ABox. From these explicit facts a reasoner can infer the permissions of individual users to individual objects in the ABox by full calculation of property extensions, and they can be queried at runtime. Also permissions from the perspective of an object, called the Access Control List (ACL) can be queried.
Permissions are modeled by object properties. The definition of permissions for
user roles on object classes has an important requirement: permissions are exhaustive
for every individual of a user role and every individual of an object class, e.g. “all system
administrators can read all types of files”. Obviously it is essential to model such
statements in any formal approach to RBAC, but statements like these are not generally
supported by OWL. However Rudolph et al. propose in [
The TBox contains the concept hierarchy with the user roles as well as the object class
hierarchy as depicted in Fig. 1 analogously to the scenario in [
Furthermore the TBox contains the assignment of permissions for user roles on objects. In the following example, we define that every remote client can execute every executable file with the concept product RemCli × ExeF ile v canExecute. The concept product is simulated in SROIQ with canBeExecutedBy ≡ canExecute−, canExecute1 ◦ canExecute2− v canExecute, RemCli v ∃canExecute1.{a}, ExeF ile v ∃canExecute2.{a}. The ABox contains assertions of users to user roles and files to object classes in the form OSDev(edward), P roF ile(programF ile1) etc. After full calculation of property extensions by a reasoner, we can directly read the authorizations from the inferred object properties between the ABox individuals. In our example, for the individual edward we find the Capability entry canExecute(edward, programF ile1) and for the individual programF ile1 we find the ACL entry canBeExecutedBy(programF ile1, edward). The resulting knowledge base is depicted in Fig. 2.
In the example we only defined “remote client can execute executable files. The
example scenario from [
Due to the user role hierarchy and the object class hierarchy, explicit permissions
in Tab. 1 induce implicit permissions made explicit by the DL reasoner in Tab. 2. In [
We presented an approach for an access control model with object hierarchy by means
of DL. We have fixed the flaws in the existing approach [
Our current work focuses on increasing usability: We want to adhere to the distinction of explicit and implicit permissions like we have compared them in the tables 1 and 2. We claim that this reduces effort to assign permissions and helps to avoid mistakes by granting unwanted permissions. We want to investigate two directions. In one direction, the user shall be able to define the intended permissions in the access matrix, and the user role hierarchy and object hierarchy is then automatically derived. This would help to get insights in the user role and object hierarchy which have not been obvious before. Methods from formal concept analysis (FCA) may be appropriate in this context. In the opposite direction, given a user role hierarchy and object class hierarchy, an access matrix can be completed and updated at changes with inferred permissions. This allows the user to keep track of inferred permission in addition to his explicit permissions.