Constraint-Enhanced Role Engineering via Answer Set Programming Jinwei Hu 1 Khaled M. Khan 1 Yun Bai 2 Yan Zhang 2 1 Department of Computer Science and Engineering, Qatar Univeristy, Doha 2713, Qatar 2 School of Computing and Mathematics, University of Western Sydney, Sydney 1797, Australia {jinwei, k.khan}@qu.edu.qa {ybai, yan}@scm.uws.edu.au ABSTRACT Role engineering (RE) aims to develop and maintain appropriate role-based access control (RBAC) configurations. However, RE with constraints in place is not well-studied. Constraints usually describe organizations’ security and business requirements. An in- consistency between configurations and constraints compromises security and availability, as it may authorize otherwise forbidden access and deprive users of due privileges. In this paper, we apply answer set programming (ASP) to discover RBAC configurations that comply with constraints and meet various optimization objec- tives. We first formulate the need of supporting constraints as a problem independent of and complementary to existing RE prob- lems. We then present a flexible framework for translating the pro- posed problem to ASP programs. In this way, the problem can be addressed via ASP solvers. Finally, we demonstrate the effective- ness and efficiency of our approach through experimental results. Categories and Subject Descriptors D.4.6 [Operating Systems]: Security and Protection—Access con- trols; K.6.5 [Management of Computing and Information Sys- tems]: Security and Protection General Terms Security, Management Keywords RBAC, Constraint, Role Engineering, Answer Set Programming 1. INTRODUCTION It proves challenging to build a secure and manageable access control system. By introducing “roles” as an intermediate level between users and permissions, role-based access control (RBAC) mitigates the difficulty. There, users are assigned to roles; roles in turn are associated with permissions [9, 24]. RBAC has been regarded as an effective approach to the access control problem of medium and large size organizations [23]. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ASIACCS ’12, May 2–4, 2012, Seoul, Korea. Copyright 2012 ACM 978-1-4503-1303-2/12/05 ...$10.00. However, RBAC systems are costly to develop and maintain. Putting aside other problems, the creation of an RBAC configu- ration, which consists of identifying a set of appropriate roles and assigning users and permissions to roles, is not easy [14, 21]. As such, various role engineering (RE) approaches have been pro- posed to find “good” configurations, e.g., [5, 8, 21, 29]. Provided with certain information about the organization in question, an RE tool produces a configuration. Nonetheless, one main limitation of existing approaches is that, the discovered configuration does not necessarily meet constraints. Organizations’ security officers often specify constraints to en- force high-level security objectives. One typical example is a separation-of-duty policy, which, for example, prohibits a user from performing two mutually exclusive permissions (e.g., prepare a check and authorize a check). 1 Moreover, constraints could also be used to model business requirements. For example, an organi- zation may place a constraint that a role emergencyManager be assigned to at least two users, so that at least two managers are available in an emergency. As an inherent part of the classic RBAC models [24] and the standards [2, 9], constraints play an important part in capturing organizations’ requirements [1, 7, 17, 27]. A configuration inconsistent with constraints, if deployed, may undermine organizations’ interests, by means of authorizing other- wise forbidden accesses or depriving users of due privileges. This poses continual challenges. When being deployed, the configura- tion ought to comply with constraints. Afterwards, this compli- ance should persist. However, organizations’ security and business requirements are subject to constant changes. One misleading as- sumption is that people can establish their requirements once for all; it obstructs the integration of research efforts with practices [26]. Hence, a deployed configuration needs updating from time to time to reflect organizations’ requirements [8, 21]. Unfortunately, so far little effort has been devoted to constraint support when organizations are adopting RBAC configurations or undergoing evolution. On the one hand, the state of the art of RE barely takes constraints into consideration; as a result, it is neces- sary to adapt discovered configurations for constraints. As pointed out in [21, 29], a post-processing like this is often unavoidable and, if done manually, is a large bottleneck. Hence, an effective and efficient support of constraints for RE is worth investigation. On the other hand, the research literature on constraints in access con- trol has focused mainly on checking if there exists a configuration consistent with constraints (e.g., [27]) or if a change to a configura- tion is safe with respect to constraints (e.g., [7, 17]). They provide inadequate help. Although some approaches such as [27] gener- ate configurations in presence of constraints, they are not tailored 1 To increase the cost of an fraud, it is often required that no user can both prepare and authorize a check.