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. 17-20, 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 in-volvement 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 relation-ship 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 med-ical information service of hospital are deemed to be such examples. In such applications, we can not ex-pect that all organizations or systems adopt a same type of database system. Moreover we can not also as-sume that each orgarnization’s security administrator enforces a same security policy.
Various attempts have been made to design and im-plement 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 pol-icy 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 as-sist organization’s security policies but the most efforts are on the single security domain.
In this paper, we describe an access control frame-work 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
In-stitute of Science and Technology (GIST), Gwangju 500-712, Rep. of Korea ([email protected])
†GIST ([email protected])
‡ Faculty of Computer Science and Communication
En-gineering, Kyushu University, Fukuoka 812-8581, Japan ([email protected])
§ Department of Computer Science, University of Illinois at
Urbana-Champaign, IL 61801, USA ([email protected])
metapolicy [13] on conventional RBAC. The access con-trol 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 ap-plication 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 data-sources: 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 hierar-chies is suggested from Interoperable RBAC (IRBAC) model [4]. The permission is propagated beyond the boundaries by the direct role translation among the co-operated systems in IRBAC. However there is no con-cept on the cooperation domain or virtual hierarchy in their research. Whereas, there is the concept of coop-eration (team) in team-based access control (TMAC) [5]. They have introduced the team role for the col-laboration 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 organi-zation.
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
Con-trol
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 theCooperation Role(also calledMeta Role). As a role is a job function or a named duty in an orga-nization, the cooperation role represents a job function of a cooperative task. Translation capabilities that give rise to cooperation roles are given for each security ad-ministrator. All the interested parties constitute an interoperable domain by agreeing on cooperation roles and assigning their permissions to those roles. Assign-ment 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 do-main acts as a metapolicy dodo-main which abstracts the inter-domain collaboration.
We concentrate on the clear separation of inter-domain sessions from local sessions with interoperable user as-signment (IU A) and role translation (RT) relations.
IU A 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 ofRT relation is one-way from local do-main to cooperation dodo-main. Consequently, permis-sions of each role are gathered into a cooperation role. These permissions are the privilege of the cooperation duty.
IU A and RT relations are valid only under the co-operation 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.
• DOM AINi; a domain managed by a single
ad-ministrative authority, identified as i, where 1≤
i ≤n. (In the following definition, all sets with the subscriptiare defined under theDOM AINi.)
• U SERi, ROLEi, OP Ri, OBJi: the set of users,
roles, operations and objects.
• P ERMi=OP Ri×OBJi: the set of permissions. • SESSIONi: the set of sessions.
• CROLEj: the set of interoperable or cooperative
job functions, identified as j. (1≤j≤m)
• U Ai⊆U SERi×ROLEi: a many-to-many
user-to-role relation.
• IU Ai ⊆ U SERi ×CROLEj: a many-to-many
user-to-cooperation role assignment relation.
• P Ai⊆P ERMi×ROLEi: a many-to-many
role-to-permission assignment relation.
• RTi⊆ROLEi×CROLEj: a many-to-many
role-to-cooperation role translation relation.
The session captures dynamics of the access context. We define the following functions for session manage-ment.
• users on role(r : ROLEi) →2U SERi: users
as-signed to a roler, namely,
– users on role(r) =
{u∈U SERi|(u, r)∈U Ai}
• users on crole(cr:CROLEj)→2 n
S
k=1 U SERk
: users assigned to a cooperation rolecr, namely,
– users on crole(cr) = {u∈ n S k=1 U SERk |(u, cr)∈ n S k=1 IU Ak} • active user(s:SESSIONi)→U SERi: the
map-ping from a session to a user.
• active roles(s : SESSIONi) → 2ROLEi: the
mapping from a session to a set of roles, i.e.;
– active roles(s)⊆
{r∈ROLEi|(active user(s), r)∈U Ai}
• active croles(s : SESSIONi) → 2 m
S
k=1
CROLEk
: the mapping from a session to a set of cooperation roles, namely, – active croles(cr)⊆ {cr∈ m S k=1 CROLEk | (active user(s), cr)∈ n S k=1 IU Ak}
To query the available permissions to a given role or a cooperation role, the following functions are invoked:
• perms on role(r : ROLEi) →2P ERMi:
permis-sions assigned to a roler, namely,
– perms on role(r) =
Figure 1: C-RBAC model
• perms on crole(cr : CROLEj) → 2 n
S
k=1 P ERMk
: permissions assigned to a cooperation rolecr, i.e.,
– perms on crole(cr) ={p∈ n S k=1 P ERMk| ∃r[(r, cr)∈ n S k=1 RTk∧(p, r)∈ n S k=1 P Ak]}
• avail session perms(s:SESSIONi)→2 n
S
k=1 P ERMk
: a set of permissions which a sessionshas:
– S r∈active roles(s) perms on role(r)∪ S cr∈active croles(s) perms on crole(cr)
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 an-cestor role has permissions of descendants’. The mem-bership 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.
• RHi ⊆ ROLEi ×ROLEi, partial ordering on
ROLEi called the inheritance relation, i.e.,
– For ∀r1, r2 ∈ ROLEi, r1 ≥ r2 means r1 is
an ancestor ofr2. (Equivalently,r2 is a
de-cendent ofr1.)
• CRHj⊆CROLEj×CROLEj, partial ordering
onCROLEj called the inheritance relation, i.e.,
– For ∀cr1, cr2 ∈ CROLEj, cr1 ≥ cr2 means
cr1 is an ancestor ofcr2. (Equivalently,cr2
is a decendent ofcr1.)
3
Security Policy Configuration for Trusted
Database Interoperation
The realization of the application which uses multi-ple datasouces needs the policy mediator who coordi-nates 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 data-sources. The constructed application involves the co-ordinator 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 config-ure 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 (or-ganizations) – fire station (f), hospital (h), and city of-fice (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 cooper-ation 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 mem-bers are assigned to team member role so as to propa-gate its privileges to ancestor roles.
After initiating the cooperation role hierarchy, the translation of each domain is carried out. A Cheif Offi-cer (f.co r)1of 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
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 idio-syncrasy of the previously visited patients. The role (h.mro r) is mapped to the medic (m r) by the appica-tion configuraappica-tion. The schema associated with Resi-dence role (c.resi r) in the city office contains resiResi-dence 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 applica-tion roles and schemas. Each applicaapplica-tion role is asso-ciated 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 exam-ple, 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 informa-tion (identity) to perform query operainforma-tions 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 ju-risdiction. The equipment schema uses both the schema containing rescue training knowledge base f.res train and the schema for managing available equipment sta-tus. 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 rela-tion.
3.3 Application Query
Under the policy configuration for the rescue appli-cation, the following query might be possible on team’s tuning out to get information about route and bulid-ing 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 pre-cautions 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.
Figure 3: Ambiguity and its detection
Note that local users still operates with its own data-base under its own security configuration.
4
Ambiguity in Policy Configuration
There might be possible conflicts in security configu-ration 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 with-out application domain in [9] based on K¨uhnhauser’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 con-figuration because we can not always sure that the configured policy is consistent. Here we present un-ambiguous 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
ROLEC and a local domain’s role setROLEL, where
ri, rj ∈ ROLEC, ru, rv ∈ ROLEL: if ri > rj and
ru> rvis respectively the configuration of cooperation
domain and local domain, and (ri, rv)∈RTL, then it
must be not the case (rj, ru)∈RTL.
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 (7→): if
a r 7→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 r7→f.r r7→tm r
and f.u r 7→ 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 r7→ r r results in f.u r 7→ f.r r(7→ tm r) 7→ r r. Therefore, the two role can have same privileges. This
causes the implcit rule conflict. Because the cooper-ation configurcooper-ation 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 nec-essarily 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 privi-leges. Direct privilege (Direct(r)) is a set of privileges that is assigned to the corresponding role by permis-sion 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 relatiohsipri→rjmeans
Effective(ri) ⊂ Effective(rj). Effective(M axRole) is
the union of all the privileges and Effective(M inRole) =
∅.
We exploit the edge insertion algorithm in [15]. Or-dinarily there may be or may not be lub or glb in a role hierarchy. Thus, we construct the global role graph be-fore inserting the RT relations in the way that mapping all the maximal nodes of each domain (including appli-cation hierarchy) to the (global) MaxRole and all the minimal nodes to the MinRole [Fig. 3] before config-uring RT relation. Then we apply the algorithm 1 to insert RT relation between the application hiearachy and the local domain. The algorithm detects inconsis-tency. If the global role graph falls to be inconsistent state after certain RT relation (edge) insertion – for ex-ample, 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 configu-ration for trusted database interopeconfigu-rations to support collaborative applications which refer multiple data-sources. Our framework is based on Collaborative Role Based Access Control model and the model extend the conventional RBAC to support cooperation construct-ing cooperation (application) domain. We have illus-trated an example configuration for the rescue appli-cation with three local domains’ datasources. We have also illustrated the possible ambiguity in the policy con-figuration and presented its possible resolution method which can be used in configuration time.
Our future research interest is on the possible exten-sion of CRBAC model to include several modalities by which support constraints on temporal or spatial access control to be used in recent ubiquitous environments.
Algorithm 1RT Insertion
1: procedureRTInsertion(RG=<R,→>, r1→r2)
2: if there is a path fromr1to r2 then ⊲Check if there is already the relation
3: return;
4: end if
5: add edge (RT relation)r1→r2 toRG; ⊲ Insert the relation
6: Direct(r2) := Direct(r2)−Effective(r1); ⊲Adjust privileges
7: Effective(r2) := Effective(r2)∪Effective(r1);
8: forallri,rj∈ Rdo ⊲Check inconsistency
9: if Effective(ri) = Effective(rj)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. Sama-rati, “Database Security,” ACM Press, Addison-Wesley, 1995.
[2] S. Dawson, S. Qian, and P. Samarati, “Providing Security and Interoperation of Heterogeneous Sys-tem,” Distributed and Parallel Databases 8, pp. 119-145, 2000.
[3] D. Jonscher and K.R. Dittrich, “Argos – A config-urable access control subsystem which can propa-gate access rights,” Proc. of 9th IFIP Working Conf. on Database Security, 1995.
[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. 2000.
[5] R. K. Thomas, “Team-based access control (TMAC): a primitive for applying role-based ac-cess controls in collaborative environments,” Proc. of the second ACM workshop on Role-based access control, pp.13-19, 1997.
[6] D. Ferraiolo, J. Cugini, and R. Kuhn, “Role Based Access Control: Features and Motivations,” In Proc. of Computer Security Applications Confer-ence, IEEE Computer Society Press, 1995.
[7] R. S. Sandhu, E. J. Coyne, H. L. Feinstein and R. Chandramouli, “Role-Based Access Control Mod-els,” IEEE Computers, Vol. 29, No. 2, pp. 38-47, Feb. 1996.
[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. 224-274, Aug. 2001.
[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. 481-486, 2004.
[10] H. C. Kim, R. S. Ramakrishna, K. Sakurai, “A Collaborative Role-Based Access Control for Trusted Operating Systems in Distributed Envi-ronment,” IEICE Trans. Fundamentals, Vol.E88-A, No. 1, Jan. 2005.
[11] Jos ˙e V ˙azquez-G ˙omez, “Modelling Multidomain Security,” In proc. of 1992-1993 workshop on New security paradigms, pp. 167-174, 1993.
[12] Jos ˙e V ˙azquez-G ˙omez, “Multidomain Security,” Computers & Security, Vol. 13, pp. 161-184, 1994. [13] H. H. Hosmer, “Metapolicies I,” ACM SIGSAC
Review, pp. 18-43, 1992.
[14] Winfried E. K¨uhnhauser, “A Classification of In-terdomain Actions,” ACM SIGOPS Operating Sys-tems Review Vol. 32, No. 4, pp. 47-61, 1998. [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, 1999.
