## 1 Introduction  
With the rapid development and comprehensive application of network information technology, there is a large amount of storage required and many exchanges in large-scale and complex information-management systems [1]. Organizations adopt access control mechanisms to ensure the system security, and the role-based access control (RBAC) mechanism has been the main standard for most organizations over the last three decades. However, there is only one role attribute in RBAC systems on which users and objects can depend. The RBAC mechanism is identity-dependent and lacks flexibility, particularly in large-scale collaborative environments. As an alternative, attribute-based access control (ABAC) has been developed recently. In ABAC, a request for accessing any resource is permitted or denied based on the attributes assigned to the requesting user, the attributes assigned to the requested object, the environment condition where the request is made, and an authorization policy [2]. An ABAC policy is a set of authorization rules that includes various combinations of attribute-value pairs of users, objects, and environments, as well as operating privileges. If a user makes a request to access an object, an authorization rule to satisfy the access request is sought. Its flexibility, scalability, and identity-less properties overcome the limitations of RBAC, and make ABAC very attractive for use in collaborative systems like cloud computing and the internet of things [3]. For the successful implementations of ABAC mechanisms in commercial organizations, the identification of a suitable set of authorization rules and the construction of a good ABAC system are critical tasks. This process, known as policy engineering [4; 5], is regarded as one of the most difficult and costliest components for implementing the ABAC mechanism. Similar to role engineering in RBAC, there are also two main approaches for constructing policy-engineering systems: top-down [6] and bottom-up [7; 8; 9]. For the former, rules are specified by precisely evaluating and splitting the business processes into smaller independent units that are then associated with access permissions. However, this approach can ignore the existing access modes in the organization and is also time-consuming, labor-intensive, and error prone. For the latter, rules are derived from existing access permissions, and the architectural structure of ABAC can be automatically constructed. The bottom-up approach, also called policy mining, has gained much interest and considerable popularity in the last few years. The policy-mining problem in ABAC involves discovering a suitable ABAC policy from a traditional access control mode, such that the access authorizations covered by the policy are consistent with the traditional access permissions. [PERSON] and [PERSON] [10] first proposed a well-known bottom-up mining approach (simply represented as Xu-Stoller) and derived an ABAC policy from access control lists and the corresponding attribute data. [PERSON] et al. [11] considered that the policy-engineering problem in ABAC and the role-engineering problem in RBAC are similar and equally important for the construction of the corresponding access control models and presented a detailed survey of the two techniques. Actually, to enhance the interpretability of policy mining, it is necessary to cluster users, objects, or environments with the same attribute properties, similar to the clustering of users or permissions in the role-mining problem. However, due to the diversity of the attribute properties of entities and the variability of accesses, the mining scale is large and complex using conventional policy-mining methods.