Greedy and evolutionary algorithms for mining relationship-based access control policies

Abstract

Relationship-based access control (ReBAC) provides a high level of expressiveness and flexibility that promotes security and information sharing. We formulate ReBAC as an object-oriented extension of attribute-based access control (ABAC) in which relationships are expressed using fields that refer to other objects, and path expressions are used to follow chains of relationships between objects.ReBAC policy mining algorithms have potential to significantly reduce the cost of migration from legacy access control systems to ReBAC, by partially automating the development of a ReBAC policy from an existing access control policy and attribute data. This paper presents two algorithms for mining ReBAC policies from access control lists (ACLs) and attribute data represented as an object model: a greedy algorithm guided by heuristics, and a grammar-based evolutionary algorithm. An evaluation of the algorithms on four sample policies and two large case studies demonstrates their effectiveness.An access control list (ACL) policy is a tuple CM , OM , Act, SP 0 , where CM is a class model, OM is an object model, Act is a set of actions, and SP 0 ⊆ OM × OM × Act is a subject-permission relation. Conceptually, SP 0 is the union of the resources' access control lists.An ReBAC policy π is consistent with an ACL policy CM , OM , Act, SP 0 if they have the same class model, object model, and actions and [[π]] = SP 0 .An ReBAC policy consistent with a given ACL policy can be trivially constructed, by creating a separate

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 rule is a tuple subjectType, subjectCondition, resourceType, resourceCondition, constraint, actions , where subjectType and resourceType are class names, subjectCondition and resourceCondition are conditions, constraint is a constraint, actions is a set of actions. A rule must satisfy several well-formedness requirements [BSL19b]. For a rule ρ = st, sc, rt, rc, c, A , let sType(ρ) = st, sCond(ρ) = sc, rType(ρ) = rt, rCond(ρ) = rc, con(ρ) = c, and acts(ρ) = A.…”

“…Policy mining algorithms have the potential to greatly reduce this cost, by automatically producing a high-level policy from existing lower-level data; vetting and tweaking it is significantly less work than creating a high-level policy from scratch. There is a substantial amount of research on role mining, surveyed in [ ReBAC policy mining was first studied by Bui et al [BSL17,BSL19b]. They define the problem as follows: Given information about the attributes of all entities in the system, and the set of currently granted permissions; Find a ReBAC policy that grants the same permissions using concise, high-level rules.…”

“…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].…”

“…Unlike ORAL and Iyer et al's language, the other ReBAC policy languages cited above cannot express constraints that relate the attributes of different entities. Such constraints appear in a majority of the rules in the case studies used in [BSL19b].…”