Abstract
In most access control scenarios, the communication between the PDP (policy decision point) and the PEP (policy enforcement point) can cause high authorization overhead. Authorization recycling enables PEP to use the previous access control decisions fetched from the PDP to handle some upcoming access control requests, reduce authorization costs, and increase the efficiency of access control decision-making. Inspired by the RBAC (role-based access control) authorization recycling mechanism, this article first presents an ABAC (attribute-based access control) model based on Boolean expressions of subject and object attributes. It then proposes an authorization recycling approach for this model. In this approach, we provide construction and update methods for authorization data caches and access control decision-making rules for SDP (secondary decision point) by using the caches. The proposed approach can deduce precise and approximate access control decisions from the cache of authorization data, reducing communication between the PEP and the PDP. Finally, the feasibility of the proposed method is verified by conducting a small-scale test. ABAC, SDP, authorization recycling, and authorization caching.
1. Introduction
Access control [1] is to restrict users of an application system from performing illegal operations or prevent their unauthorized access that can lead to security problems. The main access control types are DAC (discretionary access control) [2], MAC (mandatory access control) [3], and RBAC (role-based access control) [4]. However, compared to the DAC, MAC, and RBAC, the ABAC has the advantages of high flexibility, strong scalability, and fine granularity, making it widely used in distributed environments [5–9] because it overcomes the limitations of the traditional access control schemes.
As the scale of distributed applications has been expanding, the authorization mechanism based on the traditional single PDP (policy decision point) has become more fragile and challenging to extend to large-scale systems. The architecture of traditional access control solutions has certain shortcomings. Namely, the PDP can be a single point of failure, thus becoming a latent performance bottleneck, which affects the system’s reliability and availability. Moreover, the communication delay between the PDP and the PEP (Policy Enforcement Point) can cause high authorization overhead. To improve the above shortcomings, researchers adopted authorization recycling [10]. The authorization recycling mechanism makes full use of historical access control decision data to improve the efficiency of future access control decisions. It has long been used to improve the availability and performance of access control systems. Some simple authorization recycling methods have been proposed [11, 12], which are based on the request-response model, in which the PEP intercepts application requests and sends the request to the PDP. The PDP returns the decision results to the PEP according to the access control policy, and the PEP enforces these decisions.
In order to save storage space and enhance the usability and performance of a system, it is necessary to propose an approximate authorization recycling mechanism. Beznosov [13] extends the precise authorization recycling mechanism and introduces approximate authorization recycling. Crampton et al. [14] propose the SAAM (secondary approximate authorization model) for the BLP (Bell-LaPadula) model. The SDP (secondary decision point) is added to the authorization architecture [15], as depicted in Figure 1. The SDP is embedded with the PEP, which cannot only handle repeated authorization requests but also can solve approximate authorization requests through the calculation in the authorization cache. The SAAM infers precise and approximate responses using the relationship between subject and object inferred from the previous responses. In Figure 1, paths 1–8 illustrate the authorization workflow when the SDP cannot make a decision on the request and the request needs to be sent to the PDP; paths (1)–(6) illustrate the case where the SDP can make a decision on the request.
Wei et al. [15] introduce the authorization recycling method in a hierarchical RBAC system, which can not only compress authorization data in the cache but also effectively infer approximate decisions from the cached data. Reeja [16] proposes an authorization recycling method using the CSAR (cooperative secondary authorization recycling) in the cloud computing system, which utilizes the cooperative cache of access control decisions to improve the hit rate. Wei et al. [17] propose a publish-subscribe system in which authorization requests and responses are passed between applications and authorization servers, which can enhance the availability of the authorization system.
Inspired by the literature [15], we present an authorization recycling approach in the ABAC system. However, the two models are quite different. In RBAC, roles are associated with permissions, which can be regarded as ABAC single attribute; RBAC only considers positive authorization; in ABAC, we consider the combination of multiple attributes associated with permissions, so the processing of cache construction and update is also different, which makes authorization recycling more complicated but worthwhile. Furthermore, the ABAC [18, 19] neither follows the closed world policy nor the open world policy. Therefore, this article mainly introduces the ABAC authorization recycling approach under the closed-world, open-world, and hybrid policy [20]. Firstly, we build a general-purpose ABAC model which supports positive and negative but also hybrid authorizations. CP-ABE [21, 22] (ciphertext-policy attribute-based encryption) is one of the prominent attribute-based cryptographic access control approaches for “read” permissions on data objects in a cloud environment. Its access policy is a Boolean expression of attributes and has the essential characteristics of the ABAC model. Therefore, we first construct the ABAC model based on Boolean expressions of subject and object attributes. Secondly, provide methods for building and updating the authorization data caches and specify SDP’s access control decision rules. Finally, the feasibility of the authorization recycling approach is verified by conducting a small-scale experiment.
The rest of the paper is organized as follows. Section 2 introduces the ABAC model and assumptions of authorization recycling. Section 3 describes the ABAC authorization recycling approach in detail. Section 4 presents the test results of the proposed recycling approach. A discussion of related works and comparisons is provided in Section 5. Finally, the main conclusions and directions for future work are given in Section 6.
2. ABAC Model
2.1. ABAC Model
The ABAC uses attributes to describe the subject, object, and environment and uses these attributes to formulate access control policies [23–25] to evaluate whether the subject is allowed to perform specific actions on the object.
The ABAC model considered in this paper basically follows the specifications in [26], and its essential components are as follows: (1)Attribute: attributes represent characteristics of the subject and object; attributes have names and values(2)Subject: a user or entity, such as a device, that makes an access request and performs operations on an object; the subject can have one or more attributes(3)Object: system resources accessed by the subject; the object can have one or more attributes(4)Operation: operation represents the subject’s actions on the object, including read, write, edit, delete, and other actions(5)Permission: permission is composed of an object and an operation (action) on the object(6)Policy: a policy consists of access control rules about a subject and an object that determine whether to allow the subject’s access request to an object based on the attributes of the subject and the object
The rule is the basic unit of an ABAC policy [27]. We first discuss the rule. is used to represent a rule, and and are used to describe rules related to subject and object, respectively. The precise recursive definitions of rules related to subject and object are given in the following.
Definition 1. The subject-related rule (subject-rule) can be recursively defined as follows: (1)Any subject attribute is a subject rule, and it is called an atomic subject rule(2)If are subject rules, then their conjunction is also a subject rule(3)If are subject rules, then their disjunction is also a subject rule(4)An expression obtained by (1)–(3) a finite number of times is a subject rule
Definition 2. The object-related rule (object-rule) can be recursively defined as follows: (1)Any object attribute is an object rule, and it is called an atomic object rule(2)If are object rules, then their conjunction is also an object rule(3)If are object rules, then their disjunction is also an object rule(4)An expression obtained by (1)–(3) a finite number of times is an object rule
If an attribute of a subject (object) in an access request matches the atomic subject (object) rule, then we say the subject (object) attribute satisfies the atomic subject (object) rule.
In this work, the subject and object in the ABAC are modeled as a set of attributes, respectively. Environmental attributes have the same status as subject and object attributes. For simplicity, environmental attributes are not considered in this article.
As we know, an attribute usually refers to a tuple . In most CP-ABE schemes, an attribute name and a value are combined and represented as an attribute. We follow the characteristics of the CP-ABE access policy to define our ABAC policy. We also try to improve the expressivity of access control policy in our ABAC model. Here, we enumerate attributes that can be supported in our ABAC and discuss how to define rules about these attributes. (1)Nominal attribute: it appears in the form of an attribute name and an attribute value in the rule. For example, . If a subject attribute is included in a request, then we say satisfies since both the attribute name and attribute value match the attribute name and attribute values in (2)Binary attributes: they appear in the form of an attribute name and an attribute value in the rule. For example, (1 denotes male, 0 denotes female). If a subject attribute is included in a request, then we say satisfies since both the attribute name and attribute value matches the attribute name and attribute values in (3)Orderial attributes: there is a full order relation among all values of an orderial attribute. For example, an attribute level has five different values: excellent, good, average, fair, poor, and . We can express a raw subject-related rule as in our ABAC rule, where , . If a subject attribute is included in a request, then we say atisfies since both the attribute name and attribute value match the attribute name and attribute values in (4)Numeric attributes: it only supports discrete, finite attribute values. For example, an attribute score has five different values: 1, 2, 3, 4, and 5. We can express a raw object-related rule as in our ABAC rule, where , , . If an object attribute is included in a request, then we say object attribute satisfies since both the attribute name and attribute value match the attribute name and attribute values in
According to the explanation above, we will directly discuss attributes. We will not discuss attribute name and value separately and also will not discuss other kinds of mathematical operations such as , , , and .
The formal specification of the ABAC model is as follows: (1) represent the subjects (the subject is usually assumed to be a user), objects, operations, subject attributes, object attributes, and permissions, respectively(2) where . Permissions represent the authorized behavior of a subject; the object is expressed by a boolean combination of object attributes in object rules
Closed-world policy, open-world policy, and a combination of both, hybrid policy, are meta-policies used in most access control scenarios. Unfortunately, the hybrid policy can lead to the absence of a satisfactory policy or the occurrence of policy conflicts against an access request [28]. Satisfiable policy absence indicates that the user access request meets no authorization policy. Policy conflict means the user access request meets both positive and negative authorization policies. To enhance system security, if there is a policy conflict, the denial-take-precedence [29] is adopted. If there occurs satisfiable policy absence, the denial-for-absence is used. In practice, different systems can define their own meta-policies for satisfiable policy absence and policy conflicts.
Based on the definitions mentioned above, we define three variants of the ABAC model, ABAC (P), ABAC (N), and ABAC (H), that follow the closed-world policy, the open-world policy, and the combination of these two policies, respectively.
In this article, it is assumed that there exists at least one policy for each permission. An access control policy for permission is defined as a triple , where denotes the subject rule and denotes the object rule, , effect ∈ {permit, deny}. We use to represent the request, where , , and represent the subject attribute set, object attribute set, and permission to access, respectively. The supplementary definitions for the three variants are given in the following.
Definition 3 (ABAC(P)) model. For a positive authorization policy for permission is defined as a triple and an access request, only if the subject and object attribute sets in the access request satisfy , the final access control decision for permission will be permit; otherwise, it will be deny.
Definition 4 (ABAC(N)) model. For a negative authorization policy for permission is defined as a triple and an access request , only if the subject and object attribute sets in the access request satisfy ,the final access control decision for permission will be deny; otherwise, it will be permit.
Definition 5 (ABAC(H)) model. For an authorization policy for permission is defined as a triple , where and a request , only if both the subject and object attribute sets in the access request satisfy , the request meets the access control policy. The final access control decision for permission is specified as follows: (1)If there are only one positive authorization policy about permission , then this case is regarded as ABAC (P); if the request meets the policy, then the decision result will be permit; otherwise, it will be deny(2)If there exists only one negative authorization policy about permission , then this case is regarded as ABAC (N); if the request meets the policy, then the decision result will be deny; otherwise, it will be permit(3)If there exist both positive and negative authorization policies about permission , then (a)If the request meets only the positive authorization policy, then the decision result will be permit(b)If the request meets only the negative authorization policy, then the decision result will be deny(c)If the request meets both polices, then the denial-take-precedence will be adopted, and the decision result will be deny(d)If the request meets none of the policies, then the denial-for-absence will be adopted, and the decision result will be deny
2.2. Authorization Recycling Assumptions
Before the authorization recycling approach for the ABAC model is presented, the assumptions of the ABAC system should be given, and they are as follows: (1)Only the PDP can reach the whole access control policy, while the SDP cannot(2)The SDP generates precise, approximate responses based on the cached decision data and request
Definition 6 (Precise and approximate decision). For an authorization request, the authorization decision is precise if PDP makes the decision or the SDP makes it, and there exists the exact same previous request with a decision by PDP. Otherwise, we say the decision is approximate.
The SDP is considered safe if it permits any request that the PDP permits. Furthermore, the SDP is considered consistent if it denies any request that the PDP denies [14]. Typically, a safe and consistent SDP that will return the same response as the PDP for any request is expected. This article aims to construct a safe and consistent SDP.
Next, the definition of minimal subject and object attribute sets is given as follows to help us construct the cache.
Definition 7 (Minimal subject attribute set). Attribute set is a minimal subject attribute set of a subject-related rule , if it satisfies the following requirements [30]: (1)Attribute set satisfies (2)For all , attribute set does not satisfy
Example 1. Suppose . Minimal subject attribute sets of are and . Attribute sets and satisfy subject-related rule ; for all , and , attribute sets and do not satisfy the subject-related rule .
Definition 8 (Minimal object attribute set). Attribute set is a minimal object attribute set of an object-related rule , if it satisfies the following requirements: (1)Attribute set satisfies (2)For all , attribute set does not satisfy
3. Authorization Recycling for ABAC Model
3.1. Preliminaries
It is reasonable to assume that there is at least one policy for each permission, either a positive authorization policy, a negative authorization policy, or both. If there are multiple positive (or negative) authorization policies, then they can be merged into one positive (negative) authorization policy using a Boolean expression, while different types of authorization policies, i.e., positive and negative, cannot be merged.
Suppose a subject has an access request , where , and represent the subject attribute set, object attribute set, and permission to access, respectively. We use to represent the positive authorization policy, to represent a set of minimal subject attribute sets of ; represents a set of minimal object attribute sets of . Similarly, represents the negative authorization policy, represents a set of minimal subject attribute sets of ; represents a set of minimal object attribute sets of
This section considers different types of caches relying on the responses fetched from the PDP and the existing policies. (1)There exists only one positive authorization policy for permission : (a)If a request satisfies the positive authorization policy for at the PDP side, then the PDP permits the request and returns some attribute sets and together with the permit response to the SDP, where The corresponding permit response is denoted as .(b)If a request does not satisfy the positive authorization policy for at the PDP side, then the PDP denies the request, and return attribute sets and together with the deny response to the SDP, the corresponding deny response is denoted as .(2)There exists only one negative authorization policy for permission : (a)If a request satisfies the negative authorization policy for at the PDP side, then then the PDP denies the request and returns some attribute sets and together with the deny response to the SDP, where The corresponding deny response is denoted as .(b)If a request does not satisfy the negative authorization policy for at the PDP side, then the PDP permits the request, and return attribute sets and together with the permit response to the SDP, the corresponding permit response is denoted as .(3)There exist both positive and negative authorization policies for permission : (a)If a request satisfies both the positive and negative authorization policies, then the PDP denies the request because the denial-take-precedence is adopted, or if the request satisfies only the negative authorization policy, then the PDP denies the request, and the PDP returns all attribute sets and together with the deny response to the SDP, where The corresponding deny response is denoted as . This case is slightly different from the other cases above. The PDP returns all the minimal sets that meet the negative authorization policy to the SDP while returning the deny response.(b)If a request satisfies only the positive authorization policy but not the negative one, then the PDP permits the request and returns some attribute sets and together with the permit response to the SDP, where The corresponding permit response is denoted as .(c)If a request does not satisfy both the positive and negative authorization policies, then the PDP denies the request because the denial-for-absence is adopted, and returns attribute sets and together with the deny response to the SDP, the corresponding deny response is denoted as .
The response content is specified as where where where where where where
It is assumed that the PDP sends attribute sets included in response to the SDP, which may threaten the privacy of the policy. Therefore, these contents can be encrypted, and the PDP sends the ciphertext to the SDP. However, since our emphasis is on authorization recycling, we did not consider policy privacy in our work.
3.2. Cache Building
Seven relations below are used for cache construction:
The basic idea is that under the condition that there is only a positive authorization policy for permission , the permit response is used to build , and the deny response is used to build
Similarly, under the condition that there is only a negative authorization policy for permission , the deny response is used to build , and the permit response is used to build
Lastly, under the condition that there exist both positive and negative authorization policies for permission , the deny response is used to build , the permit response is used to build , and the deny response caused by satisfiable policy absence is used to build
Caches , , , , , , and are all initialized as empty. When a subject sends access request to the PDP, the PDP returns the access control decision to the SDP, relying on the access control policies that are associated with permission
Next, we mainly discuss the construction process of the cache when the PDP traverses the policy repository. For a certain permission in the policy repository, there is either only one positive authorization policy, or only one negative authorization policy, or there are two policies, one positive authorization policy and one negative authorization policy. Here are different cases: (1)There exists only one positive authorization policy for permission . According to Algorithm 1 in Appendix, if the PDP permits the request, then it adds to ; otherwise, the PDP denies the request, and the construction of is as follows (a)If attributes of both the subject and object in the request do not meet rules , , then is directly added to , where , and (b)If, in the request, the subject’s attributes do not meet , but the object’s attributes meet , then is added to , where (c)If, in the request, the subject’s attributes meet , but the object’s attributes do not meet , then is added to , where (2)There exists only one negative authorization policy for permission . Reference Algorithm 1 , if the PDP denies the request, then it adds to ; otherwise, the PDP permits the request, and the construction of is as follows: (a)If attributes of both the subject and object in the request do not meet rules , and , then is directly added to , where , and (b)If, in the request, the subject’s attributes do not meet but the object’s attributes meet , then is added to , where (c)If, in the request, the subject’s attributes meet but the object’s attributes do not meet , then is added to , where (3)Both positive and negative authorization policies coexist. Denote two policies as and , where , . According to Algorithm 3 in Appendix, the cache is built as follows: (a)If the PDP denies the request and the SDP receives the deny response , then it adds to . If only the minimal sets included by the current request are returned, the SDP may produce a permit response based on the content of the cache for subsequent requests. However, the request may consist of minimal sets of the negative authorization policy, which do not appear in the cache. The request should be denied according to the requirement for the SDP to be consistent with PDP. The PDP returns all minimal attribute sets that meet the negative authorization policy to avoid producing such an incorrect response(b)If the PDP permits the request and the SDP receives the permit response , then it adds to (c)If the PDP denies the request and the SDP receives a deny response together with the information on the satisfiable policy absence. Then the building process of can be divided into three following cases: (i)If attributes of both the subject and object in the request do not meet rules , , , and , then is directly added to , where , and (ii)If, in the request, the subject’s attributes do not meet and , but the object’s attributes meet and/or , then is added to , where (iii)If, in the request, the subject’s attributes meet and/or , but the object’s attributes do not meet and , then is added to , where
Note: if, in the request, the subject’s attributes meet and the object’s attributes meet or if the subject’s attributes meet and the object’s attributes meet , then nothing needs to be added to
3.3. SDP Decision Rules
This subsection gives the SDP decision rules, which are used to infer accurate or approximate access control decisions from a cache.
Case 1. If there is only one positive authorization policy for permission , the and can be built. According to Algorithm 2 in Appendix, the following two rules are used to infer accurate or approximate access control decisions.
Assume , then request will be permitted by the SDP, if and .
Theorem 9. When a user sends a request, the SDP’s decision to permit the request according to is safe.
Proof. Assuming that SDP makes a permit decision for the request by . According to , such that , where , and , .
Based on cache construction, and satisfy rules and of , respectively; additionally, we also have , . So, the PDP should permit the request . That is, the request permitted by SDP according to the would also be permitted by the PDP.
Assume then the request will be denied by the SDP, if or .
Theorem 10. When a user sends a request, the SDP’s decision to deny the request according to is consistent.
Proof. Assuming that SDP makes a deny decision for request by . According to , , where , or , .
Based on cache construction, and do not satisfy rules and of , respectively; additionally, we also have , . So, the PDP should deny the request . That is, the request denied by SDP according to the the PDP would also deny.
Case 2. If there is only one negative authorization policy for permission , the and can be built. Reference Algorithm 2, the following two rules are used to infer accurate or approximate access control decisions.
Assume , then request will be denied by the SDP, if and .
Theorem 11. When a user sends a request, the SDP’s decision to deny the request according to is consistent.
Proof. Assuming that SDP makes a deny decision for the request by . According to , such that , where , and , .
Based on cache construction, and satisfy rules and of , respectively; additionally, we also have , . So, the PDP should deny the request . That is, the request denied by SDP according to the the PDP would also deny.
Assume then request will be permitted by the SDP, if or .
Theorem 12. When a user sends a request, the SDP’s decision to permit the request according to is safe.
Proof. Assuming that SDP makes a permit decision for request by . According to , , where , or , .
Based on cache construction, and do not satisfy rules and of , respectively; additionally, we also have , . So, the PDP should permit the request . That is, the request permitted by SDP according to the would also be permitted by the PDP.
Case 3. If both positive and negative authorization policies coexist for permission , the , , and can be built. According to Algorithm 4 in Appendix, the following three rules are used to infer accurate or approximate access control decisions.
Assume , then request will be denied by the SDP, if and .
Theorem 13. When a user sends a request, the SDP’s decision to deny the request according to is consistent.
Proof. Assuming that SDP makes a deny decision for the request by . According to , such that , where , and , .
Based on cache construction, and satisfy rules and of , respectively; additionally, we also have , . So the PDP should deny the request . That is, the request denied by SDP according to the the PDP would also deny.
Assume , then request will be permitted by the SDP, if and .
Theorem 14. When a user sends a request, the SDP’s decision to permit the request according to is safe.
Proof. Assuming that SDP makes a permit decision for the request by . According to , such that where , and , .
Based on cache construction, and satisfy rules and of , respectively; Additionally, we also have , . So the PDP should permit the request . That is, the request permitted by SDP according to the would also be permitted by the PDP.
Assume , then request will be denied by the SDP, if or .
Theorem 15. When a user sends a request, the SDP’s decision to deny the request according to is consistent.
Proof. Assuming that SDP makes a deny decision for request by . According to , where , or , and .
Based on cache construction, and do not satisfy rules and of , respectively; or and do not satisfy rules and of , respectively; additionally, we also have , . So, the PDP should deny the request . That is, the request denied by SDP according to the the PDP would also deny.
The symbol is used to indicate the inference rule reference priority, if there is only one positive authorization policy for permission , and the priority of the following two rules is . If there is only one negative authorization policy for permission , the priority of the following two rules is . If both positive and negative authorization policies coexist for permission , the priority of the following three rules is . Once a rule is applied to a request, the SDP stops evaluating the request against lower priority rules.
3.4. Cache Update
When the SDP cannot make a decision on the request, the request needs to be sent to the PDP, and then the cache may be updated.
Under the condition, both positive and negative authorization policies coexist, once the SDP receives the deny response , and then, all minimal sets are added to , so does not need to be updated.
The update of and are as follows: (1)If a request satisfies only the positive authorization policy but not the negative one, the PDP permits the request, and the SDP receives the permit response . The update of is divided into the following cases:
Case 1. If the record of w.r.t. permission is empty, then the corresponding record is added to according to the building process of that is given in Section 3.2.
Case 2. If , then is updated by replacing with , where , , and O(2)If both positive and negative authorization policies are not satisfied, then the PDP denies the request, and the SDP receives a deny response with the information on the satisfiable policy absence. Then, the updating process of is divided into the following cases:
Case 1. If attributes of both subject and object do not meet rules , the is updated as follows: (1)If the record of w.r.t. permission is empty, then the corresponding record is added to according to the building process of that is given in Section 3.2(2)If , then is updated as follows: (a)If and , then is updated by replacing with , where , and (b)If and , then is updated by replacing with , where , and (c)If and , then is updated by replacing with , where , and (d)If and , then is updated by replacing with , where , and
Case 2. If the subject’s attributes do not meet and , but the object’s attributes meet and/or , then and are updated as follows: (1)Update : (a)If the record of w.r.t. permission is empty, then the corresponding record is added to according to the building process of that is given in Section 3.2(b)If , then is updated as follows: (i)If , then is updated by replacing with , where (ii)If , then is updated by replacing with , where (2)Update : (a)If the record of w.r.t. permission is empty, then is added to , where , and (b)If , then is updated by replacing with , where
Case 3. If the subject’s attributes meet and/or , but the object’s attributes do not meet and , then and are updated as follows: (1)Update : (a)If the record of w.r.t. permission is empty, then the corresponding record is added to according to the building process of that is given in Section 3.2(b)If , then is updated as follows: (i)If , then is updated by replacing with , where (ii)If , then is updated by replacing with , where (2)Update : (a)If the record of w.r.t. permission is empty, then is added to , where , and (b)If , then is updated by replacing with , where
Case 4. If the subject’s attributes meet and the object’s attributes meet ; or if the subject’s attributes meet and the object’s attributes meet , then does not need to be updated. The update of is as follows: (1)If the subject’s attributes meet , then the update of refer to (2) in Case 3(2)If the object’s attributes meet , then the update of refer to (2) in Case 2
If there exists only one positive authorization policy for permission , the update of refer to ; the update of refer to
If there exists only one negative authorization policy for permission , the update of refer to ; the update of refer to
Above, we provide the authorization recycling method under the hybrid policy, including how to construct the cache, define reasonable decision rules, and update the cache.
The environment attributes can be added to the presented ABAC model. Consequently, the access request will be changed to , and the access control policy will be , where represents the environment rule. Only if the subject, object, and environment attribute sets in the access request satisfy the rule , the request satisfies the access control policy. We can similarly provide an authorization recycling method. This article does not put the environment attribute into the model for brevity.
4. Experimental Results and Evaluation
4.1. Comparison with Different Approaches
Table 1 compares the proposed work with some existing work in terms of flexibility of policy expression, access granularity, authorization recycling, and application scenarios. Compared to [15], our approach is for ABAC and supports negative authorization; ours is more flexible, has higher policy expression ability, and supports fine-grained access control. Compared to [5, 9], our emphasis is on providing authorization recycling method, including building and updating the cache and making precise or approximate decisions. Our solution is based on the general-purpose ABAC model and is not directed to specific applications.
4.2. Test Results
A small-scale experiment was conducted to evaluate the hit rate of the authorization recycling approach for the ABAC model under the hybrid policy. This approach was carried out on a PC with an Intel (R) Core (TM) i7-8750h CPU at 2.20 GHz-2.21 GHz, 8GB memory, and Windows 10 x64. The application software was JetBrains PyCharm Community Edition 2019.3, and the interpreter was Python 3.7.
The experimental procedure was as follows. First, 50 subject attributes, 50 object attributes, and 10000 different permissions were randomly generated. For one-third of permissions, there was only one positive authorization policy for each permission; for another one-third of permissions, there was only one negative authorization policy for each permission; and lastly, for the remaining permissions, there were both positive and negative authorization policies for each permission. Each policy had a rule , where represented a Boolean expression of subject attributes. Attributes in the expression were randomly selected from 50 subject attributes in a random amount. Further, was a Boolean expression of object attributes, and the attribute in the expression was randomly selected from 50 object attributes in a random amount. Next, we randomly generated a request set containing 10000 access requests, and represented a request, where denoted the subject attribute set, whose attributes were randomly selected from 50 subject attributes in a random amount, and represented the object attribute set, whose attributes were randomly selected from 50 object attributes in a random amount, and lastly, represented the permission to access. The average number of both subject attributes and object attributes in each policy is about 13, and the average number of both subject attributes and object attributes in each access request is about 25.
The method proposed in this article was more suitable for those situations where the same user or similar users in the same organization have more concentrated permission access over a certain period. So we randomly accessed 200, 500, 800, 1000, 2000, and 3000 out of 10000 permissions. When a subject sent an access request for permission, the PDP searched for the policy associated with that permission. Then, it calculated the minimal subject and object attribute sets according to Definitions 7 and 8, respectively. The obtained test results are shown in Figure 2.
(a) Random access to 200 permissions, the number of various responses
(b) Random access to 500 permissions, the number of various responses
(c) Random access to 800 permissions, the number of various responses
(d) Random access to 1000 permissions, the number of various responses
(e) Random access to 2000 permissions, the number of various responses
(f) Random access to 3000 permissions, the number of various responses
The cache was initially empty, and the SDP used the information fetched from the PDP to gradually build and update the cache. As the number of requests increased, the SDP achieved more information from the PDP, and the cache records continued to increase. From Figure 2, it can be seen that the number of approximate responses increased with the number of requests and was much larger than the number of precise responses. In the case of the same number of requests sent, the more permission for random access, the fewer the requests resolved locally by the SDP. In the case of certain access permissions, the more the number of requests, the more the requests are resolved locally by the SDP, and the hit rate gradually increases, as shown in Figure 3.
(a) Random access to 200 permissions, the hit rate variation with the number of requests
(b) Random access to 500 permissions, the hit rate variation with the number of requests
(c) Random access to 800 permissions, the hit rate variation with the number of requests
(d) Random access to 1000 permissions, the hit rate variation with the number of requests
(e) Random access to 2000 permissions, the hit rate variation with the number of requests
(f) Random access to 3000 permissions, the hit rate variation with the number of requests
In addition, we also tested the decision time in two conditions: on-cache and off-cache. Under the off-cache condition, users’ requests are directly decided by the PDP and sent to the PEP for enforcement. In the on-cache condition, the PDP decides on the users’ requests first, the matching policy contents or requests are cached in the corresponding caches by the SDP, and then later requests are solved by the SDP according to SDP decision rules. In the on-cache test, we randomly accessed 100 permissions from 10,000 permissions, sent 1,000 requests for these permissions, and recorded the decision time. Then, we used the exact requests and their related policies and did the same test with off-cache. We conducted the same test for five rounds, and the decision time was recorded and averaged. The average response time for each round is listed in Table 2.
The average decision time in the on-cache condition is 119.743 ms less than that in the off-cache condition. Moreover, if the network communication time is considered, the average decision time with on-cache will be shorter than that with off-cache.
Making access control decisions with the cache is more advantageous than without the cache. In addition, if the PDP cannot be reached, the SDP can handle some requests using the cache to cover up the failure of the PDP. The proposed system can overcome the shortcomings of the PDP to some extent and reduce the workload of the PDP.
5. Related Work
The ABAC has been widely used in distributed environments in recent years due to its flexibility, scalability, and fine-granularity access control. Li et al. [31] described the overall framework of the ABAC. Hu et al. [26] provided a comprehensive definition and guidance for implementing the ABAC, becoming the NIST ABAC standard. In this work, an ABAC model, which supports hybrid authorizations, is proposed. The proposed model relies on Boolean expressions of subject and object attributes, capturing common characteristics of the ABAC practices.
In access control, caching authorization responses [11, 12] and reuse of them can increase the usability and performance of the access control system, so authorization recycling has attracted much attention recently. Beznosov [13] presented approximate authorization recycling and proposed to use the publish-subscribe architecture to share and actively recycle authorization. However, this approach uses many precomputed authorizations in the delivery channel and actively recycles authorizations on an immediate basis; it also extends the precise caching mechanism. In [17], a publish-subscribe model was proposed to transfer access requests and responses between the application and authorization server. This work presents an accurate and approximate authorization recycling method for the ABAC.
Crampton et al. [14] proposed an authorization recycling model-SAAM based on the BLP model, which uses the relationship between the subject and object of the previous responses to deduce approximate responses. This model formally defines SAAM and introduces the SDP. Namely, SAAM provides an alternative source for access control decisions. It builds a general-purpose, application-independent authorization recycling framework to achieve a new authorization response from the SDP. It reuses the previous response to infer information about the underlying access control policy and makes an approximate response consistent with the policy. Compared to the approach presented in [14], our authorization recycling approach is for the ABAC model, in which permission access is based on rules about subject and object attributes. It should be noted that handling access requests in the ABAC model is much more complicated than in the BLP model. Consequently, authorization recycling in the ABAC is more complex than that of the BLP model. Additionally, our authorization recycling supports the hybrid policy, while the BLP model supports only the closed-world policy.
In [16, 32], collaborative secondary authorization recycling was studied. In [16], an authorization recycling method using CSAR in the cloud computing system, which uses cooperative caching of access control decisions to improve the hit rate, was developed. Wei et al. [32] discussed the collaboration between multiple SDPs and proposed a collaborative secondary authorization recovery method. This method takes advantage of a large-scale, distributed cooperative system to improve the hit rate of access control decisions. Application servers share their recycled authorization results with each other. Compared to analyses in [16, 32], in this work, the cooperation between SDPs is not considered. However, this work focuses on making full use of all information fetched from the PDP when making secondary authorization decisions to increase the hit rate. Additionally, authorization recycling for a relatively complex ABAC model is presented.
The RABC authorization recycling was studied in [15]. Crampton et al. [15] proposed the caching strategy SAAMRBAC. They provided an authorization recycling algorithm, which includes the compression of an authorization cache. The SDP can effectively infer precise and approximate decisions from the cached data to overcome the shortcomings of the PDP. In contrast to the RBAC, the ABAC has the advantages of high flexibility, scalability, and fine granularity. Inspired by the results in [15], a general-purpose ABAC model, which supports hybrid authorizations, is developed in this work. However, in the RBAC, roles associated with permissions and only positive authorization is considered. In the ABAC, a combination of several attributes associated with a permission is considered, which makes authorization recycling more complex but worthy.
6. Conclusion
This paper presents a general-purpose ABAC model that supports the hybrid policy. It also introduces the authorization recycling approach for this model, specifies reasonable rules to construct the cache, and effectively renders precise and approximate decisions from the cache. In the presented model, the Boolean expressions of subject and object attributes are used, so an application system can extend this model, adding other attributes, such as environmental attributes. In the cache construction process, two principles are adopted: (1) full use of information fetched from the PDP in making authorization decisions at the SDP; and (2) do not use the PDP if there is any chance to make a safe and consistent authorization decision at the SDP, since fetching a new response increases communication cost and searching overhead. Finally, a small-scale experiment is conducted to evaluate the effectiveness of the proposed approach.
It should be noted that the ABAC models and their workflows can be much more complicated in practice, and authorization policies may change all the time in some ABAC systems. This work does not consider the impact of policy changes on the cache. The ABAC cache supporting dynamic policy change will be studied in our future work. The applicability of the proposed approach in practical environments will also be considered in the future.
Appendix
Cache Construction and Access Control Decision Algorithm
If there exists only one positive authorization policy for permission . The possible contents of the response are as listed in Table 3.
The corresponding cache construction (build and update) algorithm is as follows.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The corresponding access control decision algorithm by the SDP is as follows.
| ||||||||||||||||||||||||||||||||
In the case of only one negative authorization policy for permission , the model becomes a dual model of that there is only one positive authorization policy for permission , cache construction, and access control decision algorithm are similar and will not be repeated here.
If both positive and negative authorization policies coexist for permission , the possible contents of the response are listed in Table 4.
The corresponding cache construction (build and update) algorithm is as follows.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The corresponding access control decision algorithm by the SDP is as follows.
| ||||||||||||||||||||||||||||||||||||||||||||
Data Availability
The data used to support the findings of this study are included within the article.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This research work was supported by the National Natural Science Foundation of China (grant numbers: 61862059, 61562085).