XACML for RBAC and CaDABRA:

Constrained Delegation and Attribute-Based Role Assignment

Brian J. Garback

Computer Science Department
University of Virginia
Charlottesville, VA


Alfred C. Weaver

Computer Science Department
University of Virginia
Charlottesville, VA

ABSTRACT

In this paper, we describe a model for and implementation of an enterprise access control system that extends standard RBAC and XACML, the eXtensible Access Control Markup Language, to implement CADABRA, constrained delegation and attribute-based role assignment. Our motivation comes from an effort to support web-based, federated healthcare requirements for authorization, including remote-user authorization and permission delegation. Our authorization system effectively represents authorization policies, provides dynamic permission definition, attribute-based role assignment, and enforcement, and provides delegation with complete administrative control. Two conditions provide this control. As part of a permission to delegate, a delegation condition must be met by a delegator and a delegate assignment condition must be met by the delegate to have a delegated permission assigned. We have created a web-services implementation of our model and through timing measurements it has proven an efficient solution for web-based enterprise authorization.

Categories and Subject Descriptors

D.4.6 [Operating Systems]: Security and Protection – Access controls

General Terms

Performance, Security, Languages

Keywords

Access control, RBAC, XACML, delegation, attribute-based role assignment, trust management, web-based

1.  INTRODUCTION

Web-based operation has promoted new levels of enterprise cooperation, but without privacy and security guarantees some industries cannot afford to make this change. For example, within the healthcare industry, coordination between hospital, pharmacy, and insurance systems is lacking due to HIPAA [1] regulations. Integration of their services would allow a patient to fill electronic prescriptions, register insurance claims, and have universal access to electronic medical records without having to negotiate individual, offline transactions. A web-based trust management system ensuring data privacy and security can enable this cross-domain technology. Inter-domain and intra-domain authorization is critical to trust management. Its requirements are the following:

·  Effective representation of authorization policies

·  Dynamic permission definition and enforcement

·  Permission delegation with administrative control

Policy representation for our authorization model is based on role-based access control (RBAC) and the eXtensible Access Control Markup Language (XACML).

Role-based access control is an established technology that simplifies permission management by associating users with roles and roles with access rights. For example, a hospital administrator would define the roles (physician, patient, medical student, pharmacist, etc.), associate them with permissions to manipulate medical data, and then assign individual users to them. A role hierarchy can be setup where roles inherit the permissions of their child roles.

The massive number of resources, data types, access types, and users within any large enterprise makes permission definition based on these objects and their relationships complex. For example, in a teaching hospital, a medical student can read a patient’s medical record only if the patient’s attending physician authorizes such access. To manage these access rules an authorization system must be able to define conditional access rules, evaluate the context associated with them dynamically, and provide the administrator with an effective means of managing system-wide permissions.

Version 2.0 of the eXtensible Access Control Markup Language (XACML) was approved in February of 2005 [2]. This xml extension language is used to specify authorization requests, policies, and responses, and enforce those policies by combining them and comparing them to requests. XACML also proposed a draft profile for RBAC implementation in September 2004 [3]. This profile describes how to perform user-to-role assignment and role-to-permission assignment using a role hierarchy.

Hierarchical RBAC does not completely answer the authorization problem for trust management. Constrained delegation and attribute-based role assignment, CADABRA, are also required. ABRA simply refers to assigning roles to users based on expressions of user attributes. The number of local and remote users of an enterprise may be vast and using ABRA a large number of those users can have their roles dynamically assigned via their local or remote attributes. Enterprise situations arise that require conditional delegation. For example, in the health system a doctor may want to delegate to a medical student the permission to read a patient’s chart. Delegation adds further complication by requiring support for revocation and additional administrative controls. This control can be implemented through two conditions:

  1. The Delegation Condition is fulfilled by the delegator before he can delegate a permission.
  2. The Delegate Assignment Condition is fulfilled by the delegate before a role is assigned to him.

Our model provides an XACML implementation for both ABRA and conditional delegation.

Motivated by the goal of providing a complete access control system for enterprise applications, this paper proposes the addition of CADABRA to hierarchical RBAC using XACML. This paper is organized as follows. Section 2 motivates this research with a survey of related work on RBAC, delegation, and authorization as a part of trust management. Section 3 gives a detailed description of hierarchical RBAC, XACML, and the RBAC profile of XACML. Section 4 describes our authorization design incorporating RBAC and CADABRA into XACML. Section 5 provides measurements from a web-based implementation of our authorization system. Section 6 presents our conclusions and plans for future work.

2.  RELATED WORK

Role-based access control is widely accepted as an alternative to traditional access control models [4]. The general model, RBAC96 [5], formalized the idea that permissions are associated with roles, users are assigned to roles, and users inherit the permissions associated with their roles, thereby simplifying security administration.

Delegation of authority is critical to access control systems and many of its aspects have been addressed. Stein proposed an object-oriented framework in 1987 to capture the observation that inheritance and delegation are essentially alternate methods. In 1990, Gasser and McDermott provided an architecture for delegation in a distributed system that addresses user-to-machine delegation [6]. Abadi presented a way to express delegation with a calculus for access control in distributed systems [7]. Nagaratnam and Lea presented a model for process-to-process delegation for distributed object environments [8]. The ARBAC model proposed by Sandhu et al. dealt with delegation among role administrators [9]. Goh and Baldwin treated delegation as a part of a more complete model of a role [10]. Aura recognized delegation can be effective when used for access control in a distributed environment [11]. Barku and Sandhu developed a framework for building role-based delegation models by identifying interesting human-to-human delegation cases [12].

Increasingly it is being recognized that traditional authorization methods are not powerful enough to handle security for large scale distributed applications. Blaze examined the inadequacies of existing authorization systems and proposed trust management [13]. KeyNote [14], PolicyMaker, and SPKI/SDSI [15] have also worked with the ideas of trust management, but none has provided a view of permission assignment and enforcement with complete constrained delegation.

Recently, models of delegation more similar to ours have been proposed. RBDM0 and RDM2000 dealt primarily with whole role delegation. RBDM0 was concerned with multi-step delegation and revocation within a role hierarchy [16]. RDM2000 extended RBDM0 by providing a role-based delegation model supporting hierarchical roles and multi-step delegation and a rule-based language for policy specification and enforcement [17]. RDM2000 also introduced the notion of a prerequisite condition to constrain which role can be delegated to whom. PBDM addressed multi-step delegation and revocation at the role and permission level within a role hierarchy [18]. Several PBDM models were proposed to support both user-to-user and role-to-role delegation and administrative controls such as only allowing a subset of a role’s permissions to be delegated. The attribute-based-delegation model (ABDM) addressed managing and constraining delegation [19]. ABDM also differentiated between decided and undecided delegatees. Although ABDM introduced the delegation constraint that must be satisfied by the delegatee, little coverage in ABDM was given to how delegation constraints carry through delegation chains.

Security within distributed healthcare is commonly used as an application of these authorization technologies. Weaver et al. proposed a design for federated, secure trust network for distributed healthcare, which provided the foundation for the research presented in this paper. Zhang et al. [20] presents a delegation framework that can be used within the security framework of healthcare applications. Wilikens et al. [21] discusses how to apply CBAC to healthcare, but the model is static and not able to handle arbitrary context-dependent authorization policies.

3.  HIERARCHICAL RBAC AND XACML

This section begins with a description of hierarchical RBAC and XACML. Then, the profile for RBAC using XACML is discussed. These technologies motivate the research discussed in section 4.

3.1  Hierarchical Role-Based Access Control

Role-based access control is widely accepted as an alternative to protection matrix-based techniques. The idea of associating a set of permissions with a role and assigning that role to users has become widely adopted in many commercial systems and is quite suitable for the healthcare system. With objects such as patient records, images, prescriptions, medications, and demographic information, and roles such as physicians, nurses, medical students, patients, and administrators, the health system is a clear fit for RBAC. The user-to-permission mapping can be made quickly by first establishing the role-to-permission mapping, then assigning a user to a role. Example mappings of a medical system are shown in Figure 1.

Figure 1. Medical RBAC Example

To extend this application of RBAC, a role hierarchy can be implemented. The main idea is that roles are associated with permissions and may also be associated with other roles and their permissions. These hierarchies can be used in the health system to represent responsibility and ability. It also limits redundant permission definition within roles and provides a more intuitive view of permissions to ease the work of the role administrator. An example healthcare role hierarchy is presented in Figure 2.

Figure 2. Medical Hierarchical RBAC Example

In this example, the universal role would provide permissions to change one’s demographic information. Patients and physicians have permission to access medical data and inherit hospital user. A surgeon can perform surgery while an orthopedist can perform x-rays and each of these inherit physician.

Figure 3. XACML Documents and Their Relationships

3.2  XACML 2.0 Core

The eXtensible Access Control Markup Language is an XML extension language used to specify and enforce authorization policy. Version 2.0 was approved by OASIS in February of 2005.

XACML provides a standard architecture for making authorization decisions (see Figure 3).

  1. Access requests are filtered by the Policy Enforcement Point (PEP).
  2. The PEP forms a formal XACML request using context from the access and any additional, necessary context from the Policy Information Point (PIP).
  3. The XACML request is forwarded to the Policy Decision Point (PDP).
  4. The PDP gathers authorization policies that apply to this request.
  5. The PDP gathers additional attributes needed to compare the request to the policies.
  6. A comparison is made by the PDP and the decision is returned as an XACML response to the Policy Enforcement Point (PEP).
  7. The PEP permits or denies access.

Figure 4. XACML Decision Architecture

XACML specifies three types of xml documents: requests, responses, and policies. They and their relationships are represented in Figure 4.

A <Request>, which describes an access, contains three sets of attributes, one for the <Subject> who made the request, one for the <Resource> he is trying to access, and one for the <Action> he is trying to take.

A <Policy Set> is a set of policies and a <Policy> represents an authorization policy, generally a set of permissions. A <Policy> is composed a <Target> and a set of <Rule>s. A <Target> filters requests by comparing its subjects, resources, and actions to the attributes in a request. A <Rule> is intended to represent an access rule or permission. It contains a <Target> and a <Condition>, which is a logical expression of attributes comparisons.

A <Response> contains the <Result> of the request-policy comparison: an authorization <Decision> and additional <Status> regarding the decision.

The PDP takes a request and finds all policies whose targets match the request. Within those policies, the PDP finds all rules whose targets match the request. The conditions in matching rules are then matched against the request, the results of these comparisons are combined, and a response is returned to the PEP.

3.3  XACML Profile for Hierarchical RBAC

The RBAC profile of XACML v2.0 was approved in September 2004 [21]. It presents a method of assigning role attributes, specifying core and hierarchical roles and their permissions, and then authorizing access.

This profile uses four XACML policy/policy set types to implement RBAC:

·  Role Policy Set or RPS: associates a role with a PPS

·  Permission Policy Set or PPS: contains all the permissions associated with a role

·  Role Assignment Policy: defines which roles are assigned to which subjects

·  HasPrivilegesOfRole Policy: supports queries to determine if a user has a certain role assigned

In order to express a role hierarchy, the PPS of one role references the PPS of another role thereby inheriting all the permissions of that referenced role.

This profile contains an example of a hierarchical authorization system consisting of two roles, manager and employee. A manager can sign a purchase order and an employee can create a purchase order. Additionally, the manager role inherits employee and its permission to create a purchase order.

Figure 5 and Figure 6 contain examples of RBXACML policies and corresponding requests and responses.

Figure 5. A <Request> to determine if Seth has the employee role assigned matches
the Employee Role <Rule> in the Role Assignment <Policy>.

4.  RBAC WITH CADABRA IN XACML

The XACML profile of RBAC has a couple shortcomings. It lacks a clear specification of role assignment as it states “There is no fixed form for a Role Assignment <Policy>.” Additionally there is no mention of delegation. To address these issues, this paper presents an implementation of CADABRA, conditional delegation and attribute-based role assignment, using XACML.