ARBAC Policy for a Large Multi-National Bank

Administrative role-based access control (ARBAC) is the first comprehensive administrative model proposed for role-based access control (RBAC). ARBAC has several features for designing highly expressive policies, but current work has not highlighted the utility of these expressive policies. In this report, we present a case study of designing an ARBAC policy for a bank comprising 18 branches. Using this case study we provide an assessment about the features of ARBAC that are likely to be used in realistic policies.

💡 Research Summary

The paper presents a comprehensive case study of designing and analyzing an Administrative Role‑Based Access Control (ARBAC) policy for a multinational bank with eighteen branches. Building on a previously published RBAC model for a European bank, the authors replicate a set of 33 job‑specific roles for each branch, resulting in a total of 594 roles across the organization. The roles are organized into four business divisions—Financial Analyst (FA), Share Technician (ST), Office Banking (OB), and Support E‑Commerce (SE). Within each division there is a top‑level division role, two managerial roles (Head of Division and Group Manager), and five non‑managerial roles (Assistant, Specialist, Senior, Junior, Clerk). All branch‑specific roles inherit from a generic “Employee” role.

The primary security objective is to enforce a Separation‑of‑Privilege (SOP) constraint that limits any user to at most three of the five non‑managerial roles within a single division. To achieve this, the authors exploit three expressive features of ARBAC: disjunctions, positive preconditions, and mixed (positive and negative) preconditions. They illustrate the construction of can‑assign rules for the FA‑Clerk role as a representative example. The assignment logic is divided into three cases: (1) the user holds none of the other non‑managerial roles, (2) the user holds exactly one, and (3) the user holds exactly two. Each case is encoded by a set of can‑assign rules that enumerate the permissible combinations of positive and negative role memberships. For instance, when a user already holds two non‑managerial roles, a rule with three positive preconditions (the division role plus the two existing non‑managerial roles) and two negative preconditions (the remaining non‑managerial roles) permits assignment to a third role. Similar rule sets are generated for all non‑managerial roles. Managerial role assignments are restricted by including negative preconditions for all non‑managerial roles, ensuring that a user cannot simultaneously hold a managerial and a non‑managerial role in the same division.

All roles are defined as revocable, leading to 594 can‑revoke rules (one per role). The policy therefore supports full lifecycle management of role memberships.

For verification, the authors formulate safety queries of the form ⟨user, target‑role⟩ to ask whether a particular role can eventually be assigned to a user under the administrative rules. Two concrete questions are examined: (1) can a user be assigned to four non‑managerial roles in any single branch, and (2) can a user be assigned to four non‑managerial roles in all eighteen branches simultaneously? To encode these questions, auxiliary roles AnyFour_i (one per branch) and Branch_i (also one per branch) are introduced. AnyFour_i becomes assignable when a user holds four non‑managerial roles in branch i, while Branch_i is made assignable if the user holds AnyFour_i or Branch_(i+1). By adding a single can‑assign rule that links the administrative role “Admin” to Branch_1 (for question 1) or to the conjunction of all Branch_i roles (for question 2), the authors reduce each question to a standard safety query. These queries can be fed to model‑checking tools to automatically verify whether the SOP constraints are upheld before policy deployment.

The study demonstrates that the expressive constructs of ARBAC—particularly disjunctions and mixed preconditions—are essential for modeling realistic SOP constraints in large‑scale financial institutions. However, the same expressive power increases the computational complexity of safety analysis, underscoring the need for formal verification techniques. By providing a concrete policy specification, a systematic rule‑construction methodology, and a clear approach to safety‑query formulation, the paper offers a practical blueprint for banks and other regulated enterprises seeking to implement robust, analyzable administrative access‑control policies.