Comprehensive two-level analysis of role-based delegation and revocation policies with UML and OCL

Abstract

Context. Role-based access control (RBAC) has become the de facto standard for access management in various large-scale organizations. Often rolebased policies must implement organizational rules to satisfy compliance or authorization requirements, e.g., the principle of separation of duty (SoD). To provide business continuity, organizations should also support the delegation of access rights and roles, respectively. This, however, makes access control more complex and error-prone, in particular, when delegation concepts interplay with SoD rules.Objective. A systematic way to specify and validate access control policies consisting of organizational rules such as SoD as well as delegation and revocation rules shall be developed. A domain-specific language for RBAC as well as delegation concepts shall be made available.Method. In this paper, we present an approach to the precise specification and validation of role-based policies based on UML and OCL. We significantly extend our earlier work, which proposed a UML-based domain-specific language for RBAC, by supporting delegation and revocation concepts.Result. We show the appropriateness of our approach by applying it to a banking application. In particular, we give three scenarios for validating the interplay between SoD rules and delegation/revocation. Preprint submitted to Information and Software TechnologyApril 19, 2012 Conclusion. To the best of our knowledge, this is the first attempt to formalize advanced RBAC concepts, such as history-based SoD as well as various delegation and revocation schemes, with UML and OCL. With the rich tool support of UML, we believe our work can be employed to validate and implement real-world role-based policies.

A Review of Delegation and Break-Glass Models for Flexible Access Control Management

“…Similarly, some break-glass approaches allow for the definition of break-glass policies for individual subjects (subject-based break-glass policies, see, e.g., [1,29,34]), others allow for the definition of break-glass policies on role-level (role-based break-glass policies, see, e.g., [7,16,45]). In addition, some of the delegation and break-glass models explicitly address entailment constraints (see, e.g., [39,42,45]). Entailment constraints define additional conditions for access control decisions by considering, e.g., the task history or certain context information (such as time or location).…”

“…A SOD constraint defines that two permissions/tasks must not be assigned to (or activated/performed by) the same subject, while a BOD constraint defines that two bound permissions/tasks need to be assigned to the same subject or role. Furthermore, some approaches offer modeling support to visualize the respective concepts, some approaches (also) provide corresponding tool support for enforcing delegation or break-glass policies (see, e.g., [37,38,42]). This variety presents a challenge for researchers working in this field or wishing to quickly grasp the state of research.…”

“…An approach similar to [50] is presented in [23], where a capability-based delegation model (CRBAC) based on RBAC96 (see [30]) is introduced to support cross-domain delegation of roles and permissions in terms of capability transfer. Recently, an approach for the model-based specification of rolebased delegation and revocation policies via UML was introduced in [42]. They use standard UML class and object diagrams for graphically visualizing delegation policies.…”

“…They use standard UML class and object diagrams for graphically visualizing delegation policies. Corresponding tool support as well as conflict detection and resolution handling are not provided in [42].…”

Verification of Authorization Policies Modified by Delegation

“…Instances of patterns 1 to 3 can be checked over an authorization model instance, and instances of patterns 4 to 9 can be checked over a delegation model instance. In section 4.1, we introduce a banking example partially borrowed from [25]. We model this example and illustrate how patterns can be instantiated to detect SoD conflicts in this setting.…”