Trusted Database Interoperation Based on Collaborative Role-Based Access Control

Transcription

1 All rights are reserved and copyright of this manuscript belongs to the authors. This manuscript has been published without reviewing and editing as received from the authors: posting the manuscript to SCIS 2006 does not prevent future submissions to any journals or conferences with proceedings. SCIS 2006 The 2006 Symposium on Cryptography and Information Security Hiroshima, Japan, Jan , 2006 The Institute of Electronics, Information and Communication Engineers Trusted Database Interoperation Based on Collaborative Role-Based Access Control Hyung Chan Kim R. S. Ramakrishna Kouichi Sakurai Wook Shin Abstract The increasing development of distributed application has led to the widespread involvement of database interconnection. Information sharing through the interconnection requires a new type of access control beyond local-only access control scheme: we need to consider the relationship among organizations and a collaborative application. In this paper, we describe an access control framework for the trusted database interoperation based on the collaborative role-based access control model. The cooperation is realized by the construction of virtual role hierarchy for the collaborative application extending the conventional role based access control model. The policy mediator for the application achieves the integration of heterogeneous local datasources which may be under different security policies. Keywords: access control, role-based access control, database security, mediator enforced security, interoperation, collaboration model, multi-domain security 1 Introduction There are pressing demands to support distributed applications which use multiple datasources across the organization s boundary. The administrative service of gorvenment, insurance system of company, and medical information service of hospital are deemed to be such examples. In such applications, we can not expect that all organizations or systems adopt a same type of database system. Moreover we can not also assume that each orgarnization s security administrator enforces a same security policy. Various attempts have been made to design and implement trusted database systems based on Mandatory Access Control (MAC) models [1]. Letting aside the effectivness of MAC schemes, we now take attentions to Role Based Access Control (RBAC). RBAC models [6, 7, 8] have been widely accepted in many computing systems as it offers flexibility in enforcement, and policy neutrality. It also easy to administer. Thus, recent DBMSs have taken the effort in providing support for RBAC. Many RBAC models have been proposed to assist organization s security policies but the most efforts are on the single security domain. In this paper, we describe an access control framework for the trusted database interoperation based on collaborative role-based access control (C-RBAC) model proposed in [10]. C-RBAC is a supplemented model of the concept of multidomain security [11, 12] and Department of Information and Communications, Gwangju Institute of Science and Technology (GIST), Gwangju , Rep. of Korea (kimhc@gist.ac.kr) GIST (rsr@gist.ac.kr) Faculty of Computer Science and Communication Engineering, Kyushu University, Fukuoka , Japan (sakurai@csce.kyushu-u.ac.jp) Department of Computer Science, University of Illinois at Urbana-Champaign, IL 61801, USA (wookshin@uiuc.edu) metapolicy [13] on conventional RBAC. The access control framework is based on the construction of virtual role hierarchy for the cooperative database application. We also look around the possibility of the inconsistent policy configuration and its example resolution method within the framework. 1.1 Related Work Our research is motivated from Dawson et al. [2]. They have suggested the mediator and wrapper based architecture for database interoperation under MAC policy to integrate heterogenous datasources. The application hieararchy, a lattice over security labels, is similar with our concept of cooperation domain made of a role hierarchy [10]. The Argos architecture [3] has also considered the intergration of multiple datasources: propagating global authorizations to autonomous local systems by mapping global onto local access rights. The Argos is based on identity-based access control (IBAC). There are recent efforts for collaboration supplemented on RBAC model. The translation between role hierarchies is suggested from Interoperable RBAC (IRBAC) model [4]. The permission is propagated beyond the boundaries by the direct role translation among the cooperated systems in IRBAC. However there is no concept on the cooperation domain or virtual hierarchy in their research. Whereas, there is the concept of cooperation (team) in team-based access control (TMAC) [5]. They have introduced the team role for the collaboration and assigns team members to the roles for temporary activated duties. Our research is different from theirs in that their assumption is neither on the heterogenous system nor on the autonomous domains. They have shown an example within an single organization.

2 The rest of this paper is organized as follows. In section 2, we present the collaborative role based access control model. The example of security configuration for trusted database interoperation is given in section 3. Section 4 discusses on the possible ambiguity in the policy configuration and presents an example resolution method. The paper ends with conclusions in section 5. 2 Collaborative Role Based Access Control Here we use the notion of domain to demarcate the system boundary of access entities under single security policy. The core of the Collaborative RBAC (C-RBAC) model [Fig. 1] is the Cooperation Role (also called Meta Role). As a role is a job function or a named duty in an organization, the cooperation role represents a job function of a cooperative task. Translation capabilities that give rise to cooperation roles are given for each security administrator. All the interested parties constitute an interoperable domain by agreeing on cooperation roles and assigning their permissions to those roles. Assignment of permissions to the cooperation roles are fixed by translation relations between roles and cooperation roles. By introducing the cooperation role, a virtual domain can be built in a natural way. This virtual domain acts as a metapolicy domain which abstracts the inter-domain collaboration. We concentrate on the clear separation of inter-domain sessions from local sessions with interoperable user assignment (IU A) and role translation (RT) relations. IUA is the assignment relation by which a user of a domain has a duty for inter-domain actions. RT is the translation relation which builds cooperation duties by collecting roles needed to perform the cooperative task. The direction of RT relation is one-way from local domain to cooperation domain. Consequently, permissions of each role are gathered into a cooperation role. These permissions are the privilege of the cooperation duty. IUA and RT relations are valid only under the cooperation negotiation. With one-way property of RT relation, it is impossible to configure a formation in which transfer of privileges are feasible along with the chain of domains. All inter-domain accesses are granted or denied via cooperation roles which are formed by the agreement of each domain. The decisions on inter-domain access have to be taken subject to the inter-domain policy. The agreement process can be executed with the help of mature public key based cryptographic technology. The main components of the core C-RBAC are given below. DOMAIN i ; a domain managed by a single administrative authority, identified as i, where 1 i n. (In the following definition, all sets with the subscript i are defined under the DOMAIN i.) USER i, ROLE i, OPR i, OBJ i : the set of users, roles, operations and objects. PERM i = OPR i OBJ i : the set of permissions. SESSION i : the set of sessions. CROLE j : the set of interoperable or cooperative job functions, identified as j. (1 j m) UA i USER i ROLE i : a many-to-many userto-role relation. IUA i USER i CROLE j : a many-to-many user-to-cooperation role assignment relation. PA i PERM i ROLE i : a many-to-many roleto-permission assignment relation. RT i ROLE i CROLE j : a many-to-many roleto-cooperation role translation relation. The session captures dynamics of the access context. We define the following functions for session management. users on role(r : ROLE i ) 2 USERi : users assigned to a role r, namely, users on role(r) = {u USER i (u, r) UA i } USER k users on crole(cr : CROLE j ) 2 : users assigned to a cooperation role cr, namely, users on crole(cr) = {u n USER k (u, cr) n n IUA k } active user(s : SESSION i ) USER i : the mapping from a session to a user. active roles(s : SESSION i ) 2 ROLEi : the mapping from a session to a set of roles, i.e.; active roles(s) {r ROLE i (active user(s), r) UA i } CROLE k active croles(s : SESSION i ) 2 : the mapping from a session to a set of cooperation roles, namely, active croles(cr) {cr m (active user(s), cr) n IUA k } m CROLE k To query the available permissions to a given role or a cooperation role, the following functions are invoked: perms on role(r : ROLE i ) 2 PERMi : permissions assigned to a role r, namely, perms on role(r) = {p PERM i (p, r) PA i }

3 perms on crole(cr : CROLE j ) 2 permissions assigned to a cooperation role cr, i.e., perms on crole(cr) = {p n r[(r, cr) n RT k (p, r) n Figure 1: C-RBAC model n PERM k : PERM k PA k ]} avail session perms(s : SESSION i ) 2 a set of permissions which a session s has: perms on role(r) r active roles(s) perms on crole(cr) cr active croles(s) n PERM k : A hierarchical model is built on the core C-RBAC model. We define the hierarchical model for roles as well as cooperation roles from two angles: permission inheritance and user membership inheritance since they are very important features of RBAC [8]. Permission inheritance is a well-known property of RBAC: if there are partial ordering relations among roles, then an ancestor role has permissions of descendants. The membership inheritance allows users assigned to an ancestor role to have the membership of descendant role as well. Note that we do not define a hierarchical relationship between roles and cooperation roles. This is consistent with our aim: separation of cooperation from the local policy domains. RH i ROLE i ROLE i, partial ordering on ROLE i called the inheritance relation, i.e., For r 1, r 2 ROLE i, r 1 r 2 means r 1 is an ancestor of r 2. (Equivalently, r 2 is a decendent of r 1.) CRH j CROLE j CROLE j, partial ordering on CROLE j called the inheritance relation, i.e., For cr 1, cr 2 CROLE j, cr 1 cr 2 means cr 1 is an ancestor of cr 2. (Equivalently, cr 2 is a decendent of cr 1.) 3 Security Policy Configuration for Trusted Database Interoperation The realization of the application which uses multiple datasouces needs the policy mediator who coordinates the application policy amongst multiple domains. Sometimes the negotiation on the several factors such as authentication, the range of available permissions or users may or may not be needed to share the datasources. The constructed application involves the coordinator which takes charge of the orchestration of multidomain accesses. Wrappers may be involved in each local domain to adjust coordinated protocols with the coordinator. This section presents how to configure security policy for the sample application which uses multiple datasouces using C-RBAC model for the coordinator and wrappers. 3.1 Configuring Role Hierarchy We take an rescue application to demonstrate our scheme. The rescue application is activated when the emergency occurs. For example, car accident or fire may be the case. In this example, three domains (organizations) fire station (f), hospital (h), and city office (c) are involved to activate the rescue team. Each domain maintains its own database for the specific job functions and is under the specific security policy of its own. Figure 2 illustrates an example configuration of role hiearachy for the rescue collaboration. The cooperation role hierarchy is constructed to involve roles such as team leader (tl r), rescuer (r r), medic (m r), and team member (tm r). Ordinary query privileges for commonly used information among rescue team members are assigned to team member role so as to propagate its privileges to ancestor roles. After initiating the cooperation role hierarchy, the translation of each domain is carried out. A Cheif Officer (f.co r) 1 of the fire station and Cheif Doctor (h.cd r) of the hospital are translated to play team leader of the rescue team. The rescuer (f.r r) of the fire station has 1 We prefix the first alphabet of domain name for the convenience.

4 Figure 2: Role hierarchy configuration for rescue application Table 1: Mapping among application schema and local schema App. role App. schema Local schema tl r none none r r district, equipment f.j area, f.res train, f.status m r med info h.patient history, h.constitution tm r identity c.residence privileges on the schema of rescue knowlegebase for example, peculiarity of the emgergent area and suitable rescue equipment and he/she is translated into the rescuer of the collaboration (r r). The medical record officer (h.mro r) in the hospital who is granted for the access to the medical record schema which maintain the medical history and other descriptions about idiosyncrasy of the previously visited patients. The role (h.mro r) is mapped to the medic (m r) by the appication configuration. The schema associated with Residence role (c.resi r) in the city office contains residence information of the jurisdictional area. The information may include resident s social security number (SSN), address, family, and so on. The unclassified schema of the fire station and the hospital can be accessed by all the subjects whitin the application. 3.2 The Mapping Among Application Schema and Local Domain Schema Table 1 shows the relationship amongst the application roles and schemas. Each application role is associated with the appropriate application schema which is meta schema only used in the application. The real datasouces are connected with the relation between the application and the local domain schema. For example, a user on rescuer role (r r) uses district schema and equipment schema to know about the area information of rescue spot and the suitable equipment status for the rescue, respectively. Medic (m r) needs to know about the case history to be careful in rescue activity, thus the application schema med info is defined. All the team member (tm r) need to maintain the personal information (identity) to perform query operations jointly with its own knowledge-specialized schema. These application schemas are constructed in the way of being provided by each local domain s schemas. The district schema is related with the schema f.j area which is for the area information of the fire station s jurisdiction. The equipment schema uses both the schema containing rescue training knowledge base f.res train and the schema for managing available equipment status. Similarly, med info schema refers the h.patient history and h.constitution to get information on the people rescued whose identity is in the identity schema mapped from residence schema of the city office. The team leader isn t direcly associated with any schema, but he/she can manage the team refering all the database schemas due to the role dominance relation. 3.3 Application Query Under the policy configuration for the rescue application, the following query might be possible on team s tuning out to get information about route and buliding description based on the similarity of description pattern between person s address and location index of the district knowledgebase. SELECT route, build desc FROM district [dist] identity [id] WHERE SIMILARITY(id.address, dist.location) and (id.ssn = JE1023A31 or id.name = john ). Similarly the medic can acquire pre-information on the medical constitution of person rescued to take precautions in rescue activity with refering the identity schema. Both the role r r and m r can use the schema identity due to the role dominance relation. However, the two roles can not access the counter role s schema because of separation of duty: there is no relationship betweem the two role.

5 Figure 3: Ambiguity and its detection Note that local users still operates with its own database under its own security configuration. 4 Ambiguity in Policy Configuration There might be possible conflicts in security configuration for the application due to the translation relation among domains. Concerning the RBAC model, our previous work have investigated on the conflict issues of directely translation method among local roles without application domain in [9] based on Kühnhauser s domain classification [14]. We also have insisted that one can handle domain conflict, policy-freeness, and rule conflict in terms of the formation of access entities compared to the direct role-to-role translation [10]. However, there still need to be careful in policy configuration because we can not always sure that the configured policy is consistent. Here we present unambiguous property to be avoided. Figure 3 depicts the example of ambiguous configuration. We rephrases the definition of the nonambiguity from [2] to fit in our model as the following. Nonambiguity: For a cooperation domain s role set ROLE C and a local domain s role set ROLE L, where r i, r j ROLE C, r u, r v ROLE L : if r i > r j and r u > r v is respectively the configuration of cooperation domain and local domain, and (r i, r v ) RT L, then it must be not the case (r j, r u ) RT L. To our anaysis, the result is that the two roles, r r and tm r is equalized in terms of privileges. To show this, let s define a privilege derivation relation ( ): if a r b r then the privileges of role r a is derived to role r b. Role inheritance relation or role translation in C-RBAC can be understood in terms of the privilege derivation relation. Starting from tm r we can discover that privilege derivation paths, f.u r f.r r tm r and f.u r r r, are possible. Thus tm r has more privileges than r r. However, by the cooperation role hierarchy and the transitity of privilege inheritance, tm r r r results in f.u r f.r r( tm r) r r. Therefore, the two role can have same privileges. This causes the implcit rule conflict. Because the cooperation configuration dictates that r r is the ancestor of tm r, though they are same in their ability as they have same privileges by the implicit rule. If this example is extended for the role m r in Figure 2 with the hospital domain, then that case might break the seperation of duty principle between r r and m r. Because the three roles have a same duty. Therefore, some resolution method have to be necessarily applied to policy configurator to clear up the ambiguity. Here we present one of possible solutions based on the role graph model [15]. A role graph is an acyclic, directed graph. Node and edge represent role and inheritance relationship respectively. Each node is associated with role name, direct and effective privileges. Direct privilege (Direct(r)) is a set of privileges that is assigned to the corresponding role by permission assignment, and effective privilege (Effective(r)) is derived prvileges from its junior roles. In a role graph, there always must be MaxRole and MinRole which are the least upper bound (lub) and the greatest lower bound (glb). The inheritance relatiohsip r i r j means Effective(r i ) Effective(r j ). Effective(MaxRole) is the union of all the privileges and Effective(M inrole) =. We exploit the edge insertion algorithm in [15]. Ordinarily there may be or may not be lub or glb in a role hierarchy. Thus, we construct the global role graph before inserting the RT relations in the way that mapping all the maximal nodes of each domain (including application hierarchy) to the (global) MaxRole and all the minimal nodes to the MinRole [Fig. 3] before configuring RT relation. Then we apply the algorithm 1 to insert RT relation between the application hiearachy and the local domain. The algorithm detects inconsistency. If the global role graph falls to be inconsistent state after certain RT relation (edge) insertion for example, inserting (2) after (1) or vice versa in Figure 3 effective privileges of conflicting roles get to be same as the aformentioned analysis. 5 Conclusion We have presented on the security policy configuration for trusted database interoperations to support collaborative applications which refer multiple datasources. Our framework is based on Collaborative Role Based Access Control model and the model extend the conventional RBAC to support cooperation constructing cooperation (application) domain. We have illustrated an example configuration for the rescue application with three local domains datasources. We have also illustrated the possible ambiguity in the policy configuration and presented its possible resolution method which can be used in configuration time. Our future research interest is on the possible extension of CRBAC model to include several modalities by which support constraints on temporal or spatial access control to be used in recent ubiquitous environments. Acknowlegement This research was supported

6 Algorithm 1 RT Insertion 1: procedure RTInsertion(RG =< R, >, r 1 r 2 ) 2: if there is a path from r 1 to r 2 then Check if there is already the relation 3: return; 4: end if 5: add edge (RT relation) r 1 r 2 to RG; Insert the relation 6: Direct(r 2 ) := Direct(r 2 ) Effective(r 1 ); Adjust privileges 7: Effective(r 2 ) := Effective(r 2 ) Effective(r 1 ); 8: for all r i, r j R do Check inconsistency 9: if Effective(r i ) = Effective(r j ) then 10: print error (message: Inconsistent RT insertion); 11: abort; 12: end if 13: end procedure in part by Joint Forum for Strategic Software Research (SSR) of International Information Science Foundation of JAPAN, and in part by Brain Korea 21 of Ministry of Education (MOE) of KOREA. References [1] S. Castano, M. Fugini, G. Martella, and P. Samarati, Database Security, ACM Press, Addison- Wesley, [2] S. Dawson, S. Qian, and P. Samarati, Providing Security and Interoperation of Heterogeneous System, Distributed and Parallel Databases 8, pp , [3] D. Jonscher and K.R. Dittrich, Argos A configurable access control subsystem which can propagate access rights, Proc. of 9th IFIP Working Conf. on Database Security, [4] A. Kapadia, J. Al-Muhtadi, R. Campbell, and D. Mickunas, IRBAC 2000: Secure Interoperability Using Dynamic Role Translation, Proc. of the 1st International Conference on Internet Computing, Jun [5] R. K. Thomas, Team-based access control (TMAC): a primitive for applying role-based access controls in collaborative environments, Proc. of the second ACM workshop on Role-based access control, pp.13-19, [9] H. C. Kim, W. Shin, R. S. Ramakrishna, and K. Sakurai, Conflicts of Role Based Access Control in Multi-domain Security, Proc. of 2004 Symposium on Cryptography and Information Security (SCIS 2004), pp , [10] H. C. Kim, R. S. Ramakrishna, K. Sakurai, A Collaborative Role-Based Access Control for Trusted Operating Systems in Distributed Environment, IEICE Trans. Fundamentals, Vol.E88-A, No. 1, Jan [11] Josė Vȧzquez-Gȯmez, Modelling Multidomain Security, In proc. of workshop on New security paradigms, pp , [12] Josė Vȧzquez-Gȯmez, Multidomain Security, Computers & Security, Vol. 13, pp , [13] H. H. Hosmer, Metapolicies I, ACM SIGSAC Review, pp , [14] Winfried E. Kühnhauser, A Classification of Interdomain Actions, ACM SIGOPS Operating Systems Review Vol. 32, No. 4, pp , [15] M. Nayanchama, S. Osborn, The Role Graph Model and Conflict of Interest, ACM Trans. on Info. and Sys. Sec., Vol. 2, No. 1, pp. 3-33, [6] D. Ferraiolo, J. Cugini, and R. Kuhn, Role Based Access Control: Features and Motivations, In Proc. of Computer Security Applications Conference, IEEE Computer Society Press, [7] R. S. Sandhu, E. J. Coyne, H. L. Feinstein and R. Chandramouli, Role-Based Access Control Models, IEEE Computers, Vol. 29, No. 2, pp , Feb [8] D. F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli, Proposed NIST Standard for Role-Based Access Control Model, ACM Trans. on Information and Systems Security, Vol. 4, No. 3, pp , Aug