Efficient and Extensible Policy Mining for Relationship-Based Access Control

Abstract

Relationship-based access control (ReBAC) is a flexible and expressive framework that allows policies to be expressed in terms of chains of relationship between entities as well as attributes of entities. ReBAC policy mining algorithms have a potential to significantly reduce the cost of migration from legacy access control systems to ReBAC, by partially automating the development of a ReBAC policy. Existing ReBAC policy mining algorithms support a policy language with a limited set of operators; this limits their applicability.This paper presents a ReBAC policy mining algorithm designed to be both (1) easily extensible (to support additional policy language features) and (2) scalable. The algorithm is based on Bui et al.'s evolutionary algorithm for ReBAC policy mining algorithm. First, we simplify their algorithm, in order to make it easier to extend and provide a methodology that extends it to handle new policy language features. However, extending the policy language increases the search space of candidate policies explored by the evolutionary algorithm, thus causes longer running time and/or worse results. To address the problem, we enhance the algorithm with a feature selection phase. The enhancement utilizes a neural network to identify useful features. We use the result of feature selection to reduce the evolutionary algorithm's search space. The new algorithm is easy to extend and, as shown by our experiments, is more efficient and produces better policies. KEYWORDS security policy mining; attribute-based access control; relationshipbased access control; feature selection ACM Reference Format:

Mining Relationship-Based Access Control Policies

“…Our policy language, which we call ORAL20, is Bui et al's ORAL19 (our name for it) [BSL19a], extended to allow negative conditions and constraints. We give a brief overview of the language, and refer the reader to [BSL19a] for details of ORAL19 and to [BSL19b] for details of the original version of ORAL, which ORAL19 extends. This overview is largely the same as in [BSL19a].…”

“…A reference type is any class name (used as a type). Like [BSL19a], we leave inheritance as a topic for future work.…”

“…We chose ORAL as the basis for our policy language to facilitate comparison with existing work. ORAL [BSL17,BSL18,BSL19b,BSL19a] or a similar language [IM19] is used in all of the published work on ReBAC policy mining. The similarity of Iyer et al's policy language to ORAL is reflected in the fact that the policies used in their experiments are translations of parts of the ORAL policies used in [BSL19b].…”

“…First, a policy language without negation is sometimes preferred to reduce the chance of writing rules that grant excess permissions when new entities are added; for example, the condition subject.department ∈ {CS, EE} is safe even if new departments may be created, but the condition subject.department = CS may lead to undesired granting of permissions to members of new departments. Second, this allows direct experimental comparison of our algorithm with FS-SEA*, the state-of-the-art ReBAC policy mining algorithm in [BSL19a], the most recent and best of Bui et al's ReBAC policy mining algorithms. FS-SEA* is a complicated multi-phase algorithm that combines heuristics, neural networks, and a grammar-based genetic algorithm.…”

“…To demonstrate the benefits of our approach, we conducted an experimental comparison with FS-SEA* [BSL19a]. The datasets used in our experiments include four sample policies, two large case studies based on policies of real organizations [DBLJ14a,DBLJ14c], and the five synthetic policies used in [BSL19a]. Compared to FS-SEA*, DTRM is simpler, significantly faster, achieves similar policy quality, and can mine policies in a richer language (with negative conditions and constraints).…”