Deploying ABAC policies using RBAC systems

Abstract

The flexibility, portability and identity-less access control features of Attribute Based Access Control (ABAC) make it an attractive choice to be employed in many application domains. However, commercially viable methods for implementation of ABAC do not exist while a vast majority of organizations use Role Based Access Control (RBAC) or their temporal extensions, such as Temporal Role Based Access Control (TRBAC). In this paper, we present a solution for organizations having a RBAC/TRBAC that can deploy an ABAC policy. Essentially, we propose a method for the translation of an ABAC policy (including time constraints) into a form that can be adopted by an RBAC/TRBAC system.

We experimentally demonstrate that time taken to evaluate an access request in RBAC and TRBAC systems is significantly less than that of the corresponding ABAC system. Since the cost of security management is more expensive under RBAC when compared to ABAC, we present an analysis of the different management costs and present mitigation approaches by considering various administrative operations.

Keywords

ABAC TRBAC temporal RBAC time attributes deploying enabling

1. Introduction

Role-Based Access Control (RBAC) is the de-facto standard of access control for most organizations for the last three decades. And to cater to the changing requirements of businesses, organizations have extended and modified RBAC in various forms such as temporal RBAC, environment/context aware RBAC, spatial RBAC, etc. TRBAC is the temporal extension of RBAC which restricts the time duration during which a role can be enabled or made available. However, a primary limitation of Role based systems is their significant dependence on user and object identity for mapping it to a set of roles. As an alternative, the Attribute Based Access Control (ABAC) are identity-less, a feature which gives them a great deal of flexibility. In ABAC, subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions [4,5]. As such, ABAC can comprehensively handle various factors affecting access control decisions like location, time, server load, etc., and also facilitates inter-domain accesses. ABAC covers all the extended features of RBAC and also enhances the access control system in terms of workability to the users and objects as it is an identity-less and dynamic form of access control. Furthermore, ABAC is also more portable across organizational domains, because it only depends on user and object attributes for defining access. Indeed the flexibility, portability and identity-less access control features make ABAC very attractive to be employed in many application domains, including cloud computing, web services, collaborative and coalition based systems, as it is feasible to make access control decisions without any prior knowledge of the subject. As a result, many organizations are now moving to ABAC, because of its above-mentioned advantages. Indeed, Gartner predicts that by 2020, 70% of enterprises would use ABAC as the dominant mechanism to protect critical assets, up from less than 5% today [11].

From a security management standpoint also, ABAC is beneficial as it allows for the creation of access policies based on the existing attributes of the users and objects, as compared to manual assignment of roles, ownership or security labels. ABAC reduces the need for manual intervention in configuring and deploying access control. Suppose if an employee changes roles or leaves the company, RBAC roles need to be manually changed or deactivated by an administrator, perhaps within several systems, which adds a layer of vulnerability from the security perspective. As organizations expand and contract, partner with external entities, and modernize systems, this method of managing user access becomes increasingly difficult and inefficient [4]. On the other hand, under an ABAC system implementation, such organizational changes effectively do not incur any manual cost as no changes need to be made to the access control configuration. As such, the administrative cost of ABAC is significantly lower as compared to that of RBAC (or even that of discretionary access control (DAC)).

Despite many organizations acknowledging the benefits of an ABAC model compared to other access control models and wanting to adopt ABAC as their method of access control; there do not yet exist many commercial ABAC implementations. Some vendors such as Axiomatics, do offer ABAC implementations as dynamic authorization solutions, however, ABAC implementations have not yet been incorporated into any of the popular operating systems, or applications such as DBMS, etc. As such, organizations wanting to adopt ABAC, need to implement it in-house, which can often be error-prone and unreliable.

RBAC systems and their temporal extensions are widely deployed in almost all commercially available OS and application systems at most organizations. In [2], we have proposed an approach that can help realize an ABAC policy using a RBAC system. Essentially, we have considered ABAC policies and translate them into an equivalent RBAC configuration so that a user gains access to a resource in RBAC if and only if that user has the specified access under ABAC. In this paper, we extend it by considering ABAC policies with temporal constraints and translate them into an equivalent TRBAC configuration.

There are a number of benefits for taking this path to enforcing access control. First, our approach is an alternative where ABAC can simply be realized with a readily available RBAC implementation. Second, it is well known that when an access request is submitted by a user, the enforcement in ABAC is much more expensive in terms of time and processing power than that in RBAC. We experimentally demonstrate that the evaluation of access request is faster if ABAC is implemented in the form of RBAC/TRBAC. As a result, with our approach, one can enjoy the benefits of ABAC (such as flexibility, etc.) as well as the benefits of RBAC (efficient authorization enforcement). Due to this, one may still want to go on our proposed path, even if an ABAC implementation were to be available in future.

Third, as ABAC paradigm is very popular for cloud environments due to its fine-grained property. Therefore, our solution is also beneficial for the organizations that have an RBAC system in place and would like to be a part of cloud or a collaborative data sharing environment.

Further, we discuss an analysis of taking this path in both the translations, namely (i) ABAC to RBAC and (ii) ABAC with temporal constraints to TRBAC. However, while RBAC administration and maintenance are considered less costly when compared to DAC, as mentioned earlier, it is more expensive when compared to ABAC. Recognizing this fact that the maintenance cost in RBAC is significantly higher than that of ABAC, we also propose methods to handle such changes effectively by considering the different configuration and management costs while dealing with various change scenarios such as addition/deletion of users and objects, changes to ABAC policies including addition/deletion of subject/object attributes, addition/deletion of ABAC rules.

The rest of this paper is organized as follows. In Section 2, we provide a brief overview of ABAC, ABAC with temporal constraints, RBAC and TRBAC. In Section 3, we present our approach for converting an ABAC policy to RBAC. The idea is to cover all the authorizations of ABAC model and build an equivalent RBAC model. We also examine how the number of policy rules in ABAC relates to the number of roles in RBAC. In Section 4, we present a solution that translates an ABAC policy with time attributes/temporal constraints to an equivalent TRBAC system. In Section 5, we experimentally compare the cost of enforcement in an ABAC system to the cost of enforcement in RBAC once the ABAC policies are implemented in the RBAC system. We also discuss the comparison of enforcement cost when ABAC policies with time constraints are implemented in a TRBAC system. In Section 6, we discuss the management cost by considering the administrative operations in the two systems and ways to make it more efficient. In Section 7, we review the related work. Finally, in Section 8, we conclude the paper and discuss future research directions.

2. Preliminaries

In this section, we briefly present the attribute based access control (ABAC) model [6,14], the Role Based Access Control model [13], and Temporal Role Based Access Control Model (TRBAC) [3], upon which all of the following work is based. In ABAC, the authorization to perform an operation (e.g., read/write/modify) is granted based on the attributes of the requesting user, requested object, and the environment in which a request is made. In RBAC, the authorization to perform an operation is based on role of a user requesting permission to access and object, whereas TRBAC is a temporal extension of RBAC.

2.1. RBAC

The basic components of RBAC are as follows:

Users ( $U$ ): Represents a set of authorized users/subjects. Each member of this set is denoted as $u_{i}$ , for $1 ⩽ i ⩽ | U |$ .

Objects ( $O$ ): Represents a set of resources to be protected. Each member of this set is denoted as $o_{i}$ , for $1 ⩽ i ⩽ | O |$ .

ROLES ( $R$ ): Represents a set of roles. Each member of this set is denoted as $r_{i}$ , for $1 ⩽ i ⩽ | R |$ .

$OPS$ : Represents a set of operations. Each member of this set is denoted as ${op}_{i}$ , for $1 ⩽ i ⩽ | OPS |$ .

$PRMS$ : Represents the set of Permissions $PRMS \subseteq {(o-op) ∣ o \in O \land op \in OPS}$ .

$UA$ : User Role assignment relation, $UA \subseteq U \times R$ is a many-to-many mapping of user to role assignments. We use a $m \times n$ binary matrix to represent $UA$ .

$PA$ : Permission Role assignment relation, $PA \subseteq PRMS \times R$ is a many-to-many mapping of permission to role assignments.

2.2. TRBAC

TRBAC is a temporal extension of RBAC. It allows roles to be enabled for specific sets of time intervals and disables the roles for the remaining time. The TRBAC model by Bertino et al. [3] which is an extension of RBAC model allows to enable and disable roles in RBAC by restricting the set of time intervals during which a role can be allowed. During this time duration the user can get the role and the permissions associated with that role. In addition to the $UA$ and $PA$ of a traditional RBAC setting, for TRBAC, an $REB$ (Role Enabling Base) is also maintained, which contains for each temporal role( $R_{T}$ ), a set of time intervals during which the role can be enabled. So, the user can be assigned the permissions through a role only during the set of time intervals during which those roles are enabled as specified in the $REB$ .

$PE$ : Represents Periodic Expression, which is a set of time intervals given in terms of $Calendars$ . A Calendar is a set of time intervals and can have any one of the following granularities: Hours, Days, Weeks, Months, or Years. two Expressions: $Begin$ and $End$ are associated with each $PE$ to bound the set of time intervals from below and above. Note that the number of time intervals in $PE$ could be infinite however in our paper we consider $PE$ to be the set of time intervals in the given system.

$REB$ : Represents role Enabling Base, which describes the enabling duration of each role in terms of one or more periodic expressions( $PE$ ). The resulting $REB$ entry is $⟨ [begin, end], PE ⟩$ . Corresponding to each role r one or more entries of the form $⟨ [begin, end], PE, enable r ⟩$ are present denoting the time interval set during which r is enabled.

2.3. ABAC

The basic components of ABAC are as follows:

Users ( $U$ ): Represents a set of authorized users/subjects. Each member of this set is denoted as $u_{i}$ , for $1 ⩽ i ⩽ | U |$ .

Objects ( $O$ ): Represents a set of resources to be protected. Each member of this set is denoted as $o_{i}$ , for $1 ⩽ i ⩽ | O |$ .

Environment ( $E$ ): Represents a set of environment conditions, independent of users and objects. Each member of this set is denoted as $e_{i}$ , for $1 ⩽ i ⩽ | E |$ .

$U_{A}$ : Represents a set of user attribute names. Members of these sets are represented as ${ua}_{i}$ , for $1 ⩽ i ⩽ | U_{A} |$ , each ${ua}_{i}$ is associated with a set of possible values it can acquire. For instance, if a user attribute Position is associated with the values {Manager, Associate, Customer}, then for every $u \in U$ , value of the attribute Position can be either Manager, Associate or Customer.

$O_{A}$ : Represents a set of object attribute names. Members of these sets are represented as ${oa}_{i}$ , for $1 ⩽ j ⩽ | O_{A} |$ . Each ${oa}_{i}$ is associated with a set of possible values it can acquire. For instance, if an object folder with records of customers has object attribute Region associated with a set of values {EastCoast, WestCoast}, then for every $o \in O$ , Region can be either EastCoast or WestCoast.

For the sake of simplicity, in this paper, we ignore environmental attributes.

$U_{C}$ : Represents a set of all possible user attribute conditions denoted as ${uc}_{j}$ , for $1 ⩽ j ⩽ | U_{C} |$ . Members of this set are represented as equalities of the form $n = c$ , where n is a user attribute name and c is either a constant or any. For instance if user attribute Position has possible values {Manager, Associate, Customer} and user attribute Region has possible values as {EastCoast, WestCoast}, then $U_{C}$ will be a set comprising of {Position = Manager, Position = Associate, Position = Customer, Position = any, Region = EastCoast, Region = WestCoast, Specialty = any}. Note here, that the condition n = any does not have to be explicitly chosen. It is set only if at least one other condition for n is present. We use the notation $U_{C}$ . $u_{i}$ to express the user attribute condition set of a user $u_{i}$ .

$O_{C}$ : Represents a set of all possible object attribute conditions denoted as ${oc}_{k}$ , for $1 ⩽ k ⩽ | O_{C} |$ . Members of this set are represented as equalities of the form $n = c$ , where n is an object attribute name and c is either a constant or any. For instance if object attribute Region has possible values {EastCoast, WestCoast} and object attribute RecordOf has possible values {Manager, Associate, Customer, Staff}, then $O_{C}$ will be a set comprising of {Region = EastCoast, Region = WestCoast, Region = any, RecordOf = Manager, RecordOf = Customer, RecordOf = Associate, RecordOf = Staff, RecordOf = any}. For an attribute name n, if the value of c is any, then the attribute n is not relevant for making the corresponding access decision. Therefore, as above, the condition n = any does not have to be explicitly chosen. It is set only if at least one other condition for n is present. We use the notation $O_{C}$ . $o_{i}$ to express the object attribute condition set of an object $o_{i}$ .

ABAC Policy base $Π_{A}$ : This represents a set of access rules in the ABAC system. Each member of this set is denoted as $π_{i}$ , for $1 ⩽ i ⩽ | Π |$ , where π is a quadruple of the form $⟨ uc, oc, ec, op ⟩$ . If a user makes a request to access an object, the policy base is searched for any rule through which the user can gain access. If such a rule exists, then access is granted, otherwise it is denied.

In $U_{C}$ and $O_{C}$ we have represented the attribute conditions as equalities, however, our approach is flexible to include the complex attribute condition constructs (inequalities, negation, subset, etc.) by converting them to their corresponding list of attributes conditions. In the following, we define the mapping between users and user attribute conditions as well as objects and object attribute conditions.

$UAR$ : User attribute relation $UAR \subseteq U \times U_{C}$ is a many-to-many mapping of users and user attribute conditions. We use a $m \times n$ binary matrix to represent $UAR$ , where $UAR [i, j] = 1$ , if user $u_{i}$ satisfies an attribute condition ${uc}_{j}$ . As shown in the example in Table 1, user $u_{1}$ is an Manager whose region is WestCoast.

Table 1
$UAR$

User (u) Region = EastCoast ( $u c_{1}$ ) Position = Manager ( $u c_{2}$ ) Region = WestCoast ( $u c_{3}$ ) Position = Associate ( $u c_{4}$ )

$u_{1}$ 0 1 1 0

$u_{2}$ 0 0 1 1

$u_{3}$ 1 1 0 0

$u_{4}$ 1 0 0 1

User (u)	Region = EastCoast ( $u c_{1}$ )	Position = Manager ( $u c_{2}$ )	Region = WestCoast ( $u c_{3}$ )	Position = Associate ( $u c_{4}$ )
$u_{1}$	0	1	1	0
$u_{2}$	0	0	1	1
$u_{3}$	1	1	0	0
$u_{4}$	1	0	0	1

Table 2

$OAR$

Object (o)	Region = WestCoast ( $o c_{1}$ )	Region = EastCoast ( $o c_{2}$ )	Recordof = Customer ( $o c_{3}$ )
$o_{1}$	1	0	1
$o_{2}$	0	1	1

$OAR$ : Object attribute relation, $OAR \subseteq O \times O_{C}$ is a many-to-many mapping of objects and the set of all attributes conditions, where we again use a $m \times n$ binary matrix to represent $OAR$ . $OAR [i, j] = 1$ if an object $o_{i}$ satisfies an object attribute condition ${oc}_{j}$ . Table 2 shows an example where object $o_{1}$ is the recordof Customer in WestCoast region.

2.4.

{ABAC}^{T C}

${ABAC}^{T C}$ : ABAC with time attribute conditions.

$T_{C}$ : Represents a set of all possible time attribute conditions denoted as ${tc}_{j}$ , for $1 ⩽ j ⩽ | T_{C} |$ . Each $t c_{i}$ is of the form of $⟨ [begin, end], calendar ⟩$ , similar to Periodic Expressions, $PE$ , discussed before. For example, for time interval with start time 1 pm and end time 3 pm, time attribute condition ${tc}_{j} = ⟨ [1, 3], pm hours ⟩$ . Corresponding to every $p e$ there is a time attribute condition.

Unlike, $U_{C}$ , and $O_{C}$ , time attribute conditions are evaluated in a way that if any time attribute condition present in an ABAC rule, is satisfied by a user, the user is granted access.

ABAC Policy base $Π_{T A}$ : This represents an ABAC Policy with time attribute conditions in addition to the ABAC policy $Π_{A}$ described before. Each member of this set is denoted as $π_{i}$ , for $1 ⩽ i ⩽ | Π_{T A} |$ , where π is a quadruple of the form $⟨ uc, oc, tc, op ⟩$ . If a user makes a request to access an object at a certain time, the policy base is searched for any rule through which the user can gain access. If such a rule exists, then access is granted, otherwise it is denied.

3. ABAC to RBAC translation

This section presents our methodology to translate the ABAC policy configuration to an equivalent one in RBAC. Towards this end, we first formally define the optimal ABAC to RBAC translation problem and then present our approach.

3.1. Problem formulation

Intuitively, our goal is to discover RBAC roles from ABAC policy base in such a way that the set of RBAC roles is minimum and at the same time the authorizations are the same as those under ABAC. In the following, we formalize the definition of the ABAC to RBAC translation problem.

$A$ : An authorization a having the form of $⟨ u, o, o p ⟩$ denotes that the user u is allowed to perform an operation $o p$ on the object o, where $u \in U$ , $o \in O$ , and $o p \in OPS$ . We use $u . a$ , $o . a$ and $o p . a$ to denote the user, object and operation associated with a. We denote the set of all authorizations as $A$ . For each operation $o p_{i} \in OPS$ , we define $A_{o p_{i}} \subseteq A$ such that for every $a \in A_{o p_{i}}$ , $o p . a = o p_{i}$ . For example, if $OPS = {read, write}$ , we have $A_{read}$ and $A_{write}$ such that $A_{read} \cup A_{write} = A$ .

Given an ABAC policy base $Π_{A}$ , we say $A$ covers π if for every user u and object o combination where u is allowed to perform operation $o p$ on o, there exists an authorization $a = ⟨ u, o, o p ⟩ \in A$ . (In the following subsection, we provide an algorithm on how to derive such $A$ from Π.) Similarly, given an RBAC policy $Π_{R}$ , we say $A$ covers $Π_{R}$ if for every user u and object o combination where u is allowed to perform operation $o p$ on o in $Π_{R}$ , there exists an authorization $a = ⟨ u, o, o p ⟩ \in A$ . Now we are ready to formally define the optimal ABAC to RBAC translation problem.

Problem Statement. Given an ABAC policy $Π_{A}$ , Users $U$ , Objects $O$ , User Attribute relation ( $UAR$ ), and Object Attribute relation ( $OAR$ ), the ABAC to RBAC translation problem is to identify a RBAC policy $Π_{R}$ that includes a set of Roles $R$ , $PA$ and $UA$ such that the set of authorizations $A$ derived from $Π_{A}$ and $Π_{R}$ are equal and the number of roles $| R |$ is minimum.

3.2. Approach

In this section, we discuss how we develop a system that will translate ABAC policies in a manner that they can be implemented by an RBAC. The $UAR$ , $OAR$ and ABAC policy base $Π_{A}$ is fed to an ABAC-RBAC Translator which generates $Π_{R}$ , which includes $R$ and the corresponding $UA$ and $PA$ that form the RBAC policy. The detailed process for translation is described below and has been shown in Fig. 1.

Fig. 1.

Approach for deployment of ABAC in RBAC.

Algorithm 1

Generating $A$ and $UPA$

Table 3

Policy ( $Π_{A}$ )

Attributes	Permission
$u c_{3}$ , $u c_{4}$ , $o c_{1}$ , $o c_{3}$	$o p_{1}$
$u c_{2}$ , $u c_{3}$ , $o c_{1}$ , $o c_{3}$	$o p_{1}$
$u c_{1}$ , $u c_{2}$ , $o c_{2}$ , $o c_{3}$	$o p_{1}$
$u c_{1}$ , $u c_{4}$ , $o c_{2}$ , $o c_{3}$	$o p_{1}$
$u c_{2}$ , $u c_{3}$ , $o c_{1}$ , $o c_{3}$	$o p_{2}$
$u c_{1}$ , $u c_{2}$ , $o c_{2}$ , $o c_{3}$	$o p_{2}$

Table 4

$A$

User u	Object o	Permission $o p_{i}$
$u_{1}$	$o_{1}$	$o p_{1}$
$u_{2}$	$o_{1}$	$o p_{1}$
$u_{3}$	$o_{2}$	$o p_{1}$
$u_{4}$	$o_{2}$	$o p_{1}$
$u_{1}$	$o_{1}$	$o p_{2}$
$u_{3}$	$o_{2}$	$o p_{2}$

Table 5

$UPA$

	$o_{1}$ - $o p_{1}$	$o_{1}$ - $o p_{2}$	$o_{2}$ - $o p_{1}$	$o_{2}$ - $o p_{2}$
$u_{1}$	1	1	0	0
$u_{2}$	1	0	0	0
$u_{3}$	0	0	1	1
$u_{4}$	0	0	1	0

Steps for ABAC to RBAC translation. Step 1. Construct the set of Authorizations $A$ from the User Attribute Relation ( $UAR$ ), Object Attribute Relation ( $OAR$ ) and the ABAC policy base ( $Π_{A}$ ): For each user( $u_{i}$ )-object( $o_{j}$ ) combination from $UAR$ and $OAR$ , we check if their corresponding attribute conditions( $U_{C}$ . $u_{i}$ and $O_{C}$ . $o_{i}$ ) form a superset of any of the given ABAC rules in $Π_{A}$ . For every such superset occurrence, we include the set comprising of user( $u_{i}$ ), object( $o_{j}$ ) and the operation( $o p_{k}$ . $π_{k}$ ) in $A$ . The procedure is automated in the first part of Algorithm 1. As an example, given $UAR$ in Table 1, $OAR$ in Table 2 and Π in Table 3, the derived $A$ is shown in Table 4.

Step 2. Derive User Permission Assignment ( $UPA$ ) from $A$ : The $UPA$ is defined as an $M \times N$ matrix, where $M = | U |$ comprising of a row for each user, and $N = | O$ - $op |$ , comprising of a column for each object and operation combination in $A$ . Using ( $A$ ), we derive ( $UPA$ ) as follows: We consider all the Users in ( $A$ ) and associate the objects with permissions to form PRMS(o-op) in RBAC. There is a row in $UPA$ for each user and a column for each PRMS(o-op). For each row, if the (o-op) is true for that user, the corresponding cell is filled with 1, otherwise with 0. The procedure is automated in the second part of Algorithm 1. Given $A$ in Table 4, the derived $UPA$ is shown in Table 5.

Step 3. Derive User Assignment Relation ( $UA$ ) and Permission Assignment Relation ( $PA$ ) by performing Role Mining: For the automation of this step, we have used DEMiner algorithm proposed by Uzun et al. [15]. The primary reason to choose this is because it generates a compact set of roles which are disjoint in their permissions. As a result, it makes administration of access requests much easier, which is in sync with the idea of this work. When a user requests for a specific permission, there will be a single role with that specific permission, thus making the access control decision faster and efficient. This is the reason why we choose this algorithm as the benchmark. It reduces the administrative cost, as the roles generated are non overlapping and the access request decision is evaluated faster than any other role mining algorithm that produces overlapping roles.

We performed slight modification to the DEMiner algorithm by sorting the users in the $UPA$ in decreasing order of the number of $PRMS$ before applying the algorithm on our dataset. This helped improve the efficiency and effectiveness of the algorithm in terms of time and the number of roles created. Considering our example once again, given $UPA$ in Table 5, the derived $UA$ and $PA$ are shown in Tables 6 and 7, respectively.

Table 6

$UA$

	$r_{1}$	$r_{2}$	$r_{3}$	$r_{4}$
$u_{1}$	1	1	0	0
$u_{2}$	1	0	0	0
$u_{3}$	0	0	1	1
$u_{4}$	0	0	1	0

Table 7

$PA$

	$o_{1}$ - $o p_{1}$	$o_{1}$ - $o p_{2}$	$o_{2}$ - $o p_{1}$	$o_{2}$ - $o p_{2}$
$r_{1}$	1	0	0	0
$r_{2}$	0	1	0	0
$r_{3}$	0	0	1	0
$r_{4}$	0	0	0	1

Theorem 1.

Let $A$ be the set of authorizations covered by $Π_{A}$ and $R$ . If $| Π_{A} |$ is the minimum number of ABAC rules required to cover $A$ and $| R |$ is the minimum number of roles required to cover $A$ , then $| Π_{A} | ⩾ | R |$ .

Proof.

Let ‘k’ be the minimum number of ABAC Rules $| Π_{A} |$ , where $Π_{A} = {π_{1}, π_{2}, π_{3}, \dots, π_{k}}$ that cover a set of authorizations $A$ and let ‘n’ be the minimum number of RBAC roles $R$ that cover the same set of authorizations $A$ is $R = {r_{1}, r_{2}, r_{3}, \dots r_{n}}$ .

Because ‘k’ is the minimum number of rules, each rule covers at least one unique authorization. So, if we map each of the policy rules $π_{i}$ in ABAC to a role $r_{j}$ in RBAC (where both $π_{i}$ and $r_{j}$ cover same set of authorizations in $A$ ), we will get exactly ‘k’ roles. We have shown the same in Example 1 described below. Therefore, for every rule we can create one corresponding role which will cover same set of authorizations. So, we can infer that in all possible cases, the count of roles to express a set of authorizations $A$ will never be more than the count of rules. In the worst case, $| Π_{A} |$ and $| R |$ will be equal.

So far, we know that, for ‘n’ to be the minimum roles required to express $A$ , ‘k’ has to be equal to ‘n’ or greater than ‘n’. Else we cannot say that ‘n’ is the minimum number of roles (i.e. $k ⩾ n$ ). To check if ‘k’ could be less than or equal to ‘n’, we conjecture that, we can map the authorizations expressed by a single role in RBAC to a single rule in ABAC. We use a simple counter example to disprove the above conjecture. We can see in Example 2 below, that for 2 RBAC roles, we need atleast 6 ABAC rules to express the same authorizations. We need 5 ABAC rules: $π_{1}$ , $π_{2}$ , $π_{3}$ , $π_{4}$ and $π_{5}$ to describe authorizations of $r_{1}$ and one ABAC rule $π_{6}$ to describe authorizations of $r_{2}$ . Note that it is impossible to describe role $r_{1}$ by a single ABAC rule as $r_{1}$ covers the set users which satisfy no common attribute condition(s).

In case we have common attributes between users or objects in the role, for example in role $r_{2}$ , user $u_{1}$ and $u_{4}$ have a common attribute ${uc}_{4}$ , then one ABAC rule could cover the same authorizations of $r_{2}$ , i.e. $π_{6}$ (this will give access to both $u_{1}$ and $u_{4}$ to $o_{3}$ to perform $o p_{1}$ as both $u_{1}$ and $u_{4}$ satisfy user attribute condition ${uc}_{4}$ ). Hence, we need at least 6 ABAC Rules to express the authorizations covered by 2 roles. Thus, Example 2 is a testimony to that fact that it is possible to have an RBAC role where no single ABAC rule can express the authorizations of that particular single role.

To conclude, the number of Policy Rules in ABAC is always greater than or equal to the number of Roles in RBAC, i.e., $| Π_{A} | ⩾ | R |$ . □

Example 1.

An ABAC rule $π_{1}$ : $⟨ {uc}_{1}, {oc}_{1}, read ⟩$ gives users $u_{1}$ and $u_{2}$ (both having attribute ${uc}_{1}$ ), read access on object $o_{1}$ (having attribute $o c_{1}$ ); i.e. two authorizations $A_{1}$ and $A_{2}$ , where $A_{1} = ⟨ u_{1}, o_{1}, read ⟩$ and $A_{2} = ⟨ u_{2}, o_{1}, read ⟩$ . The corresponding role $r_{1}$ will be assigned to users( $u_{1}, u_{2}$ ) and will be granted permission ( $o_{1}, read$ ).

Example 2.

An RBAC system which has two roles $r_{1}$ and $r_{2}$ giving authorizations $A$ (Table 8) to four users( $u_{1}$ , $u_{2}$ , $u_{3}$ , $u_{4}$ ). The $UA$ relation is given in Table 9 and $PA$ relation is in Table 10. The users and objects satisfy the attribute conditions as shown in the User Attribute Relation $UAR$ (Table 11) and Object Attribute Relation $OAR$ (Table 12). In total, atleast 6 ABAC policy rules are required to cover the authorizations of both the roles. They are as follows: $\begin{matrix} π_{1} : ⟨ {uc}_{1} ⟩, ⟨ Any ⟩ & π_{4} : ⟨ {uc}_{3} ⟩, ⟨ {oc}_{1} ⟩ \\ π_{2} : ⟨ {uc}_{2} ⟩, ⟨ {oc}_{1} ⟩ & π_{5} : ⟨ {uc}_{3} ⟩, ⟨ {oc}_{2} ⟩ \\ π_{3} : ⟨ {uc}_{2} ⟩, ⟨ {oc}_{2} ⟩ & π_{6} : ⟨ {uc}_{4} ⟩, ⟨ {oc}_{3} ⟩ \end{matrix}$

Table 8

$A$

User	Object	Permission
$u_{1}$	$o_{1}$	$o p_{1}$
$u_{1}$	$o_{2}$	$o p_{1}$
$u_{1}$	$o_{3}$	$o p_{1}$
$u_{2}$	$o_{1}$	$o p_{1}$
$u_{2}$	$o_{2}$	$o p_{1}$
$u_{3}$	$o_{1}$	$o p_{1}$
$u_{3}$	$o_{2}$	$o p_{1}$
$u_{4}$	$o_{3}$	$o p_{1}$

Table 9

$UA$

	$r_{1}$	$r_{2}$
$u_{1}$	1	1
$u_{2}$	1	0
$u_{3}$	1	0
$u_{4}$	0	1

Table 10

$PA$

	$o_{1}$ - $o p_{1}$	$o_{2}$ - $o p_{1}$	$o_{3}$ - $o p_{1}$
$r_{1}$	1	1	0
$r_{2}$	0	0	1

Table 11

$UAR$

User	$u c_{1}$	$u c_{2}$	$u c_{3}$	$u c_{4}$
$u_{1}$	1	0	0	1
$u_{2}$	0	1	0	0
$u_{3}$	0	0	1	0
$u_{4}$	0	0	0	1

Table 12

$OAR$

Object	$o c_{1}$	$o c_{2}$	$o c_{3}$
$o_{1}$	1	0	0
$o_{2}$	0	1	0
$o_{3}$	0	0	1

{ABAC}^{T C}

to TRBAC translation

As an extension of the previous section, in this section we present our methodology to translate the ${ABAC}^{T C}$ (ABAC policy configuration with time attribute conditions) to an equivalent one in TRBAC. Towards this end, we first formally define the optimal ${ABAC}^{T C}$ to TRBAC translation problem and then present an approach which we will be looking at to perform this translation.

4.1. Problem formulation

Intuitively, our goal is to discover temporal roles from ${ABAC}^{T C}$ policy base in such a way that the set of roles is minimum and at the same time the authorizations are the same as those under ${ABAC}^{T C}$ . In the following, we formalize the definition of the ${ABAC}^{T C}$ to TRBAC translation problem.

Mining of Temporal Roles: The input to the temporal role mining process is $TUPA$ -Temporal User-Permission Assignment relation, which describes the sets of time intervals for which one or more permissions are assigned to each user. The $TUPA$ matrix can be easily derived from the Authorizations( $A$ ) and the set of Time Attributes in an ${ABAC}^{T C}$ policy. The rows of the matrix represent the users and the columns represent the permissions. Each cell ( $u_{i}$ , $p_{j}$ ) of the matrix contains either a zero or a set $T_{i j}$ of time intervals for which user $u_{i}$ is assigned permission $p_{j}$ .

Given an ${ABAC}^{T C}$ policy base $Π_{T A}$ , we say $A$ covers $π_{T A}$ if for every user u and object o combination where u is allowed to perform operation $o p$ on o for a time period $t_{i j}$ , there exists an authorization $a = ⟨ u, o, o p, t ⟩ \in A$ . Similarly, given a TRBAC policy $Π_{T R}$ , we say $A$ covers $Π_{T R}$ if for every user u and object o combination where u is allowed to perform operation $o p$ on o during time period $t_{i j}$ in $Π_{T R}$ , there exists an authorization $a = ⟨ u, o, o p ⟩ \in A$ during time duration t.

Now we are ready to formally define the optimal ${ABAC}^{T C}$ to TRBAC translation problem.

Problem Statement. Given an ABAC policy $Π_{T A}$ , Users $U$ , Objects $O$ , User Attribute relation ( $UAR$ ), and Object Attribute relation ( $OAR$ ), a set of Time intervals( $T_{i j}$ ), the ${ABAC}^{T C}$ to TRBAC translation problem is to identify a TRBAC policy $Π_{T R}$ that includes a set of Roles $R$ , $PA$ , $UA$ and Role Enabling Base( $REB$ ) such that the set of authorizations $A$ derived from $Π_{T A}$ and $Π_{T R}$ are equal, the duration for which these authorizations $A$ are activated which is derived from the set of time constraints in ${ABAC}^{T C}$ rules and $REB$ in TRBAC is same and the number of roles $| R |$ is minimum.

4.2. Approach

Now, we discuss how we develop the system that will translate an ${ABAC}^{T C}$ policy to a TRBAC system. The $UAR$ , $OAR$ , ABAC policy base $Π_{T A}$ (with time constraints) is fed to an ABAC-TRBAC Translator which generates $Π_{T R}$ , which includes $R$ , $REB$ and the corresponding $UA$ and $PA$ that form the TRBAC policy. The detailed process for translation is described below and has been shown in Fig. 2. Similar to the approach discussed in the previous section, we translate the ${ABAC}^{T C}$ to a TRBAC system by first constructing the Authorizations $A$ . Then the Authorizations are combined with the Time Attributes/constraints in the ${ABAC}^{T C}$ Policy $Π_{T A}$ to construct $TUPA$ . Post this step, a Temporal Role mining algorithm can be used to obtain $R$ , $REB$ and the corresponding $UA$ and $PA$ that form the TRBAC policy.

Fig. 2.

Approach for deployment of ABAC with time constraints in TRBAC.

Example 3.

Consider

UA R_{T A}

in Table 13(a),

OA R_{T A}

in Table 13(b) and ABAC policy in Table 13(c). Here,

t c_{1} = 1 am– 3 am

t c_{2} = 2 am– 5 am

and

t c_{3} = 7 am– 8 am

. Using these we create the

TUPA

in Table 14. We perform Temporal Role mining in the

TUPA

to get

UA

PA

and

REB

shown in Tables 15(a), 15(b) and 15(c).

Table 13

$U A R_{T A}$ , $O A R_{T A}$ , and $Π_{T A}$ for organization $G_{1}$

(a) $U A R_{T A}$					(b) $O A R_{T A}$					(c) $Π_{T A}$

U	$u c_{1}$	$u c_{2}$	$u c_{3}$	$u c_{4}$	$O_{1}$	$o c_{1}$	$o c_{2}$	$o c_{3}$	$o c_{4}$	Rule	Attributes
$u_{1}$	0	1	0	1	$o_{1}$	1	0	1	0	$π_{1}$	$u c_{2}$ , $o c_{3}$ , $t c_{1}$ , r
$u_{2}$	1	0	0	0	$o_{2}$	0	0	1	0	$π_{2}$	$u c_{4}$ , $o c_{3}$ , $t c_{2}$ , r
$u_{3}$	0	1	0	0	$o_{3}$	0	1	0	0	$π_{3}$	$u c_{2}$ , $o c_{2}$ , $t c_{3}$ , r
$u_{4}$	1	0	0	0						$π_{4}$	$u c_{1}$ , $o c_{1}$ , $t c_{1}$ , $t c_{3}$ , r

Table 14

$TUPA$

	$p_{1}$	$p_{2}$	$p_{3}$
$u_{1}$	1 am–3 am, 2 am–5 am	1 am–3 am, 2 am–5 am	7 am–8 am
$u_{2}$	1 am–3 am, 7 am–8 am	0	0
$u_{3}$	1 am–3 am,	1 am–3 am	7 am–8 am
$u_{4}$	1 am–3 am, 7 am–8 am	0	0

Table 15

$U A_{T A}$ , $O A_{T A}$ , and $R E B_{T A}$

(a) $U A_{T A}$						(b) $O A_{T A}$				$R E B_{T A}$

U	$r_{1}$	$r_{2}$	$r_{3}$	$r_{4}$	$r_{5}$	$O_{1}$	$p_{1}$	$p_{2}$	$p_{3}$	Role	Enabling Time Interval
$u_{1}$	1	1	1	0	1	$r_{1}$	1	0	0	$r_{1}$	1 am–3 am
$u_{2}$	1	0	0	1	0	$r_{2}$	1	1	0	$r_{2}$	1 am–5 am
$u_{3}$	1	0	1	0	1	$r_{3}$	0	0	1	$r_{3}$	7 am–8 am
$u_{3}$	1	0	0	1	0	$r_{4}$	1	0	0	$r_{4}$	7 am–8 am
						$r_{5}$	0	1	0	$r_{5}$	1 am–3 am

While there are different approaches for Temporal Role Mining, in this paper, we have used the approach proposed by Mitra et al. [12]. They present an approach to select a minimal set of roles using a greedy heuristic.

5. Experimental comparison of access request evaluation cost

5.1. ABAC and RBAC

In order to compare the time taken for access request (AR) evaluation, the same ABAC and RBAC policy, we need to first create two equivalent policies and compare the time taken to evaluate the same set of access requests. This is done as follows. First, a synthetic ABAC policy base ( $Π_{A}$ ) is created. For creating synthetic ABAC Policies we used the data generator used by Talukdar et al. [14]. Next, using the ABAC policy base and the User Attribute relation ( $UAR$ ) and Object Attribute Relation ( $OAR$ ), the ( $UPA$ ) relation is created, on which Role Mining is done on the ( $UPA$ ) relation to create the User Assignment ( $UA$ ) and Role Assignment ( $PA$ ) relation. Any Role Mining algorithm could be used (for e.g. [16]), as long as it completely covers the given $UPA$ . In this particular case, we use the DEMiner algorithm proposed by Uzun et al. [15].

For each set of experiments, we have compared the access request evaluation time for both ABAC and RBAC. The experiments are performed on a Intel Core i7 2.60 GHz machine with 8.00 GB memory running 64-bit Windows 10. Since we are interested in seeing how the access request evaluation cost changes with respect to different parameters, we run fours sets of experiments where one parameter is varied while keeping the rest constant. Specifically, we examine the following four different scenarios: 1) increasing the rule size, 2) increasing the number of attributes in ABAC rules, 3) increasing the number of users and objects, and 4) increasing the count of positive authorizations. Here positive authorizations imply access requests that should be granted, while negative authorizations imply access requests that should be rejected. To compare the efficiency of ABAC and RBAC, we have evaluated the time taken to evaluate access requests for 100 user-object pairs. For the first three cases, we take 50 random positive authorizations and 50 random negative authorizations. For the last case, we have increased the count of positive authorizations and reduced the count of negative authorizations by keeping total access requests at 100. Further these access request evaluations were run three times and the time was averaged over all of these runs.

The key parameters are the number of users ( $U$ ), objects ( $O$ ), user attributes ( $U_{C}$ ), object attributes ( $O_{C}$ ), number of rules given ( $Π_{A}$ ) to the ABAC system. In Tables 16, 17 and 18, the first column $| U |$ is count of users, the second column $| O |$ is count of objects, third column $| U_{C} |$ is count of user attribute conditions, fourth column $| O_{C} |$ is count of object attribute conditions, fifth column $| Π_{A} |$ is count of ABAC policy rules, $| R |$ is the number of RBAC roles discovered after role mining, $A v g R T_{ABAC}$ is the average run time for ABAC and $A v g R T_{RBAC}$ is the average run time for RBAC. In Table 19, there are two additional columns for count of Positive Authorizations and Negative Authorizations.

For all the experiments, we observe that the count of roles $| R |$ discovered after role mining is much less than the count of ABAC policy rules $| Π_{A} |$ for the same set of authorizations. We can also observe that the run time for access request evaluation for ABAC is significantly greater than the run time for access request evaluation for RBAC. Next we see the individual effects of varying the parameters while keeping all others constant.

Table 16
Increasing rule size

$| U |$ $| O |$ $| U_{C} |$ $| O_{C} |$ $| Π_{A} |$ $| R |$ $A v g R T_{ABAC}$ (in ms) $A v g R T_{RBAC}$ (in ms)

200 200 500 500 500 200 19.385 0.032

200 200 500 500 1000 200 35.227 0.032

200 200 500 500 2000 200 69.108 0.032

$\| U \|$	$\| O \|$	$\| U_{C} \|$	$\| O_{C} \|$	$\| Π_{A} \|$	$\| R \|$	$A v g R T_{ABAC}$ (in ms)	$A v g R T_{RBAC}$ (in ms)
200	200	500	500	500	200	19.385	0.032
200	200	500	500	1000	200	35.227	0.032
200	200	500	500	2000	200	69.108	0.032

Fig. 3.

Increasing rule size.

Varying number of ABAC rules: Table 16 and Fig. 3 show the results obtained for access request evaluation time of ABAC and RBAC, while increasing the count of ABAC Rules, but keeping all other parameters constant. We have varied the ABAC rule count between 500, 1000, and 2000. We observe that the count of RBAC roles discovered was 200 in all the three cases. The average access request evaluation time for RBAC remains roughly the same, whereas the access request evaluation time for ABAC increases linearly. This is due to the fact that the size of $UA$ and $PA$ remain the same for the three cases, whereas the count of ABAC rules to be checked for granted access doubles each time.

Table 17

Increasing attribute size

$\| U \|$	$\| O \|$	$\| U_{C} \|$	$\| O_{C} \|$	$\| Π_{A} \|$	$\| R \|$	$A v g R T_{ABAC}$ (in ms)	$A v g R T_{RBAC}$ (in ms)
200	200	500	500	500	200	19.385	0.032
200	200	1000	1000	500	200	35.381	0.032
200	200	2000	2000	500	200	73.894	0.033

Fig. 4.

Increasing attribute size.

Varying number of User and Object Attributes: Table 17 and Fig. 4 show the results obtained for access request evaluation time of ABAC and RBAC, while increasing the count of Users Attributes and Objects Attributes for ABAC policy rules, while keeping all other parameters constant. We have increased both user and object attribute counts for ABAC rules using values 500, 1000 and 2000 for both. We observe that the count of RBAC roles discovered was 200 in all three cases. The average access request evaluation time for RBAC remains roughly the same, whereas the access request evaluation time for ABAC increases linearly. This is because of the fact that the size of $UA$ and $PA$ relation remains the same for the three cases, whereas the count of attributes to be checked for granting access in each rule increases.

Varying number of Users and Objects: Table 18 and Fig. 5 show the results obtained for access request evaluation time of ABAC and RBAC, while increasing the count of Users and Objects, but keeping all other parameters constant. Again, we observe that the average access request evaluation time in ABAC is almost 75 times that of RBAC.

Table 18

Increasing user/object size

$\| U \|$	$\| O \|$	$\| U_{C} \|$	$\| O_{C} \|$	$\| Π_{A} \|$	$\| R \|$	$A v g R T_{ABAC}$ (in ms)	$A v g R T_{RBAC}$ (in ms)
300	300	150	150	50	41	0.656	0.008
400	400	150	150	50	41	0.705	0.008
500	500	150	150	50	41	0.658	0.009

Fig. 5.

Increasing user object size.

Table 19

Increasing positive authorisations

$\| U \|$	$\| O \|$	$\| U_{C} \|$	$\| O_{C} \|$	$\| Π_{A} \|$	$\| R \|$	Positive accesses	Negative accesses	$A v g R T_{ABAC}$ (in ms)	$A v g R T_{RBAC}$ (in ms)
200	200	2000	2000	500	200	0	100	128.640	0.032
200	200	2000	2000	500	200	20	80	106.464	0.031
200	200	2000	2000	500	200	40	60	86.615	0.032
200	200	2000	2000	500	200	60	40	65.242	0.032
200	200	2000	2000	500	200	80	20	46.610	0.031
200	200	2000	2000	500	200	100	0	25.495	0.032

Fig. 6.

Increasing positive authorizations.

Varying number of Positive Authorizations: Table 19 and Fig. 6 show the results obtained for access request evaluation time of ABAC and RBAC, while varying the count of positive authorizations, but keeping all other parameters constant. Out of the 100 random user-object access requests we predetermine the number of accesses that would evaluate to be positive (granted). These positive access requests were varied between the values 0, 20, 40, 60, 80, and 100, with the remaining requests used being negative requests. We observe that the average access request evaluation time in RBAC is roughly the same as earlier, however the average access request evaluation time in ABAC has reduced linearly. An ABAC system checks each policy rule, one by one, to see if it can grant the access. When an access request is granted, no further policy rules need to be checked; whereas, when an access request is denied the ABAC system keeps on checking all the policy rules it has.

The overall results indicate the fact that evaluation of access requests in RBAC is significantly faster across the board in all cases than those of ABAC.

5.2.

{ABAC}^{T C}

and TRBAC

We observed in our previous set of experiments that the access request evaluation time for RBAC is much less than ABAC. RBAC only needs to go through $UA$ , $PA$ and $REB$ to evaluate an access request, whereas ABAC needs to check all rules and go through each attribute while evaluating an access request. On similar lines, in this part, we will compare the time taken for access request (AR) evaluation in ${ABAC}^{T C}$ and TRBAC policy, however, here we compare against varying time attributes in the ABAC policy. The idea is to understand the effect on Access Request(AR) evaluation after adding time constraints in an ABAC policy and compare it with an equivalent TRBAC policy. Next, we will study how the # of ABAC rules compare to the # of TRBAC roles by varying the count of the time component of ${ABAC}^{T C}$ rules, i.e., count of time attribute conditions in ABAC rules and the same factors as before (rulesize, attribute count and user-object count).

Similar to previous experiments, we begin by creating two equivalent policies – ABAC policy with time attribute conditions and it’s equivalent RBAC policy with Temporal roles.

First, a synthetic ${ABAC}^{T C}$ policy base ( $Π_{T A}$ ) is created. To create an $ABAC$ policy rule, user and object attribute conditions ( $U_{C}$ and $O_{C}$ ) are assigned randomly to it. ${ABAC}^{T C}$ policies are created by adding time attribute conditions to the $ABAC$ policy. For our experiments we have added $T_{C} = 1$ , 2 and 5. We ensured to cover all possible combinations of presence of time attribute conditions in the policy rules. Next, the User Attribute Relation ( $UAR$ ) and Object Attribute Relation ( $OAR$ ) are created by assigning attributes to users and objects randomly. It was also ensured that every rule in the policy base covers at least one authorization. Next, using the ${ABAC}^{T C}$ policy base and the User Attribute relation ( $UAR$ ) and Object Attribute Relation ( $OAR$ ), the Temporal UPA ( $TUPA$ ) relation is created, on which Temporal Role Mining is performed to create the User Assignment ( $UA$ ) and Role Assignment ( $PA$ ) and Role Enabling Base ( $REB$ ) relations. Any Temporal Role Mining algorithm could be used, as long as it completely covers the given $TUPA$ . In this particular case, we use the algorithm proposed by Mitra et al. [12] which minimizes the number of roles created using greedy heuristic.

For each set of experiments, we have compared the count of rules in ${ABAC}^{T C}$ and count of temporal roles in TRBAC, varying two parameters in each. We run four sets of experiments where two parameters are varied while keeping the rest constant. Specifically, we examine the following four different scenarios: 1) Increasing the rule size and increasing the # of time attribute conditions in a rule 2) Increasing the number of attributes in ABAC rules and increasing the # of time attribute conditions in a rule 3) Increasing the number of users and objects and increasing the # of time attribute conditions in a rule. 4) In another experiment, we compare the access request evaluation time for 100 access requests (50 positive and 50 negative) in ${ABAC}^{T C}$ and TRBAC while increasing the # of time attribute conditions in the policy rules. Every observation was obtained by running the experiments for 5 random inputs. For sake of simplicity, we considered the time attribute conditions to be disjoint and non contiguous. Also, the set of time attribute conditions for every $T_{C}$ value were same cross all runs. We ensured that their is atleast 1 combination of every possible length of the time attribute condition set $T_{C}$ .

Table 20
Evaluating roles: increasing rule size and time attribute conditions

$| U |$ $| O |$ $| U_{C} |$ $| O_{C} |$ $| Π_{T A} |$ $| R_{T} |$ ( $| T_{C} | = 1$ ) $| R_{T} |$ ( $| T_{C} | = 2$ ) $| R_{T} |$ ( $| T_{C} | = 5$ )

70 70 100 100 35 30.6 41.5 73.8

70 70 100 100 45 34.6 48 84.2

70 70 100 100 55 40.4 53.6 99.6

$\| U \|$	$\| O \|$	$\| U_{C} \|$	$\| O_{C} \|$	$\| Π_{T A} \|$	$\| R_{T} \|$ ( $\| T_{C} \| = 1$ )	$\| R_{T} \|$ ( $\| T_{C} \| = 2$ )	$\| R_{T} \|$ ( $\| T_{C} \| = 5$ )
70	70	100	100	35	30.6	41.5	73.8
70	70	100	100	45	34.6	48	84.2
70	70	100	100	55	40.4	53.6	99.6

Table 21

Evaluating roles:increasing user-object attributes and time attribute conditions

$\| U \|$	$\| O \|$	$\| U_{C} \|$	$\| O_{C} \|$	$\| Π_{T A} \|$	$\| R_{T} \|$ ( $\| T_{C} \| = 1$ )	$\| R_{T} \|$ ( $\| T_{C} \| = 2$ )	$\| R_{T} \|$ ( $\| T_{C} \| = 5$ )
70	70	100	100	35	30.6	41.5	75.8
70	70	150	150	35	31.8	42.4	79.2
70	70	200	200	35	30.4	40.2	75.8

Table 22

Evaluating roles:increasing user-object count and time attribute conditions

$\| U \|$	$\| O \|$	$\| U_{C} \|$	$\| O_{C} \|$	$\| Π_{T A} \|$	$\| R_{T} \|$ ( $\| T_{C} \| = 1$ )	$\| R_{T} \|$ ( $\| T_{C} \| = 2$ )	$\| R_{T} \|$ ( $\| T_{C} \| = 5$ )
50	50	100	100	35	26	35.2	63.25
60	60	100	100	35	28.2	37.8	69.4
70	70	100	100	35	30.6	41.5	75.8

Table 23

Access request evaluation time: increasing time attribute conditions

$\| T_{C} \|$	$A v g R T_{{ABAC}^{T C}}$ (in ms)	$A v g R T_{TRBAC}$ (in ms)
1	98.11	6.31
2	97.87	6.91
5	98.13	12.35

The key parameters are the number of users ( $U$ ), objects ( $O$ ), user attributes ( $U_{C}$ ), object attributes ( $O_{C}$ ), number of rules given ( $Π_{T A}$ ) to the ABAC system. In Tables 20, 21 and 22, 23, column $| U |$ is count of users, the column $| O |$ is count of objects, column $| U_{C} |$ is count of user attribute conditions, column $| O_{C} |$ is count of object attribute conditions,column $| T_{C} |$ is # of time attribute conditions in ABAC rules, column $| Π_{T A} |$ is count of ABAC policy rules, the cells in Tables 20, 21 and 22 contain $| R_{T} |$ , which is the number of RBAC roles discovered after role mining, $A v g R T_{{A B A C}^{T C}}$ is the average run time for ${ABAC}^{T C}$ and $A v g R T_{TRBAC}$ is the average run time for TRBAC.

For the first three experiments, we observe that the count of temporal roles $| R_{T} |$ discovered after temporal role mining is less than the count of ABAC policy rules $| Π_{T A} |$ for the same set of authorizations when $| T_{C} | = 1$ as this case is same as non temporal role mining discussed in previous section. On increasing $| T_{C} |$ , the count of temporal roles, $| R_{T} |$ , also increases. In general, $| R_{T} |$ becomes greater than $| Π_{T A} |$ as # of time attribute conditions $| T_{C} |$ increases. We also observe that the run time for access request evaluation for ${ABAC}^{T C}$ is greater than the run time for access request evaluation for TRBAC, i.e., $A v g R T_{TRBAC} < A v g R T_{{A B A C}^{T C}}$ .

Next we see the individual effects of varying the parameters while keeping all others constant.

Fig. 7.

Assessing TRBAC using ${ABAC}^{T C}$ policy.

Varying number of ABAC rules and Time Attribute Conditions: Effect on # Roles Table 20 and Fig. 7(c) show the results obtained for increasing # of ABAC policy rules( $Π_{T A}$ ), while also increasing ABAC time attribute conditions ( $| T_{C} |$ ), but keeping all other parameters constant.

We have varied the ${ABAC}^{T C}$ rule count between 35, 45, and 55. We observe that the count of TRBAC roles discovered increases with increasing the number of ABAC rules. This is due to the fact that number of permissions increase. We also observe that for a particular rule count, the count of TRBAC roles generated increase significantly with increasing $T_{C}$ . This is because on increasing the time attribute conditions, the permissions increase and the number of temporal roles created also increase.

Varying number of User and Object Attributes and Time Attribute Conditions:Effect on # Roles

Table 21 and Fig. 7(b) show the results obtained for increasing # of User and Object Attributes, while also increasing the Time Attribute Conditions, but keeping all other parameters constant.

We have increased both user and object attributes counts using values 100, 150 and 200 for both. We observe that, for a particular value of $T_{C}$ , the count of temporal roles created does not depend on the user/object attribute count. There is no significant effect on the count of temporal roles due to increase in the User/Object Attribute conditions. However, we observe from Fig. 7b, that # of temporal roles increase with the increasing value of $T_{C}$ . As $T_{C}$ is increased, more temporal roles are created. This is due to increase in number of permissions. We also notice that temporal roles are more than the ABAC rules.

Varying number of Users and Objects and Time Attribute Conditions:Effect on # Roles

Table 22 and Fig. 7(a) show the results obtained for increasing # of Users and Objects, while also increasing the Time Attribute Conditions, but keeping all other parameters constant.

We have increased both user and object counts using values 50, 60 and 70 for both. We observe that, for a set of users and objects, when $T_{C}$ is increased, more temporal roles are created. This is due to increase in number of permissions. We also notice that temporal roles are more than the ABAC rules. Also, for a particular $T_{C}$ the count of TRBAC roles discovered is increasing slightly as the users and objects increase. The increase is insignificant for $T_{C} = 1$ , however, as $T_{C}$ increases, the increase in # of roles is increasing.

Fig. 8.

AR evaluation in ${ABAC}^{T C}$ and TRBAC.

Varying Time Attribute Conditions: Effect on Access Request Evaluation Time

Table 23 and Fig. 8 show the access request evaluation time for ${ABAC}^{T C}$ and TRBAC, obtained for increasing time attribute conditions in ${ABAC}^{T C}$ rules. We have calculated the average access request evaluation time for 100 access requests (50 positive and 50 negative). We observe that the access request evaluation time for ${ABAC}^{T C}$ with temporal constraints is atleast 10 times that of TRBAC. Also the average AR Evaluation time for both ${ABAC}^{T C}$ and TRBAC does not vary significantly if the # of $T_{C}$ is increased.

6. Maintenance cost comparison

In this section, we discuss the configuration and the maintenance cost while dealing with various changes to the ABAC policy and the cost of translating them into an equivalent RBAC policy.

6.1. ABAC and RBAC

The list of operations that can be performed on the original ABAC policy system is as follows:

Addition/Deletion of Rules

Addition/Deletion of Users/Objects

Addition/Deletion of User/Object Attributes

Addition/Deletion of Attributes in ABAC Rules

We know that in ABAC, the initial configuration cost is the sum of number of attributes of users, objects and the policy rules, i.e., $| U_{C} | + | O_{C} | + | Π_{A} |$ . Whereas, when we implement ABAC in an RBAC system, the initial configuration cost will be the sum of the number of user role assignments and role permission assignments, i.e., $| UA | + | PA |$ . The maintenance cost of the above mentioned operations will be negligible in case of an ABAC system as every access request is evaluated at the time of enforcement. However, if we wish to deploy the ABAC policies using an RBAC system with our approach, the maintenance cost for some operations vary from making changes to the RBAC system directly to performing the entire ABAC-RBAC translation again. In the following, we have identified the maintenance cost associated with each change operation. While Fig. 9 provides the overview of how these changes are handled, the exact approach for each change is discussed in detail. To discuss the way these change operations are handled, we have divided them into two types based on the type of effort required. Specifically, some changes require the ABAC-RBAC translation to be done all over. On the other hand, due to the additional information that we maintain, they do not require such translation to be done again, but lend itself to make the relevant changes to the RBAC policy directly. In the following subsections, we elaborate on these cases, and discuss what additional information need to maintained. It turns out that, very few cases require performing the ABAC-RBAC translation all over again.

Fig. 9.

Management of administrative operations on the ABAC-RBAC system.

6.1.1. Changes requiring direct modification to the RBAC policy

Addition of Users: When a new user is added to the system, the $UPA$ changes which would require performing role mining all over again. However, if we keep the user attributes required for that role, we can avoid this expensive step, as we can simply derive which role to assign to the user. Therefore, we create a Role User Attribute Assignment Relation $RUA$ , which is a many-to-many mapping of roles to user attribute conditions, i.e., $RUA \subseteq R \times U_{C}$ . We use a $m \times n$ binary matrix to represent $RUA$ , where $RUA [i, j] = 1$ , if user attribute condition ${uc}_{j}$ is present in all the users assigned to a role $r_{j}$ .

For example, we created a $RUA$ in Table 24 using Tables 1 and 6. Notice that role $r_{1}$ in $RUA$ , has $u c_{3} = 1$ as $u c_{3}$ is present in both the users assigned to $r_{1}$ ( $u_{1}$ and $u_{2}$ ). Basically, attribute conditions assigned to a role are the set of maximum possible common attribute conditions of users in a given role. When a new user is added we can now simply select the roles to be assigned to this user by checking if user has the user attributes necessary for the role. A new row will be added to $UA$ to reflect this.

Table 24
$RUA$

Role $u c_{1}$ $u c_{2}$ $u c_{3}$ $u c_{4}$

$r_{1}$ 0 0 1 0

$r_{2}$ 0 1 1 0

$r_{3}$ 1 0 0 0

$r_{4}$ 1 0 0 1

Role	$u c_{1}$	$u c_{2}$	$u c_{3}$	$u c_{4}$
$r_{1}$	0	0	1	0
$r_{2}$	0	1	1	0
$r_{3}$	1	0	0	0
$r_{4}$	1	0	0	1

Table 25

$ROA$

Role	$o c_{1}$	$o c_{2}$	$o c_{3}$	$o p_{1}$	$o p_{2}$
$r_{1}$	1	0	1	1	0
$r_{2}$	1	0	1	0	1
$r_{3}$	0	1	1	1	0
$r_{4}$	0	1	1	0	1

Addition of Objects: Similar to the case of adding a new user, in this case we maintain a Role Object Attribute Assignment Relation $ROA$ which is a many-to-many mapping of roles to object attribute conditions ( $O_{c}$ ) and operations ( $OPS$ ), i.e., $ROA \subseteq R \times (O_{C} \cup OPS)$ . We again use a $m \times n$ binary matrix to represent $ROA$ , where $ROA [i, j] = 1$ , if object attribute condition ${oc}_{j}$ (or op) is present in all the objects (or operations) assigned to a role $r_{j}$ . Table 25 shows $ROA$ created using Tables 2 and 7. The attribute conditions assigned to a role are the set of maximum possible common set of object attribute conditions and permissions in a given role. When a new object is added, we select the roles that contain the permissions to perform an operation on the object by checking if the object has the object attributes necessary for the role. $PA$ relation will be updated with this $PRMS$ (o-op) by adding a corresponding column to it.

Deletion of Users/Objects: When a user is removed, the row corresponding to that user is deleted from $UA$ . Similarly, on deletion of an object, all the permissions associated with the object will be deleted from $PA$ .

Addition of User/Object Attributes: Addition of new attributes to a user requires updates to $UA$ . Essentially, we need to delete the earlier record of this user from $UA$ and find the new roles to be assigned from $RUA$ based on this new set of attributes. Similarly, when new attributes to an object are added, the row pertaining to the object needs to be deleted from $PA$ , and a new row need to be added based on this new set of attributes after checking eligibility using $ROA$ .

Addition of Rules: Upon adding an ABAC rule, since the $UPA$ changes accordingly, we need to redo the ABAC-RBAC translation step to generate the new $UA$ and $PA$ . However, there is an alternative to avoid this expensive step. Instead, one can add a new role corresponding to this new ABAC rule by examining the users and objects satisfying this new rule and reflect that in $UA$ and $PA$ . While this is somewhat a manual process, this avoids redoing the translation every time a new ABAC rule is added. However, in this case, the translation step can be performed after a batch of ABAC rules are added. Note, however, that this action might create redundant roles in the system.

6.1.2. Changes requiring redoing of ABAC-RBAC translation

Deletion of Rules: On deleting an ABAC rule, the $UPA$ changes, and as a result the step of ABAC-RBAC translation has to be redone, which generates new $UA$ and $PA$ .

Addition/Deletion of attributes to ABAC Rules: Since addition or deletion of attributes to a ABAC rule essentially creates a new rule, it results in a new $UPA$ . Therefore, it requires redoing of the ABAC-RBAC translation step.

6.2. ${ABAC}^{T C}$ and TRBAC

In TRBAC, in addition to the other relations, we maintain the REB relation. However, most maintenance operations happen in the similar fashion as in RBAC. The operations that will impact the REB are as follows:

Mainly the Addition of new rule is the operation that will require updation of REB as well. When we add a new role corresponding to a new ABAC rule, in TRBAC, we will need to update the UA, PA and REB all together. We can see the updation in Fig. 10

Besides this, there is possibility of another operation of Addition/Deletion of Time Attributes in ${ABAC}^{T C}$ rules. This will be dealt in the same way as Addition/ Deletion of Attributes to ABAC rules in the previous section. This will lead to creation of a new TUPA and we will need to redo the Temporal Role Mining process.

Fig. 10.

Management of administrative operations in ${ABAC}^{T C}$ –TRBAC system.

7. Related work

There have been attempts in past to integrate ABAC and RBAC. Authors have proposed methods to unify both the models to get benefits of both. Kuhn et al. [10] discussed incorporating attributes into roles to combine the best of ABAC and RBAC and provide an effective access control. Also, Al-Kahtani et al. [1] proposed a model to dynamically assign users to roles using attribute based rules. Further, Jin et al. [9] proposed RABAC: Role-centric Attribute based Access Control where they extend RBAC with user and object attributes and also add a Permission Filtering Policy (PFP) to their model. All these focus on extending RBAC rather than using the basic RBAC that is available in most commercial implementations today.

Huang et al. [7] have proposed a model to integrate ABAC and RBAC at two levels: aboveground and underground. The aboveground level is RBAC model with environment constraints added to it and the underground level uses attribute-based policies for user-role assignment and role-permission assignment. Their work is different from that of ours as they focus on a top-down model to integrate ABAC and RBAC.

To the best of our knowledge, there have been no attempts to address this problem of deployment of an ABAC policy in a RBAC system. The NIST report on ABAC [6] mentions that “while it is possible to achieve ABAC objectives using ACLs or RBAC, demonstrating access control (AC) requirements compliance is difficult and costly due to the level of abstraction required between the AC requirements and the ACL or RBAC model. Another problem with ACL or RBAC models is that if the AC requirement is changed, it may be difficult to identify all the places where the ACL or RBAC implementation needs to be updated.” Our approach attempts to draw the benefits from ABAC as well as RBAC by automatically translating a ABAC policy into RBAC.

8. Conclusions and future work

In this paper, we demonstrate how ABAC can be deployed using an RBAC or TRBAC system. Our evaluation shows that the access request evaluation cost of RBAC and TRBAC is always less than the cost of the ABAC system while implementing the same policy. However, since RBAC’s maintenance cost is higher than that of ABAC, we also discuss several mitigation strategies to minimize the cost of various administrative operations that cause changes to ABAC. In future, we plan to implement this deployment approach while enforcing segregation of duty constraints [8]. In this work, we assumed there were no temporal constraints on users’s attributes in ABAC. In future, we would like to include them as well and see how they translate into a more dynamic RBAC model.

Footnotes

Acknowledgments

Research reported in this publication was supported by the National Institutes of Health under award R01GM118574, by the National Science Foundation under awards CNS-1564034, CNS-1624503 and CNS-1747728 and by the National Academies of Sciences, Engineering, and Medicine under the PAK-US Science and Technology Cooperation Program. The content is solely the responsibility of the authors and does not necessarily represent the official views of the agencies funding the research. We would like to thank Dr. Barsha Mitra for sharing the code of Temporal Role Mining algorithm with us. We would also like to thank Dr. Emre Uzun for his comments.

References

Al-Kahtani and

Sandhu, A model for attribute-based user-role assignment, in: IEEE, 2002, pp. 353–362.

Batra,

Atluri,

Vaidya and

Sural, Enabling the deployment of ABAC policies in RBAC systems, in: DBSec, 2018, pp. 51–68.

Bertino,

Bonatti and

Ferrari, TRBAC: A temporal role-based access control model, in: ACM Transactions on Information and System Security (TISSEC), 2001, pp. 191–233.

Fisher,

Brickman,

Burden,

Jha,

Johnson,

Keller,

Kolovos,

Umarji and

Weeks, Attribute Based Access Control, 2017, In NIST SPECIAL PUBLICATION 1800-3.

Hu,

Kuhn and

Ferraiolo, Attribute-based access control, in: IEEE, 2015, pp. 85–88.

V.C.

Hu,

Ferraiolo,

Kuhn,

Schnitzer,

Sandlin,

Miller and

Scarfone, Guide to Attribute Based Access Control (ABAC) Definition and Considerations, NIST Special Publication, pp. 800–162.

Huang,

Nicol,

Bobba and

Huh, A framework integrating attribute-based policies into role-based access control, in: SACMAT, 2012, pp. 187–196. doi:10.1145/2295136.2295170.

Jha,

Sural,

Atluri and

Vaidya, Enforcing separation of duty in attribute based access control systems, in: ICISS, 2015, pp. 61–78.

Jin,

Sandhu and

Krishnan, RABAC: Role-centric attribute-based access control, in: MMM-ACNS, 2012, pp. 84–96.

10.

Kuhn,

Coyne and

Weil, Adding attributes to role-based access control, in: IEEE Comput, Vol. 43, 2010, pp. 79–81.

11.

Market Trends:, Cloud-Based Security Services Market, Worldwide, 2014, https://www.gartner.com/doc/2607617 [accessed August 21, 2015].

12.

Mitra,

Sural,

Atluri and

Vaidya, Toward mining of temporal roles, in: Proceedings of the 27th International Conference on Data and Applications Security and Privacy XXVII, 2013, pp. 65–80. doi:10.1007/978-3-642-39256-6_5.

13.

Sandhu,

Coyne,

Feinstein and

Youman, Role-based access control models, in: IEEE Computer, 1996, pp. 38–47.

14.

Talukdar,

Batra,

Vaidya,

Atluri and

Sural, Efficient bottom-up mining of attribute based access control policies, in: IEEE, 2017, pp. 339–348.

15.

Uzun,

Lorenzi,

Atluri,

Vaidya and

Sural, Migrating from DAC to RBAC, in: DBSec, 2015, pp. 69–84.

16.

Vaidya,

Atluri and

Guo, The role mining problem: Finding a minimal descriptive set of roles, in: SACMAT, 2007, pp. 175–184. doi:10.1145/1266840.1266870.

Deploying ABAC policies using RBAC systems

Abstract

Keywords

1. Introduction

2. Preliminaries

2.1. RBAC

2.2. TRBAC

2.3. ABAC

Table 1 UAR User (u) Region = EastCoast ( u c 1 ) Position = Manager ( u c 2 ) Region = WestCoast ( u c 3 ) Position = Associate ( u c 4 ) u 1 0 1 1 0 u 2 0 0 1 1 u 3 1 1 0 0 u 4 1 0 0 1

3. ABAC to RBAC translation

3.1. Problem formulation

3.2. Approach

4.1. Problem formulation

4.2. Approach

5.1. ABAC and RBAC

Table 16 Increasing rule size | U | | O | | U C | | O C | | Π A | | R | A v g R T ABAC (in ms) A v g R T RBAC (in ms) 200 200 500 500 500 200 19.385 0.032 200 200 500 500 1000 200 35.227 0.032 200 200 500 500 2000 200 69.108 0.032

Table 20 Evaluating roles: increasing rule size and time attribute conditions | U | | O | | U C | | O C | | Π T A | | R T | ( | T C | = 1 ) | R T | ( | T C | = 2 ) | R T | ( | T C | = 5 ) 70 70 100 100 35 30.6 41.5 73.8 70 70 100 100 45 34.6 48 84.2 70 70 100 100 55 40.4 53.6 99.6

6.1. ABAC and RBAC

Table 24 RUA Role u c 1 u c 2 u c 3 u c 4 r 1 0 0 1 0 r 2 0 1 1 0 r 3 1 0 0 0 r 4 1 0 0 1

6.2. ABAC T C and TRBAC

8. Conclusions and future work

Footnotes

Acknowledgments

References

Table 1
$UAR$

User (u) Region = EastCoast ( $u c_{1}$ ) Position = Manager ( $u c_{2}$ ) Region = WestCoast ( $u c_{3}$ ) Position = Associate ( $u c_{4}$ )

$u_{1}$ 0 1 1 0

$u_{2}$ 0 0 1 1

$u_{3}$ 1 1 0 0

$u_{4}$ 1 0 0 1

Table 16
Increasing rule size

$| U |$ $| O |$ $| U_{C} |$ $| O_{C} |$ $| Π_{A} |$ $| R |$ $A v g R T_{ABAC}$ (in ms) $A v g R T_{RBAC}$ (in ms)

200 200 500 500 500 200 19.385 0.032

200 200 500 500 1000 200 35.227 0.032

200 200 500 500 2000 200 69.108 0.032

Table 24
$RUA$

Role $u c_{1}$ $u c_{2}$ $u c_{3}$ $u c_{4}$

$r_{1}$ 0 0 1 0

$r_{2}$ 0 1 1 0

$r_{3}$ 1 0 0 0

$r_{4}$ 1 0 0 1

6.2. ${ABAC}^{T C}$ and TRBAC