Automatic Enforcement of Access Control Policies ... - Semantic Scholar
Automatic Enforcement of Access Control Policies among Dynamic Coalitions1 Vijayalakshmi Atluri and Janice Warner MSIS Department and CIMIC, Rutgers University, USA {atluri,janice}@cimic.rutgers.edu
Abstract. The need to securely share information on an ad-hoc basis between collaborating entities is increasingly becoming important. We propose a coalition based access control model (CBAC), comprised of three layers: coalition, role and user-object. Our model enables translation of coalition level policies to implementation level access control in a manner similar to that of the layers of the TCP/IP protocol. We present a coalition policy translation protocol that allows the implementation level access control details to be piggybacked as the access control policy percolates to the coalition level, and similarly, as the coalition level policy trickles down to the implementation level. Under our approach, a user’s request to access an object belonging to another coalition entity is automatically translated by employing an approach that considers attributes associated with user credentials and objects. Our approach ensures that the individual access control policies of each coalition entity as well as the agreed-upon coalition policies for sharing are enforced.
1
Introduction
There is an increasing need by applications to access shared resources among different autonomous entities for the purposes of achieving a common objective. This is widespread in environments such as military, emergencies, government agency collaborations, and virtual enterprises. Such sharing is accomplished by forming coalitions (or alliances or collaborations). In most cases, these coalitions are dynamic in nature. They are formed in an ad-hoc manner and members may leave and new members may join. For example, in a natural disaster, a dynamic coalition of government agencies (e.g., FEMA, local police and fire departments), nongovernment organizations (e.g., Red Cross) and private organizations (e.g., Doctors without Borders, suppliers of emergency provisions) may be formed and need access to information from one another about victims, supplies, and logistics, etc. [PTD02a]. Similarly, domestic or international governmental coalitions may be put in place to share information between different agencies. For example, in a homeland security setting, a coalition between agencies may be created for the purpose of conducting comprehensive data mining. In the commercial world, companies often team up and form virtual enterprises to benefit from complementary skills and expertise. 1
This work is supported in part by the National Science Foundation under grant IIS-0306838.
2
Vijayalakshmi Atluri and Janice Warner
In these scenarios, the coalition members normally have internal access control policies in place. Secure sharing of data requires that the members be able to exercise fine-grained access control over the shared resources governed by their own security policies. Typically, when entities agree to share their information resources, the access control policies are agreed upon at the coalition level. These agreements are not at the implementation level, in the sense that they do not specify which specific users can access the data object. For example, an agreement between agencies A and B is not an access control policy stating “a user Alice of agency A can access the “immigration” file of agency B.” Therefore, enforcing these coalition-level security policies requires transforming them to implementation level. A trivial solution would be to form teams (workgroups) of employees at the corresponding levels of both agencies. However, such a straightforward solution is not viable or scalable, may result in delays and is not practical in case of dynamic coalitions. Current approaches to facilitate sharing include three basic mechanisms: (i) Users from one coalition entity are explicitly given permission to access resources from another coalition entity. This approach is administratively time consuming and requires explicit revocation after the coalition is disbanded or when a user is no longer affiliated with the coalition entity. (ii) A single access id is provided to all of the users of the coalition entity. While this simplifies administration, fine-grained access control is not possible. (iii) The resources are copied to the coalition entity that requires access to them. Updates are difficult and and this case may result in uncontrolled sharing. Moreover, all three approaches are not suitable for dynamic, adhoc coalitions and are only feasible among entities that have long-term partnerships. We propose a coalition-based access control model comprising of multiple layers - coalition, role and user-object layer. Our model enables translation of coalition level policies to implementation level access control in a manner similar to that of the TCP/IP protocol. We envision that such a framework will enable the implementation level details to be piggy-backed as the access control policy percolates to the coalition level, and similarly, as the coalition level policies trickles down to the implementation level. Our approach is based on the following three principles: 1. The existing access control mechanisms within each entity should remain intact. It would be naïve to expect that coalition members could and would change their internal access control systems. Therefore, middleware systems between the coalition partners are needed to negotiate and translate access. 2. A common access control model will best facilitate automation of policy decisions. Because Role Based Access Control (RBAC) is policy neutral and has been shown to be able to model a variety of access control mechanisms including discretionary and mandatory access control [JSSS01, OSM00], it is a good candidate to be used as a common model in our approach. 3. Administration of CBAC should be decentralized and remain in the hands of the resource owners. Resource owners can best understand the risks of unauthorized access and should make the decisions about control. Addressing the security issues in the area of dynamic coalitions is relatively new. Philips et al. [PTD02a] have described the dynamic coalition problem by providing several motivating scenarios in a defense and disaster recovery settings, and have developed a prototype that controls access to APIs and software artifacts [PTD02b]. Cohen et al. [CWTS02] have proposed a preliminary model that captures the entities
Automatic Enforcement of Access Control Policies among Dynamic Coalitions
3
involved in coalition resource sharing and identifies the interrelationships among them. [BB03, KGBK03] have addressed the issue of automating the negotiation of policy between coalition members in a dynamic coalition. However, none of the prior work in coalition based access control addresses the issue of automatic translation of coalition level policies to the implementation level policies, and vice versa. Our work can be viewed as complementary to the above work. This paper is organized as follows. Section 2 provides an overview of our CBAC model approach. Section 3 presents the required definitions. Section 4 details our approach. Section 5 summarizes our conclusions and describes future work.
2
Overview of Our Approach
We propose a formal framework that enables automatic translation of coalition-level security policies so that users from one coalition entity gain access to objects residing at another coalition entity. This is accomplished by translating coalition-level security policies to implementation level security policies and vice versa. Specifically our approach assumes that there exist three levels: coalition, role and user-object level. Imagine a scenario where entities A and B are part of a coalition. They have agreed to share some of their data objects. When users from A request access to the data of B, the access request at the user level needs first to be translated into an equivalent request compatible with access control policies at B. In order to accomplish this, we propose to translate the user-object level access request, say 〈user-object request〉, into role level so that when the request is sent to B, the role level at B is able to interpret it and decide whether to allow or deny it based on B’s internal security policies. To this effect, A appends the role segment to the user request, thereby forming 〈role segment 〈user-object request〉〉. At the coalition level, the request is augmented with the coalition segment: 〈coalition segment 〈role segment 〈user-object request〉〉〉. When B receives the request on the other end, the coalition level first interprets the coalition segment and sends 〈role segment 〈user-object request〉〉 to the role level at B. The role level interprets the role segment and sends the 〈user-object request〉 to the user-object level. The process resembles the layers of the TCP/IP protocol in terms of lower levels serving upper levels, as shown in Figure 1. We assume each user in a coalition possesses a finite set of credentials and they are assigned to appropriate roles based on their credentials. Under the RBAC model, roles represent organizational agents who perform certain job functions within the organization. Users in turn are assigned appropriate roles based on their qualifications. In this paper, we exploit the credential mechanism to help assign users to roles based on the credential attributes possessed by users. Unlike roles, credentials are characterized by a set of attributes, which allows one to specify permissions based on the user credentials that satisfy certain conditions. Therefore, a user may only be assigned to a certain role if they have the required credentials. We assume that every member of a dynamic coalition employs RBAC as the access control policy (if not, the policies are translated and represented in RBAC), and that there exists a universal set of credential types and object types. Suppose user u from agency B wishes to access an object o of agency A. According to A’s access
4
Vijayalakshmi Atluri and Janice Warner
Coalition Entity A
Coalition Entity B
〈 coalition segment 〈 role segment 〈 user-object request〉 〉 〉
Coalition Level 〈 role segment 〈 user-object request〉 〉
〈 user-object request 〉
Coalition Level
Role Level
Role Level
〈 role segment 〈 user-object request〉 〉
User-Object Level
User-Object Level
〈 user-object request 〉
Fig. 1. Illustration of Different Layers in the CBAC Model policy over o, only certain roles are allowed access and therefore, only the users who are assigned to these roles are allowed to access o. We compute the set of credentials (i.e. their attribute values) possessed by all these users at A. Taking a conservative approach, we assume these are the required set of credentials to access o. We allow a user u to access o, only if u’s credential attributes are equivalent or a superset of the set of required credential attributes. At B’s end, we take the most authoritative set of credentials attributes possessed by user u to present with a request for object o.
3
Preliminaries
We briefly present the necessary formalism required to describe our approach. Specifically, we define our models use of objects, credentials and the RBAC model. Objects: Each organizational entity maintains a set of objects, OBJS, that can be shared with other organizational entities within a coalition. Each object belongs to an object-type, organized in an object-type hierarchy. Definition 1 [Object-type] An object-type ot is a pair (ot_id, OA), where ot_id ∈ OT is a unique object-type identifier; and OA is the set of attributes associated with ot_id. Each oai ∈ OA is denoted by an attribute name. Definition 2 [Object] An object obj is a triple (ot_id, obj_id, obj-attr-values), where ot_id ∈ OT, obj_id ∈ OBJS, obj-attr-values = (oa :v1, ..., oa: vn), where {oa1, .. oan } ⊆ OA(ot). OA(ot) denotes the set of attributes associated with ot. We use obj(obj_id), obj(ot_id) and obj(obj-attr-values) to denote the object id, the object-type id, and the set of attribute values of the object obj, respectively. The set of object attributes describe the objects such as keywords or concepts. The RBAC Model: In our work, we adopt the NIST standard of the RBAC model [FERR01]. For the sake of simplicity, we do not consider sessions or separation of duties constraints. Definition 3 [RBAC] • U, ROLES, OPS, and OBJS are the set of users, roles, operations, and objects.
Automatic Enforcement of Access Control Policies among Dynamic Coalitions
5
• • • • • •
UA ⊆ U × ROLES, a many-to-many mapping user-to-role assignment relation. PRMS, (the set of permission) ⊆ {(op, obj) | op ∈ OPS and obj ∈ OBJS} PA ⊆ PRMS×ROLES, a many-to-many mapping of permission-to-role assignments. assigned-users(r) = {u ∈ U | (u, r) ∈ UA}, the mapping of role r onto a set of users. assigned-roles(u) = { r ∈ ROLES | (u, r) ∈ UA}. assigned-permissions(r) = { p ∈ PRMS | (p, r) ∈PA}, the mapping of role r onto a set of permissions. • assigned-objects(r, p) → {obj ⊆ OBJS}, the permission-to-object mapping, which gives the set of objects associated with permission p for a given role. Formally, assigned-objects(r, p) = {obj ∈ OBJS | p = (op,obj)}. • RH ⊆ ROLES × ROLES is a partial order on ROLES, called the role hierarchy. Due to the role hierarchy, there exists an inheritance relation, written as ≥ where r1 ≥ r2 only if all permissions of r2 are also permissions of r1, and all users of r1 are also users of r2. Formally: (r1 ≥ r2) ⇒ assigned-permissions(r2) ⊆ assigned-permissions(r1) Λ assigned-users(r1)⊆assigned-users(r2). We assume that a comparison between roles can always be made. Parallel, incomparable role hierarchies are not allowed. Credentials: We assume that each subject is associated with one or more credentials. Credentials are assigned when a user is created and are updated according to the profile of the user. To make the task of credential specifications easier, credentials with similar structures are grouped into credential-types. Credential-types are typically organized as credential-type hierarchy. We denote the set of credential-type identifiers with CT, the set of credential identifiers with CI, and the set of user identifiers with U. A credential-type can be formally defined as follows. Definition 4 [Credential-type] A credential-type ct is a pair (ct_id, A), where ct_id ∈ CT is a unique identifier and A is the set of attributes belonging to ct_id. Each ai ∈ A has an attribute name and A(ct) is the set of attributes belonging to ct. Example 1: The credential type “doctor” can be (doctor, {affiliation, specialty}). Definition 5 [Credential] A credential c, an instance of a credential-type ct, is a 4tuple (ct_id, c_id, user_id, user-profile), where ct_id ∈ CT, c_id ∈ CI, user-id ∈ U and user-profile = (a1 : v1, …., an : vn), where {a1, .. an} ⊆ A(ct). The set of credentials associated with users in the system is denoted by the credential base (CB). We use c(c_id), c(user-id), c(ct_id) and c(user-profile) to denote the credential id of c, the user to which c is assigned, the credential type id of c and the set of attribute values of the user u (the user profile) for c, respectively. Example 2: An example of a credential for credential type “doctor” is as follows: (doctor, c-1, Roberts, (affiliation: Doctors without Borders, Specialty: immunology)) The attribute values of the credentials can be specified similarly to attribute certificates. Such certificates can be issued to users within coalition entities.
6
4
Vijayalakshmi Atluri and Janice Warner
Coalition Based Access Control (CBAC) Model
In this section, we present the proposed CBAC model, the coalition policy translation protocol, and an example that illustrates the working of our protocol. Definition 6: [coalition] A coalition C, is a tuple (coalition_id, E) where coalition_id is a unique identifier of a coalition and E = {e1, e2, …} is a set of coalition entities that have unique identifiers, entity_ids. Example 3: In a natural disaster, the International Red Cross is often on site providing shelter, food and protection to displaced persons. Doctors without Borders may provide services to combat the spread of infectious diseases. The two organizations could benefit from a coalition system that allows them to access each other’s information in a secure manner. Throughout this paper we will expand on an instance of this example where both organizations respond to an emergency in Turkey. In our example, Doctors without Borders has noticed a large number of infected wounds and wants to determine whether the problem is localized and if so, the source of the infection. Thus they enter a coalition agreement to obtain the necessary data from the Red Cross. Treatment case records from the emergency in Turkey and prior information on diseases or injuries in Turkey are to be shared. Coalition level policy specification: This is a high level agreement between the members of the coalition on the types of objects they will share. We assume the objects of one coalition member, called the source_entity, are shared with another coalition member, the destination_entity. A coalition level policy p is stated as follows: p = (coalition_id, source_entity_id, destination_entity_id, source_object_type). A coalition_id is a unique identifier for the coalition, source_entity_id is a unique identifier for the coalition member who will share its data objects, destination_entity_id is a unique identifier for the coalition member who is granted access to the objects belonging to the source entity and source_object_type is the set of object types that can be shared. We use p.coalition_id, p.destination_entity_id, p.source_entity_id, and p.source_object_type to identify these parameters of policy p. The specification of object types in the coalition policy, as opposed to object ids, allows the policy to be stated at a more abstract level, facilitating the dynamic addition of new objects without having to change the coalition level policy specification. Example 4: In our example, the International Red Cross has agreed to provide access to its emergency response information system as it applies to the earthquake emergency in Turkey. The agreed upon high-level coalition policy among these two coalition members can be specified as follows: Coalition level policy, p1: (Turkey0704, RedCross, Drs_wo_Borders, {Concept: Location = “Turkey”}) Definitions that follow are required for our policy translation protocol. Note that, unlike prior approaches, users are not mapped to a specific role at the source entity. Instead, their credential attributes are matched with those required to access an object. Definition 7 [assigned-user-credentials] Given a user u and a credential base CB, the set of credentials assigned to a user are assigned-credentials(u) = {c ∈ C | c(user-id) = u}.
Automatic Enforcement of Access Control Policies among Dynamic Coalitions
7
Definition 8 [assigned-role-credentials] Given a role r and a set of users U, we define the set of credentials assigned to a role r, assigned-credentials(r) = ∪{assignedcredentials(u) | u ∈ assigned_users(r)}. Definition 9 [assigned-role-credential-attributes] Given a role r and a set of users U, we define the set of credential attributes assigned to a role r, assigned-credentialattributes(r) = ∪ {c(user-profile) | c ∈ assigned- credentials(r)}. Definition 10 [required-object-credentials] Given a role r, an object obj and a set of permission-role assignments PA, we define the set of required credentials to access an object obj, required-credentials(obj) = ∪{assigned-credentials(r) | obj ∈ assignedobjects(r, p) Λ (p, r)∈ PA}. Definition 11 [required-object-credential-attributes] Given a role r, an object obj and a set of users U, the set of credential attributes required to access an object obj is, required-credential-attributes(obj) = ∪{c(user-profile) | c ∈ requiredcredentials(obj)}. The policy translation protocol uses coalition segment, role segment and user-object segment in its request/response messages. The format of these segments are: coalition segment: 〈coalition_id, source_entity_id, destination_entity_id〉 role segment: 〈assigned-credential-attributes(r)〉 user-object segment: 〈user_id, object〉, where object can either be obj_id or ot_id. Algorithm[Coalition Policy Translation Protocol] Object Request: Input: user-object request (user_id, object_type) request_object(destination_user_id, source_object_type){ if user_id ∈ U, {destination-role-id-set ← assigned-roles(destination-user-id) RA ← assigned-credential-attributes(destination-role-id)such that destination-role-id ∈ destination-role-id-set; if (there exists a policy p such that object_type ∈ p.source_object_type) request_message ← 〈p.coalition_id, p.source_entity_id, p.destination_entity_id, 〈RA 〈user_id, p.source_object_type〉〉} else return error message “Invalid user”} Response: Input: request_message respond_object (source_entity_id, destination_entity_id, source_object){ if there exists a policy p′ such that (p.source_object_type ∈ p′.source_object_type) Λ (p.destination_entity_id = p′.destination_entity_id) for every obj such that p.source_object_type ∈ obj(obj-attrvalues) if RA ⊇ required-credential-attributes(obj) allow access to obj by destination_user_id} else return_error_message(“No credential match”)} else return_error_message(“Invalid request”)}
8
Vijayalakshmi Atluri and Janice Warner
In the following, we present the detailed steps of the protocol: Step 1: At the destination coalition entity, a user requests an object by specifying the user-object segment: 〈destination_user_id, source_object〉. The user-object segment identifies the requesting user and the requested object or set of objects. Step 2: The user-object segment is mapped at the role level to a role and the user_id is removed from the user-object segment. If the user is a member of more than one role, the highest level role in the hierarchy is selected. The role segment is comprised of the credential attributes associated with the assigned-role. The resulting message is: 〈assigned-credential-attributes(destination-role-id) 〈 source-object〉〉. Step 3: The combined role and user-object segments are sent to the coalition level. The request is mapped to a coalition instance. Then the coalition layer determines which coalition member shares the specified object type, appends the coalition segment to the request and delivers it to the appropriate coalition member. The coalition message is: 〈coalition_id, source_entity_id, destination_entity 〈assignedcredential-attributes(destination-role-id) 〈source-object〉〉〉. Step 4: The message is sent to the source coalition entity which validates it. Step 5: The role level at the source coalition entity examines the credential attributes specified in the role segment and tests if (assigned-credentialattributes(destination_role_id) ⊇ required- credential-attributes(source-object). Step 6. If the above condition is satisfied, then access is granted to the objects associated with the source object id. A system architecture for the CBAC system consists of a Coalition Control System (CCS) and an RBAC module. The CCS is the key component. It accomplishes the translation of coalition policies and controls external access to internal resources by entity members at other coalition member sites. It has three sub-components – coalition level policy interpreter, role interpreter, and user-object access controller. Although the example given in this paper is for the simplest case of two entities involved in a coalition, the approach is applicable to coalitions or partnerships with multiple entities. When there are multiple entities, we assume that there exists a coalition level policy instance among each pair of coalition entities. As a result, a pair-wise handshaking is required to enforce the agreed upon policy. This is recommended because: (i) it allows the coalition members to provide different levels of access to different partners based on level-of-trust. (ii) It facilitates the members to join and leave a coalition, without having to dissolve a coalition. Example 5: Dr. Roberts, a member of Doctors Without Borders, wishes to access data on infectious diseases in the area of the earthquake maintained by the International Red Cross. Figure 2 illustrates the steps described below: 1. He sends a request to his organizational system, which is handled by its coalition control system. The access request is in the form: 〈user-object segment〉 = 〈roberts, (concept: infectious diseases, location = Turkey)〉. The user-object access controller validates Dr. Roberts and passes the request to the role interpreter. 2. The role interpreter selects the role played by Roberts, doctor, and retrieves the credentials associated with this role_id by computing the assigned-credentialattributes(doctor). The retrieved credential is of type medical-doctor and has the attributes affiliation and specialty. It appends the role segment to the user-object
Automatic Enforcement of Access Control Policies among Dynamic Coalitions
3.
4. 5.
6.
9
segment: 〈medical-doctor, (affiliation: Doctors without Borders, specialty: immunology) 〈roberts, (concept: infectious diseases, location = Turkey)〉〉 and passes it to the coalition level policy interpreter. The coalition level policy interpreter determines the appropriate coalition and coalition member for the requested object based on the object-type, and appends the coalition segment to the role and object segments: 〈Turkey-0704, RedCross, Doctors without Borders, 〈medical-doctor, (affiliation: Doctors without Borders, specialty: immunology) 〈roberts, (concept: infectious diseases, location = Turkey)〉〉〉. The message is then passed to the International Red Cross system. The Red Cross system validates the destination member and coalition id. It passes the valid request to its role interpreter after removing the coalition level segment. The role-interpreter at this end attempts to test if someone with the received credential attributes could access objects of the specified types. It identifies the objects and computes the required-credential-attributes(obj) such that (concept: infectious diseases, location = Turkey ∈ obj(obj-attr-values). If assignedcredential-attributes(medical-doctor) ⊇ required-credential-attributes(obj), the set of objects are then passed to the user-object access controller: 〈517,730〉. The user-object access controller retrieves the objects and makes them available to Dr. Roberts. Doctors Without Borders
International Red Cross >
Coalition-level Policy interpreter
3
<doctor, ( location: Turkey, specialty: immunology) >
Coalition-level Policy interpreter 4 <doctor, ( location: Turkey, specialty: immunology) >
2 Role Interpreter
Role Interpreter
5
1 Dr. Roberts
User-Object Access Controller
6 User-Object Access Controller
Fig. 2. The Different Steps of Object Request and Response
5
Conclusions and Future Research
In this paper, we have proposed a coalition-based access control model (CBAC) comprising of multiple layers – coalition, role, and user-object (or implementation) layer. Our model enables translation of coalition level policies to implementation level access control in a manner similar to that performed by the layers in the TCP/IP network protocol. The CBAC framework described in this paper allows for dynamic, ad-hoc formations of information sharing systems for coalitions that share objects based on object attributes and credential attributes.
10
Vijayalakshmi Atluri and Janice Warner
We plan to undertake several research tasks in this area. (1) We have assumed that objects are owned by only one member of the coalition. However, there may be the need to have object ownership shared by several entities. We intend to extend our approach to facilitate such cooperative environments similar the work on cooperative role-based administration in [WL03]. (2) We have assumed that coalition member entities agree on high-level policies before there is any flow of information, making the coalition formation not completely ad-hoc. We plan to extend our approach to allow organizational entities to publish their policies and services. Coalitions could then be formed based on the compatibility and adherence to the published policies. (3) We have not considered static and dynamic separation of duties constraints and plan to extend our CBAC model to incorporate these constraints as well. Moreover, delegation is an important feature, which must be supported in coalition-based systems [FPPKK02]; and we intend to include this support as well. (4) We intend to implement our approach using the OASIS XACML specification, XML specification of attribute certificates, and registry service similar to that of UDDI registry.
6
References
[BB03] V. Bharadwaj and J. Baras, "A Framework for Automated Negotiation of Access Control Policies", Proceedings of DISCEX III, 2003. [CWTS02] E. Cohen, W. Winsborough, R. Thomas and D. Shands, “Models for Coalition-based Access Control (CBAC), SACMAT 2002, Monterey, CA. [FERR01] D. Ferraiolo, R. Sandhu, S. Gavrila, D. Kuhn, and R. Chandramouli, Proposed NIST Standard for Role-Based Access Control, TISSEC, August 2001. [FPPKK02] P. Freudenthal, K. Pesin, Keenan, Port, & Karamcheti, “dRBAC: Distributed Role-Based Access Control for Dynamic Coalition Environments”, (ICDCS), July 2002. [JSSS01] S. Jajodia, P. Samarati, S. Pierangela, L. Maria, and V. S. Subrahmanian, ``Flexible support for multiple access control policies,'' ACM TODs, June 2001. [KGBK03] H. Khurana, S. Gavrila, R. Bobba, R. Koleva, A. Sonalker, E. Dinu, V. Gligor and J. Baras, "Integrated Security Services for Dynamic Coalitions " Proc. of the DISCEX III, 2003. [KH02] Kuo and Humenn, “Dynamically Authorized RBAC for Secure Distributed Computation”, ACM Workshop for XML Security, November, 2002 [OSM00] S. Osborn, R. Sandhu and Q. Munawer, “Configuring RBAC to Enforce Mandatory and DAC Policies, ACM TISSEC, May 2000. [PTD02a] C. Philips, T.C. Ting, and S. Demurjian, “Information Sharing and Security in Dynamic Coalitions”, SACMAT 2002. [PTD02b] C. Philips, E. Charles, T. Ting, and S. Demurjian, “Towards Information Assurance in Dynamic Coalitions”, IEEE IAW, USMA, February 2002 [WL03] H. F. Wedde and M. Lischka, “Cooperative Role-Based Administration”, SACMAT 2003.
Abstract. The need to securely share information on an ad-hoc basis between collaborating entities is increasingly becoming important. We propose a coalition based access control model (CBAC), comprised of three layers: coalition, role and user-object. Our model enables translation of coalition level policies to implementation level access control in a manner similar to that of the layers of the TCP/IP protocol. We present a coalition policy translation protocol that allows the implementation level access control details to be piggybacked as the access control policy percolates to the coalition level, and similarly, as the coalition level policy trickles down to the implementation level. Under our approach, a user’s request to access an object belonging to another coalition entity is automatically translated by employing an approach that considers attributes associated with user credentials and objects. Our approach ensures that the individual access control policies of each coalition entity as well as the agreed-upon coalition policies for sharing are enforced.
1
Introduction
There is an increasing need by applications to access shared resources among different autonomous entities for the purposes of achieving a common objective. This is widespread in environments such as military, emergencies, government agency collaborations, and virtual enterprises. Such sharing is accomplished by forming coalitions (or alliances or collaborations). In most cases, these coalitions are dynamic in nature. They are formed in an ad-hoc manner and members may leave and new members may join. For example, in a natural disaster, a dynamic coalition of government agencies (e.g., FEMA, local police and fire departments), nongovernment organizations (e.g., Red Cross) and private organizations (e.g., Doctors without Borders, suppliers of emergency provisions) may be formed and need access to information from one another about victims, supplies, and logistics, etc. [PTD02a]. Similarly, domestic or international governmental coalitions may be put in place to share information between different agencies. For example, in a homeland security setting, a coalition between agencies may be created for the purpose of conducting comprehensive data mining. In the commercial world, companies often team up and form virtual enterprises to benefit from complementary skills and expertise. 1
This work is supported in part by the National Science Foundation under grant IIS-0306838.
2
Vijayalakshmi Atluri and Janice Warner
In these scenarios, the coalition members normally have internal access control policies in place. Secure sharing of data requires that the members be able to exercise fine-grained access control over the shared resources governed by their own security policies. Typically, when entities agree to share their information resources, the access control policies are agreed upon at the coalition level. These agreements are not at the implementation level, in the sense that they do not specify which specific users can access the data object. For example, an agreement between agencies A and B is not an access control policy stating “a user Alice of agency A can access the “immigration” file of agency B.” Therefore, enforcing these coalition-level security policies requires transforming them to implementation level. A trivial solution would be to form teams (workgroups) of employees at the corresponding levels of both agencies. However, such a straightforward solution is not viable or scalable, may result in delays and is not practical in case of dynamic coalitions. Current approaches to facilitate sharing include three basic mechanisms: (i) Users from one coalition entity are explicitly given permission to access resources from another coalition entity. This approach is administratively time consuming and requires explicit revocation after the coalition is disbanded or when a user is no longer affiliated with the coalition entity. (ii) A single access id is provided to all of the users of the coalition entity. While this simplifies administration, fine-grained access control is not possible. (iii) The resources are copied to the coalition entity that requires access to them. Updates are difficult and and this case may result in uncontrolled sharing. Moreover, all three approaches are not suitable for dynamic, adhoc coalitions and are only feasible among entities that have long-term partnerships. We propose a coalition-based access control model comprising of multiple layers - coalition, role and user-object layer. Our model enables translation of coalition level policies to implementation level access control in a manner similar to that of the TCP/IP protocol. We envision that such a framework will enable the implementation level details to be piggy-backed as the access control policy percolates to the coalition level, and similarly, as the coalition level policies trickles down to the implementation level. Our approach is based on the following three principles: 1. The existing access control mechanisms within each entity should remain intact. It would be naïve to expect that coalition members could and would change their internal access control systems. Therefore, middleware systems between the coalition partners are needed to negotiate and translate access. 2. A common access control model will best facilitate automation of policy decisions. Because Role Based Access Control (RBAC) is policy neutral and has been shown to be able to model a variety of access control mechanisms including discretionary and mandatory access control [JSSS01, OSM00], it is a good candidate to be used as a common model in our approach. 3. Administration of CBAC should be decentralized and remain in the hands of the resource owners. Resource owners can best understand the risks of unauthorized access and should make the decisions about control. Addressing the security issues in the area of dynamic coalitions is relatively new. Philips et al. [PTD02a] have described the dynamic coalition problem by providing several motivating scenarios in a defense and disaster recovery settings, and have developed a prototype that controls access to APIs and software artifacts [PTD02b]. Cohen et al. [CWTS02] have proposed a preliminary model that captures the entities
Automatic Enforcement of Access Control Policies among Dynamic Coalitions
3
involved in coalition resource sharing and identifies the interrelationships among them. [BB03, KGBK03] have addressed the issue of automating the negotiation of policy between coalition members in a dynamic coalition. However, none of the prior work in coalition based access control addresses the issue of automatic translation of coalition level policies to the implementation level policies, and vice versa. Our work can be viewed as complementary to the above work. This paper is organized as follows. Section 2 provides an overview of our CBAC model approach. Section 3 presents the required definitions. Section 4 details our approach. Section 5 summarizes our conclusions and describes future work.
2
Overview of Our Approach
We propose a formal framework that enables automatic translation of coalition-level security policies so that users from one coalition entity gain access to objects residing at another coalition entity. This is accomplished by translating coalition-level security policies to implementation level security policies and vice versa. Specifically our approach assumes that there exist three levels: coalition, role and user-object level. Imagine a scenario where entities A and B are part of a coalition. They have agreed to share some of their data objects. When users from A request access to the data of B, the access request at the user level needs first to be translated into an equivalent request compatible with access control policies at B. In order to accomplish this, we propose to translate the user-object level access request, say 〈user-object request〉, into role level so that when the request is sent to B, the role level at B is able to interpret it and decide whether to allow or deny it based on B’s internal security policies. To this effect, A appends the role segment to the user request, thereby forming 〈role segment 〈user-object request〉〉. At the coalition level, the request is augmented with the coalition segment: 〈coalition segment 〈role segment 〈user-object request〉〉〉. When B receives the request on the other end, the coalition level first interprets the coalition segment and sends 〈role segment 〈user-object request〉〉 to the role level at B. The role level interprets the role segment and sends the 〈user-object request〉 to the user-object level. The process resembles the layers of the TCP/IP protocol in terms of lower levels serving upper levels, as shown in Figure 1. We assume each user in a coalition possesses a finite set of credentials and they are assigned to appropriate roles based on their credentials. Under the RBAC model, roles represent organizational agents who perform certain job functions within the organization. Users in turn are assigned appropriate roles based on their qualifications. In this paper, we exploit the credential mechanism to help assign users to roles based on the credential attributes possessed by users. Unlike roles, credentials are characterized by a set of attributes, which allows one to specify permissions based on the user credentials that satisfy certain conditions. Therefore, a user may only be assigned to a certain role if they have the required credentials. We assume that every member of a dynamic coalition employs RBAC as the access control policy (if not, the policies are translated and represented in RBAC), and that there exists a universal set of credential types and object types. Suppose user u from agency B wishes to access an object o of agency A. According to A’s access
4
Vijayalakshmi Atluri and Janice Warner
Coalition Entity A
Coalition Entity B
〈 coalition segment 〈 role segment 〈 user-object request〉 〉 〉
Coalition Level 〈 role segment 〈 user-object request〉 〉
〈 user-object request 〉
Coalition Level
Role Level
Role Level
〈 role segment 〈 user-object request〉 〉
User-Object Level
User-Object Level
〈 user-object request 〉
Fig. 1. Illustration of Different Layers in the CBAC Model policy over o, only certain roles are allowed access and therefore, only the users who are assigned to these roles are allowed to access o. We compute the set of credentials (i.e. their attribute values) possessed by all these users at A. Taking a conservative approach, we assume these are the required set of credentials to access o. We allow a user u to access o, only if u’s credential attributes are equivalent or a superset of the set of required credential attributes. At B’s end, we take the most authoritative set of credentials attributes possessed by user u to present with a request for object o.
3
Preliminaries
We briefly present the necessary formalism required to describe our approach. Specifically, we define our models use of objects, credentials and the RBAC model. Objects: Each organizational entity maintains a set of objects, OBJS, that can be shared with other organizational entities within a coalition. Each object belongs to an object-type, organized in an object-type hierarchy. Definition 1 [Object-type] An object-type ot is a pair (ot_id, OA), where ot_id ∈ OT is a unique object-type identifier; and OA is the set of attributes associated with ot_id. Each oai ∈ OA is denoted by an attribute name. Definition 2 [Object] An object obj is a triple (ot_id, obj_id, obj-attr-values), where ot_id ∈ OT, obj_id ∈ OBJS, obj-attr-values = (oa :v1, ..., oa: vn), where {oa1, .. oan } ⊆ OA(ot). OA(ot) denotes the set of attributes associated with ot. We use obj(obj_id), obj(ot_id) and obj(obj-attr-values) to denote the object id, the object-type id, and the set of attribute values of the object obj, respectively. The set of object attributes describe the objects such as keywords or concepts. The RBAC Model: In our work, we adopt the NIST standard of the RBAC model [FERR01]. For the sake of simplicity, we do not consider sessions or separation of duties constraints. Definition 3 [RBAC] • U, ROLES, OPS, and OBJS are the set of users, roles, operations, and objects.
Automatic Enforcement of Access Control Policies among Dynamic Coalitions
5
• • • • • •
UA ⊆ U × ROLES, a many-to-many mapping user-to-role assignment relation. PRMS, (the set of permission) ⊆ {(op, obj) | op ∈ OPS and obj ∈ OBJS} PA ⊆ PRMS×ROLES, a many-to-many mapping of permission-to-role assignments. assigned-users(r) = {u ∈ U | (u, r) ∈ UA}, the mapping of role r onto a set of users. assigned-roles(u) = { r ∈ ROLES | (u, r) ∈ UA}. assigned-permissions(r) = { p ∈ PRMS | (p, r) ∈PA}, the mapping of role r onto a set of permissions. • assigned-objects(r, p) → {obj ⊆ OBJS}, the permission-to-object mapping, which gives the set of objects associated with permission p for a given role. Formally, assigned-objects(r, p) = {obj ∈ OBJS | p = (op,obj)}. • RH ⊆ ROLES × ROLES is a partial order on ROLES, called the role hierarchy. Due to the role hierarchy, there exists an inheritance relation, written as ≥ where r1 ≥ r2 only if all permissions of r2 are also permissions of r1, and all users of r1 are also users of r2. Formally: (r1 ≥ r2) ⇒ assigned-permissions(r2) ⊆ assigned-permissions(r1) Λ assigned-users(r1)⊆assigned-users(r2). We assume that a comparison between roles can always be made. Parallel, incomparable role hierarchies are not allowed. Credentials: We assume that each subject is associated with one or more credentials. Credentials are assigned when a user is created and are updated according to the profile of the user. To make the task of credential specifications easier, credentials with similar structures are grouped into credential-types. Credential-types are typically organized as credential-type hierarchy. We denote the set of credential-type identifiers with CT, the set of credential identifiers with CI, and the set of user identifiers with U. A credential-type can be formally defined as follows. Definition 4 [Credential-type] A credential-type ct is a pair (ct_id, A), where ct_id ∈ CT is a unique identifier and A is the set of attributes belonging to ct_id. Each ai ∈ A has an attribute name and A(ct) is the set of attributes belonging to ct. Example 1: The credential type “doctor” can be (doctor, {affiliation, specialty}). Definition 5 [Credential] A credential c, an instance of a credential-type ct, is a 4tuple (ct_id, c_id, user_id, user-profile), where ct_id ∈ CT, c_id ∈ CI, user-id ∈ U and user-profile = (a1 : v1, …., an : vn), where {a1, .. an} ⊆ A(ct). The set of credentials associated with users in the system is denoted by the credential base (CB). We use c(c_id), c(user-id), c(ct_id) and c(user-profile) to denote the credential id of c, the user to which c is assigned, the credential type id of c and the set of attribute values of the user u (the user profile) for c, respectively. Example 2: An example of a credential for credential type “doctor” is as follows: (doctor, c-1, Roberts, (affiliation: Doctors without Borders, Specialty: immunology)) The attribute values of the credentials can be specified similarly to attribute certificates. Such certificates can be issued to users within coalition entities.
6
4
Vijayalakshmi Atluri and Janice Warner
Coalition Based Access Control (CBAC) Model
In this section, we present the proposed CBAC model, the coalition policy translation protocol, and an example that illustrates the working of our protocol. Definition 6: [coalition] A coalition C, is a tuple (coalition_id, E) where coalition_id is a unique identifier of a coalition and E = {e1, e2, …} is a set of coalition entities that have unique identifiers, entity_ids. Example 3: In a natural disaster, the International Red Cross is often on site providing shelter, food and protection to displaced persons. Doctors without Borders may provide services to combat the spread of infectious diseases. The two organizations could benefit from a coalition system that allows them to access each other’s information in a secure manner. Throughout this paper we will expand on an instance of this example where both organizations respond to an emergency in Turkey. In our example, Doctors without Borders has noticed a large number of infected wounds and wants to determine whether the problem is localized and if so, the source of the infection. Thus they enter a coalition agreement to obtain the necessary data from the Red Cross. Treatment case records from the emergency in Turkey and prior information on diseases or injuries in Turkey are to be shared. Coalition level policy specification: This is a high level agreement between the members of the coalition on the types of objects they will share. We assume the objects of one coalition member, called the source_entity, are shared with another coalition member, the destination_entity. A coalition level policy p is stated as follows: p = (coalition_id, source_entity_id, destination_entity_id, source_object_type). A coalition_id is a unique identifier for the coalition, source_entity_id is a unique identifier for the coalition member who will share its data objects, destination_entity_id is a unique identifier for the coalition member who is granted access to the objects belonging to the source entity and source_object_type is the set of object types that can be shared. We use p.coalition_id, p.destination_entity_id, p.source_entity_id, and p.source_object_type to identify these parameters of policy p. The specification of object types in the coalition policy, as opposed to object ids, allows the policy to be stated at a more abstract level, facilitating the dynamic addition of new objects without having to change the coalition level policy specification. Example 4: In our example, the International Red Cross has agreed to provide access to its emergency response information system as it applies to the earthquake emergency in Turkey. The agreed upon high-level coalition policy among these two coalition members can be specified as follows: Coalition level policy, p1: (Turkey0704, RedCross, Drs_wo_Borders, {Concept: Location = “Turkey”}) Definitions that follow are required for our policy translation protocol. Note that, unlike prior approaches, users are not mapped to a specific role at the source entity. Instead, their credential attributes are matched with those required to access an object. Definition 7 [assigned-user-credentials] Given a user u and a credential base CB, the set of credentials assigned to a user are assigned-credentials(u) = {c ∈ C | c(user-id) = u}.
Automatic Enforcement of Access Control Policies among Dynamic Coalitions
7
Definition 8 [assigned-role-credentials] Given a role r and a set of users U, we define the set of credentials assigned to a role r, assigned-credentials(r) = ∪{assignedcredentials(u) | u ∈ assigned_users(r)}. Definition 9 [assigned-role-credential-attributes] Given a role r and a set of users U, we define the set of credential attributes assigned to a role r, assigned-credentialattributes(r) = ∪ {c(user-profile) | c ∈ assigned- credentials(r)}. Definition 10 [required-object-credentials] Given a role r, an object obj and a set of permission-role assignments PA, we define the set of required credentials to access an object obj, required-credentials(obj) = ∪{assigned-credentials(r) | obj ∈ assignedobjects(r, p) Λ (p, r)∈ PA}. Definition 11 [required-object-credential-attributes] Given a role r, an object obj and a set of users U, the set of credential attributes required to access an object obj is, required-credential-attributes(obj) = ∪{c(user-profile) | c ∈ requiredcredentials(obj)}. The policy translation protocol uses coalition segment, role segment and user-object segment in its request/response messages. The format of these segments are: coalition segment: 〈coalition_id, source_entity_id, destination_entity_id〉 role segment: 〈assigned-credential-attributes(r)〉 user-object segment: 〈user_id, object〉, where object can either be obj_id or ot_id. Algorithm[Coalition Policy Translation Protocol] Object Request: Input: user-object request (user_id, object_type) request_object(destination_user_id, source_object_type){ if user_id ∈ U, {destination-role-id-set ← assigned-roles(destination-user-id) RA ← assigned-credential-attributes(destination-role-id)such that destination-role-id ∈ destination-role-id-set; if (there exists a policy p such that object_type ∈ p.source_object_type) request_message ← 〈p.coalition_id, p.source_entity_id, p.destination_entity_id, 〈RA 〈user_id, p.source_object_type〉〉} else return error message “Invalid user”} Response: Input: request_message respond_object (source_entity_id, destination_entity_id, source_object){ if there exists a policy p′ such that (p.source_object_type ∈ p′.source_object_type) Λ (p.destination_entity_id = p′.destination_entity_id) for every obj such that p.source_object_type ∈ obj(obj-attrvalues) if RA ⊇ required-credential-attributes(obj) allow access to obj by destination_user_id} else return_error_message(“No credential match”)} else return_error_message(“Invalid request”)}
8
Vijayalakshmi Atluri and Janice Warner
In the following, we present the detailed steps of the protocol: Step 1: At the destination coalition entity, a user requests an object by specifying the user-object segment: 〈destination_user_id, source_object〉. The user-object segment identifies the requesting user and the requested object or set of objects. Step 2: The user-object segment is mapped at the role level to a role and the user_id is removed from the user-object segment. If the user is a member of more than one role, the highest level role in the hierarchy is selected. The role segment is comprised of the credential attributes associated with the assigned-role. The resulting message is: 〈assigned-credential-attributes(destination-role-id) 〈 source-object〉〉. Step 3: The combined role and user-object segments are sent to the coalition level. The request is mapped to a coalition instance. Then the coalition layer determines which coalition member shares the specified object type, appends the coalition segment to the request and delivers it to the appropriate coalition member. The coalition message is: 〈coalition_id, source_entity_id, destination_entity 〈assignedcredential-attributes(destination-role-id) 〈source-object〉〉〉. Step 4: The message is sent to the source coalition entity which validates it. Step 5: The role level at the source coalition entity examines the credential attributes specified in the role segment and tests if (assigned-credentialattributes(destination_role_id) ⊇ required- credential-attributes(source-object). Step 6. If the above condition is satisfied, then access is granted to the objects associated with the source object id. A system architecture for the CBAC system consists of a Coalition Control System (CCS) and an RBAC module. The CCS is the key component. It accomplishes the translation of coalition policies and controls external access to internal resources by entity members at other coalition member sites. It has three sub-components – coalition level policy interpreter, role interpreter, and user-object access controller. Although the example given in this paper is for the simplest case of two entities involved in a coalition, the approach is applicable to coalitions or partnerships with multiple entities. When there are multiple entities, we assume that there exists a coalition level policy instance among each pair of coalition entities. As a result, a pair-wise handshaking is required to enforce the agreed upon policy. This is recommended because: (i) it allows the coalition members to provide different levels of access to different partners based on level-of-trust. (ii) It facilitates the members to join and leave a coalition, without having to dissolve a coalition. Example 5: Dr. Roberts, a member of Doctors Without Borders, wishes to access data on infectious diseases in the area of the earthquake maintained by the International Red Cross. Figure 2 illustrates the steps described below: 1. He sends a request to his organizational system, which is handled by its coalition control system. The access request is in the form: 〈user-object segment〉 = 〈roberts, (concept: infectious diseases, location = Turkey)〉. The user-object access controller validates Dr. Roberts and passes the request to the role interpreter. 2. The role interpreter selects the role played by Roberts, doctor, and retrieves the credentials associated with this role_id by computing the assigned-credentialattributes(doctor). The retrieved credential is of type medical-doctor and has the attributes affiliation and specialty. It appends the role segment to the user-object
Automatic Enforcement of Access Control Policies among Dynamic Coalitions
3.
4. 5.
6.
9
segment: 〈medical-doctor, (affiliation: Doctors without Borders, specialty: immunology) 〈roberts, (concept: infectious diseases, location = Turkey)〉〉 and passes it to the coalition level policy interpreter. The coalition level policy interpreter determines the appropriate coalition and coalition member for the requested object based on the object-type, and appends the coalition segment to the role and object segments: 〈Turkey-0704, RedCross, Doctors without Borders, 〈medical-doctor, (affiliation: Doctors without Borders, specialty: immunology) 〈roberts, (concept: infectious diseases, location = Turkey)〉〉〉. The message is then passed to the International Red Cross system. The Red Cross system validates the destination member and coalition id. It passes the valid request to its role interpreter after removing the coalition level segment. The role-interpreter at this end attempts to test if someone with the received credential attributes could access objects of the specified types. It identifies the objects and computes the required-credential-attributes(obj) such that (concept: infectious diseases, location = Turkey ∈ obj(obj-attr-values). If assignedcredential-attributes(medical-doctor) ⊇ required-credential-attributes(obj), the set of objects are then passed to the user-object access controller: 〈517,730〉. The user-object access controller retrieves the objects and makes them available to Dr. Roberts. Doctors Without Borders
International Red Cross >
Coalition-level Policy interpreter
3
<doctor, ( location: Turkey, specialty: immunology) >
Coalition-level Policy interpreter 4 <doctor, ( location: Turkey, specialty: immunology) >
2 Role Interpreter
Role Interpreter
5
1 Dr. Roberts
User-Object Access Controller
6 User-Object Access Controller
Fig. 2. The Different Steps of Object Request and Response
5
Conclusions and Future Research
In this paper, we have proposed a coalition-based access control model (CBAC) comprising of multiple layers – coalition, role, and user-object (or implementation) layer. Our model enables translation of coalition level policies to implementation level access control in a manner similar to that performed by the layers in the TCP/IP network protocol. The CBAC framework described in this paper allows for dynamic, ad-hoc formations of information sharing systems for coalitions that share objects based on object attributes and credential attributes.
10
Vijayalakshmi Atluri and Janice Warner
We plan to undertake several research tasks in this area. (1) We have assumed that objects are owned by only one member of the coalition. However, there may be the need to have object ownership shared by several entities. We intend to extend our approach to facilitate such cooperative environments similar the work on cooperative role-based administration in [WL03]. (2) We have assumed that coalition member entities agree on high-level policies before there is any flow of information, making the coalition formation not completely ad-hoc. We plan to extend our approach to allow organizational entities to publish their policies and services. Coalitions could then be formed based on the compatibility and adherence to the published policies. (3) We have not considered static and dynamic separation of duties constraints and plan to extend our CBAC model to incorporate these constraints as well. Moreover, delegation is an important feature, which must be supported in coalition-based systems [FPPKK02]; and we intend to include this support as well. (4) We intend to implement our approach using the OASIS XACML specification, XML specification of attribute certificates, and registry service similar to that of UDDI registry.
6
References
[BB03] V. Bharadwaj and J. Baras, "A Framework for Automated Negotiation of Access Control Policies", Proceedings of DISCEX III, 2003. [CWTS02] E. Cohen, W. Winsborough, R. Thomas and D. Shands, “Models for Coalition-based Access Control (CBAC), SACMAT 2002, Monterey, CA. [FERR01] D. Ferraiolo, R. Sandhu, S. Gavrila, D. Kuhn, and R. Chandramouli, Proposed NIST Standard for Role-Based Access Control, TISSEC, August 2001. [FPPKK02] P. Freudenthal, K. Pesin, Keenan, Port, & Karamcheti, “dRBAC: Distributed Role-Based Access Control for Dynamic Coalition Environments”, (ICDCS), July 2002. [JSSS01] S. Jajodia, P. Samarati, S. Pierangela, L. Maria, and V. S. Subrahmanian, ``Flexible support for multiple access control policies,'' ACM TODs, June 2001. [KGBK03] H. Khurana, S. Gavrila, R. Bobba, R. Koleva, A. Sonalker, E. Dinu, V. Gligor and J. Baras, "Integrated Security Services for Dynamic Coalitions " Proc. of the DISCEX III, 2003. [KH02] Kuo and Humenn, “Dynamically Authorized RBAC for Secure Distributed Computation”, ACM Workshop for XML Security, November, 2002 [OSM00] S. Osborn, R. Sandhu and Q. Munawer, “Configuring RBAC to Enforce Mandatory and DAC Policies, ACM TISSEC, May 2000. [PTD02a] C. Philips, T.C. Ting, and S. Demurjian, “Information Sharing and Security in Dynamic Coalitions”, SACMAT 2002. [PTD02b] C. Philips, E. Charles, T. Ting, and S. Demurjian, “Towards Information Assurance in Dynamic Coalitions”, IEEE IAW, USMA, February 2002 [WL03] H. F. Wedde and M. Lischka, “Cooperative Role-Based Administration”, SACMAT 2003.
