XACML for RBAC and CaDABRA:Constrained Delegation and Attribute-Based Role Assignment

Brian J. GarbackComputer Science Department

University of VirginiaCharlottesville, VA

bjg5x@cs.virginia.edu

Alfred C. WeaverComputer Science Department

University of VirginiaCharlottesville, VA

acw@cs.virginia.edu

ABSTRACTIn 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 DescriptorsD.4.6 [Operating Systems]: Security and Protection – Access controls

General TermsPerformance, Security, Languages

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

1. INTRODUCTIONWeb-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 WORKRole-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 XACMLThis 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 ControlRole-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.

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.

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.

EMBED Visio.Drawing.11

Figure 2. Medical Hierarchical RBAC Example

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.

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 RBACThe 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

Figure 3. XACML Documents and Their Relationships

Figure 4. XACML Decision Architecture

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.

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.

4.1 Attribute-Based Role AssignmentOur authorization model contributes to a larger project on trust management. This current research focuses on the establishment and management of domain trust relationships. With such relationships, domains can exchange attributes that can then be used to identify remote users. After identification, users need permissions to make system accesses. Our model uses RBAC where permissions are assigned through two types of user-role assignment. This is the top layer of trust management.

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

The first type is direct role assignment where a user-role mapping is explicitly defined for a user and role. For instance, a new physician in a hospital would be enrolled by the administrator Figure 7. This direct mapping requires that a system administrator manually assign the role for the user based on some unique user identifier. Direct role assignment can be made for both local and remote users.

There are times where this manual role-assignment process is insufficient. In large groups of trusting domains, the number of users for any one domain could number in the hundreds of thousands or even millions. Manual assignments would be impractical and infeasible. Instead, role assignment can be performed for remote and local users using expressions of subject attributes rather than unique subject identifiers. Inter-domain attribute exchange and attribute mapping are provided through lower layers of trust management and allow remote user attributes to be accessed similarly to local user attributes. This method of assigning roles to users through logical expressions of user attributes is known as attribute-based role assignment (ABRA). For example, shown in Figure 8, a hospital could have an access rule that assigns the physician role to any user who has the physician role assigned in a highly-trusted remote domain. Direct role assignment is basically a simple expression of user attributes and is covered by ABRA.

4.2 Constrained Delegation Design4.2.1 Healthcare Requirements for Delegation Delegation is simply one entity giving a portion of its authority to another. An entity can be either an actor such as a physician or software such as a web service. Examples of how delegation may occur in the health system are as follows:

A physician taking leave may temporarily delegate his attending physician rights on a patient to another physician.

A physician may delegate his right to view a patient record to one of his medical students.

A board-certified mammographer can delegate his rights to read a patient’s mammograms to an image analysis web service to aid in diagnosis.

4.2.2 Maintaining RBAC with DelegationIn order to effectively integrate delegation into any RBAC system, RBAC requirements must be preserved. Similar to core administrative permission assignment, permission delegation must be accomplished via role assignment.

A delegator can be thought of as a limited administrator of his own permissions. As such, he can define a new delegation role as a subset of permissions in a role he has assigned and assign that delegation role to other users through ABRA. Because role assignments may not be permanent, all delegation assignments are conditioned on the delegator having the original role assigned.

A delegation role can only be a subset of the permissions within an existing role for a couple reasons. First, administrative oversight is greatly increased if a user’s permissions can be viewed in terms of regular roles even though these regular roles may represent more permissions than a user actually has. Additionally, the role hierarchy was setup by an administrator and no user should be able to alter or change this hierarchy in any way.

Figure 6. A <Request> for Steve to sign a purchase order matches the Employee PPS through the Manager RPS and PPS.

Figure 7. Direct Role Assignment

Figure 8. Attribute-Based Role Assignment

4.2.3 Delegation ConstraintsIntegrating delegation into an authorization system necessitates administrative control over delegation by constraining which permissions are allowed to be delegated and how they are allowed to be delegated.

An administrator or delegator can declare a subset of a role’s permissions delegatable to limit what is delegatable. To control how a delegator is allowed to delegate a role, two conditions can be associated with each delegatable permission:

1. A delegation condition must be fulfilled in order for a delegator to be able to delegate the permission.

2. A delegate assigning condition must be fulfilled by the delegate to have the delegation role with this permission assigned.

With these constraints, in addition to defining and assigning roles, a delegator or administrator can constrain how delegated permissions can be delegated further.

4.2.4 Constraining Multi-Step DelegationA user can be assigned to both delegated and regular roles and should be able to delegate either type; but, in order to implement multi-step delegation, RBAC must be preserved and any delegation constraints associated with a role should be inherited by a delegation role. This constraint inheritance must occur for both the delegation conditions and the delegate assigning conditions.

Every delegatable permission in a role has a delegation condition. A delegator must satisfy the delegation condition of each permission he is delegating in order to be permitted to delegate. The delegated role’s permissions inherit the delegation conditions of the original role and the delegator can logically “and” more conditions to them.

Every delegatable permission in a role has a delegate enabling condition. In order to be assigned to a delegation role, a delegate must satisfy all of them. A delegator can logically “and” more conditions to the delegate enabling conditions.

4.2.5 Constraints and the Role Hierarchy When introducing delegation constraints into a role hierarchy, it is necessary to be sure that none of the delegation or role hierarchy properties are violated. Again, a delegator can choose what to delegate and constrain how permissions are delegated further.

Just as a user can select a subset of a role’s permissions for delegation, he can also select a subset of a role’s inherited roles for delegation. Going back to Figure 2, if a user wishes to delegate Physician, he may also delegate Hospital User. In order to perform the delegation, the delegator must meet the delegation conditions for all permissions in both roles he is delegating. Then, if a delegate meets the delegate enabling conditions for D-Physician, he will have D-Physician assigned. If D-Physician is assigned, and the user meets every delegate enabling conditions for D-Hospital User, he will have D-Hospital User assigned also.

4.3 Revocation of Delegated PermissionsThe inclusion of delegation into an authorization system necessitates mechanisms to revoke delegated permissions. Here are several ways revocation can be accomplished:

At delegation time, a delegator can define conditions for enabling rules that contain a time and date to disable a role.

A delegator can dynamically revoke a role he has delegated.

An administrator can dynamically revoke any role.

In the case of multi-step delegation, if any delegator ever has a role revoked, then all delegation roles based on that role are revoked.

4.4 Implementation of RBAC and CADABRAOur implementation of RBAC and CADABRA sought to capture the functionality present in the XACML profile for RBAC, attribute-based role assignment, and constrained delegation while simplifying the policy structure presented in that profile. To this end, we present only two policy types:

1. Role Assignment Policy: a policy that contains rules to assign roles to a subject

2. Permission Policy: a policy that contains all the permissions associated with a role

Each role in the system is represented by one role assignment policy and one permissions policy. These policies are implemented as XACML policies and the assigning rules and permissions are implemented as XACML rules. Assigning rules specify targets and conditions based solely on session-independent attributes such as attributes about a subject with the only exception being an expiration time. Permissions on the other hand deal with attributes concerning an access, such as the resource, action, or the subject’s session.

The authorization system can be separated into two distinct parts, one for policy specification and one for policy enforcement. Delegation requires additional conditions and rules be specified in the policies.

4.4.1 Policy SpecificationPolicy specification involves the definition of roles, their assigning rules and permissions, and the role hierarchy. Attribute-based role assignment is accomplished through the targets and conditions of assigning rules. If any assigning rule within a role assignment policy is satisfied, a user is assigned to that role. Permissions can be thought of as actions on resources given conditions. A role is defined by defining the assigning rules for its role assignment policy and permissions for its permission policy. The role hierarchy is setup by specifying assigning rules to assign a role for any user who has an inheriting role assigned. For example, the hospital user role will have a rule to assign any user with the Physician role assigned.

In our implementation, a policy generator web application, found in Figure 9, accomplishes this task of policy specification. It allows an administrator to create roles and specify their role assignment permission policies. It stores this information to an intermediate database and calls a web service to build XACML

policies based on the contents of the database. These generated policies are respectively stored in the permission policy and assignment policy databases.

The policy generator also allows non-administrative users to examine their own permissions and manage delegation. Delegation roles can be defined based on delegatable permissions and assigned to other users. Once delegation roles are defined, a delegator can remove them or change their assigning rules and permissions. This is similar to administrative role specification except that delegation conditions must be checked prior to generating the roles and that delegators are limited in only being able to delegate roles and permissions that are a subset of those assigned to him.

4.4.2 Policy Enforcement The following are the detailed steps for policy enforcement based on our implementation presented in Figure 9:

1. A data request and a requestor-identifying token from the portal arrives at the Policy Enforcement Point (PEP)

2. The PEP parses the request and token for attributes and generates an XACML request.

3. The PDP parses this request and if the user’s roles are not specified in the token, queries the role assignment web service with one query per role in the system.

4. The role assignment service compares the role-assignment request with the assignment policy for the requested role, queries the attribute service as needed and evaluates context, and responds permit or deny.

5. The PDP compares the XACML request to the permission policies corresponding to the user’s assigned roles, queries the attribute service as needed and evaluates context, and responds either permit or deny.

6. At this point, the PEP enforces the PDP response by permitting or denying access to the web service.

4.4.3 Extensions for DelegationTo accommodate delegation and its constraints, extensions need to be made to this initial design for RBAC. In a permission policy, two additional rules are included for each delegatable permission. The first, the delegation permission, is the permission to delegate the delegatable permission and contains the delegation condition. Its target requires the resource to be the id of the delegatable permission and the action to be delegate. The second, the delegate enabling permission, is a rule to store the delegate enabling condition associated with the delegatable permission. The policy generator must allow the specification of these additional conditions.

When creating a delegation role, a delegator must specify its enabling rules. A delegation role can contain any number of permissions each of which is associated with a delegate enabling rule. When the delegator creates an enabling rule, all of the delegate enabling conditions in the delegate enabling rules will be referenced and logically anded together and then anded to the condition in the enabling rule.

There are several extensions that must be made to the XACML specification in order to fully implement delegation. The current XACML specification does not support condition references so we implemented them for delegate enabling conditions. Also, delegation requires that additional attributes be added to some of the XACML tags. Delegator and parent-role attributes are needed in the policy tag in order to identify the delegator and the role from which this role was delegated. Additionally, the attribute designator tag in the policies, which identifies an attribute contained in the request context, must also have a delegator attribute added to it. Policies can be relative to the subject accessing them so it is necessary to associate a delegation policy with the delegator. For example, a user with the physician role is granted access to any part of a patient’s record if he is the attending physician. If a physician delegates his rights to a patient record, that permission must still be

Figure 9. Authorization Architecture

dependent on the delegator’s relationship to a patient and not the delegate’s.

4.4.4 Detailed Delegation ProcessIn order to more explicitly describe how delegation constraints are managed, the following is a standard use case for a user attempting to delegate one of his roles:

1. The user loads the policy generator and views his list of assigned roles.

If an assigned role has a delegatable permission, he can choose to delegate that role.

2. He selects a role and chooses to delegate it.

He views all the delegatable permissions and their targets and conditions. The three conditions associated the delegatable permission are inherited by the delegation role.

3. He can alter the delegation role’s permissions by either removing permissions from the role or logically “anding” more conditions to the permission, delegation, and delegate assigning conditions.

4. He creates a new enabling rule.

The condition for this rule is logically “anded” to the delegate enabling conditions associated with permissions in the delegation role.

5. He initializes the enabling rule by logically “anding” more conditions to the rule and creating subject targets.

6. He generates the role.

His permission to delegate is verified by checking the delegation conditions associated with permissions in the delegation role. If he is permitted, then the role is generated. E

Figure 10 provides an example of this process using the medical scenario of a physician delegating right to read a patient record to his medical student.

5. PERFORMANCE EVALUATIONThe use of XML as a tool for authorization raises questions as to expressiveness versus efficiency, particularly in a large enterprise. Ideally, authorization should account for a negligible amount of time per access but it is necessary that all access conditions be expressed and context be checked completely. The authorization process can be found in Figure 5 and section 3.2.

Our implementation extends Sun’s implementation of off XACML, SUNXACML 1.2, which enabled us to read all the authorization policies into memory as they are defined, independent of request comparison. Therefore, the time to read policies does not factor into access time. Instead, authorization time consists of transfer time, formal request generation, request parsing, attribute gathering, request-policy comparison and context evaluation, response building, and response parsing.

In an attempt to accurately represent average-case enterprise authorization, the following assumptions were used for testing. An average hospital might see 50,000 patients visiting every year but larger ones may see more. Hospitals staff are staffed by approximately 5000 people with access to medical data such as doctors, nurses, medical students, etc. So we assume 100,000

Figure 10. A Physician, subject #5, attempts to delegate his permission to read patient 10’s recordby creating a delegation role with this permission and directly assigning it to subject #4.

users will have accounts in the local domain. As for permissions, let us assume there are 50 resource types including prescriptions, medical records, and demographic data and 5 actions to perform on each resource such as read, delete, or create. Let us assume there are 15 regular roles in a hospital such as physician, nurse, nurse practitioner, medical student, and patient. Assuming that patients will not perform delegation, and only a fraction of the staff will be delegating permissions at any one time, let us assume 2,000 delegation roles at any one time. Using these numbers and our prototype of an enterprise health system, measurements were made for authorization and role assignment. The machine used for testing was a 3 GHz P4 with 1 GB of RAM.

For authorization, request generation time is 38 ms. The request parsing time is 3 ms. The average time for the PDP to gather attributes and authorize a formal request is 30 ms. All local transfer times are less than one ms. Therefore, the total time to authorize an access is 71 ms.

The average total time to determine which regular and delegation roles a user has assigned is 983 ms. Role assignment is trivially parallelizable because each role can be checked independently, so taking a distributed approach could cut this number down to a fraction of this original value. If the time were reduced to a tenth of the original, it would take 98 ms to determine a user’s roles.

Without authorization, the average time to perform an access over a high speed connection to our medical data portal is 703 ms. If authorization is added into this system, the total time for an authorized access would be 774 ms. The 71 ms is a mere nine percent of that time. This additional time is definitely tolerable in a web-based health system where tens of milliseconds are not critical. Role assignment can be determined per session or per access. The 98 ms this process takes is definitely tolerable during the login process. Per access, this 98 ms added to the 71 ms for authorization would result in 19% of the 872 ms total access time. This result should still be tolerable.

From this performance study, several issues stand out. First, implementing direct role assignment through ABRA, though it is in keeping with the XACML framework, is unnecessary and accounts for a majority of the role assignment time. ABRA maps roles to users, but if users were mapped to roles, it would hardly take a millisecond to determine a user’s directly assigned roles. Also, if a user has no directly assigned roles, such as is the case with most remote users, no time will be spent evaluating direct role assignment. Second, attribute gathering is a large contributor to role assignment time. Attribute-caching at access time inside the PDP would do a great deal to minimize this time because of the likelihood that many role assigning rules will require the same attributes.

6. CONCLUSION AND FUTURE WORKWe described an implementation of an enterprise access control system that extends standard RBAC and XACML to implement CADABRA, constrained delegation and attribute-based role assignment. Our motivation came from an effort to support complex federated health system authorization requirements, including remote-user authorization and permission delegation,

which were not clearly defined by the profile of XACML for RBAC. To the end, we created an access control system that effectively represents authorization policies, provides dynamic permission definition, assignment, and enforcement, and provides complete administrative control over delegation. Through a performance analysis of our prototype application, we have learned that direct role assignment may be better accomplished outside of ABRA through a direct user-to-role mapping and that attribute-caching within the authorization system reduces the overhead of redundant attribute gathering. Even without these optimizations, our work proves that an extended version of XACML for RBAC and CADABRA is sufficiently expressive and efficient for use as the backbone of an electronic medical data portal’s authorization system.

The future work includes the study of a more formal method of request generation in the PEP for a web-based enterprise application. Also, more testing is needed to ensure delegation chains are not too cumbersome a solution because of the inherent condition aggregation. Efforts to refine the specification of permission-grained delegation constraints are needed. This system also opens up further research into access logging and auditing.

7. ACKNOWLEDGMENTSI would like to thank all past and present members of the Federated Trust research group at the CS department of the University of Virginia for all their help formulating, refining, and documenting my ideas, particularly Paul Bui, Joe Calandrino, Xiaohui Chen, Jim Van Dyke, James Hu, Ryan Kurtz, Zhengping Wu, and my advisor Alfred Weaver.

8. REFERENCES[1] Health Insurance Portability and Accountability Act of

1996. Public Law 104-191, 104th Congress, August 16, 1996. http://aspe.hhs.gov/admnsimp/pl104191.htm.

[2] OASIS. XACML 2.0 Core: eXtensible Access Control Markup Language (XACML) Version 2.0. XACML 2.0 OASIS Standard Specification Set. February 2005.http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf.

[3] OASIS. Core and hierarchical role based access control (RBAC) profile of XACML v2.0. XACML 2.0 OASIS Standard Specification Set. February 2005.http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf.

[4] Ferraiolo, D., Cugini, J., and Kuhn, D. R. Role-based access control (RBAC): features and Motivations. In Proceedings of 11th Annual Computer Security Application Conference. New Orleans, LA, December 11–15 1995.

[5] Sandhu, R., Coyne, E., Feinstein, H., and Youman, C. Role-based access control model. IEEE Computer 29, February 2, 1996.

[6] Gasser M. and McDermott, E. An Architecture for Practical Delegation in a Distributed System. IEEE Computer Society Symposium on Research in Security and Privacy. Oakland, CA, May 7–9, 1990.

[7] Abadi, M., Burrow, M. Lampson, B., and Plotkin, G. A Calculus for Access Control in Distributed Systems. ACM Transactions on Programming Language and Systems 15. September 4, 1993, 706–734.

[8] Nagaratnam, N., and Lea, D. Secure Delegation for Distributed Object Environments, USENIX Conference on Object Oriented Technologies and Systems. April, 1998.

[9] Sandhu, R., Bhamidipati, V., and Munawer, O. The ARBAC97 Model for Role-Based Administration of Roles. ACM Transactions on Information and System Security 2. February 1, 1999, 105–135.

[10] Cheh Goh and Adrian Baldwin. Towards a More Complete Model of Role. In Proceedings of the third ACM workshop on Role-based access control. 1998, 55-62.

[11] Aura, T. Distributed Access-Rights Management with Delegation Certificates. Secure Internet Programming. Berlin, 1999, 211–235.

[12] Barka, E., and Sandhu, R. Framework for Role-Based Delegation Models. In Proceedings of 16th Annual Computer Security Application Conference (ACSAC200). December, 2000.

[13] Blaze, M., Feigenbaum, J., and Lacy, J. Decentralized Trust Management. In Proceedings of the 1996 IEEE Symposium on Security and Privacy, May 1996, pages 164–173.

[14] Blaze, M., Feigenbaum, J., and Keromytis, A. D. KeyNote: Trust Management for Public-Key Infrastructures. In Proceedings of Security Protocols International Workshop, 1998.

[15] Clarke D., Elien, J., Ellison, C., Fredette, M., Morcos, A., and Rivest, R. L. Certificate chain discovery in SPKI/SDSI. Master 's thesis, Massachusetts Institute of Technology, 2001.

[16] Barka, E. and Sandhu, R. A Role-Based Delegation Model and Some Extensions. In Proceedings of 16th Annual Computer Security Application Conference, New Orleans, December, 2000.

[17] Zhang, L., Ahn, G., and Chu, B. A Rule-Based Framework for Role-Based Delegation. In Proceedings of the 6th ACM Symposium on Access Control Models and Technologies (SACMAT 2001). May, 2002.

[18] Zhang, X., Oh, S., and Sandhu, R. PBDM: A Flexible Delegation Model in RBAC. In Proceedings of the 8th ACM Symposium on Access Control Models and Technologies (SACMAT 2003). Como, Ilaly, June 2-3, 2003.

[19] Ye, C., Fu, Y., and Wu, Z. 2004. An attribute-based-delegation-model. In Proceedings of the 3rd international Conference on information Security (Shanghai, China, November 14 - 16, 2004). InfoSecu '04, vol. 85. ACM Press, New York, NY, 220-221.

[20] Zhang, L., Ahn, G., and Chu, B. 2002. A role-based delegation framework for healthcare information systems. In Proceedings of the Seventh ACM Symposium on Access Control Models and Technologies (Monterey, California, USA, June 03 - 04, 2002). SACMAT '02. ACM Press, New York, NY, 125-134.

[21] Wilikens, M., Feriti, S., Sanna, A., and Masera, M. 2002. A context-related authorization and access control method based on RBAC:. In Proceedings of the Seventh ACM Symposium on Access Control Models and Technologies (Monterey, California, USA, June 03 - 04, 2002). SACMAT '02. ACM Press, New York, NY, 117-124.