Context and Role Based Hybrid Access Control for ... - CiteSeerX

Download PDF
3 downloads 646 Views 91KB Size Report
Comment
A security policy is expressed by access rules, which determine how accesses are controlled and ... Access control in information systems ensures that accesses ...
Context and Role Based Hybrid Access Control for Collaborative Environments Georgiadis C., Mavridis I. and Pangalos G. Informatics Lab., Computers Div., Faculty of Technology, Aristotle University of Thessaloniki, 54006, Greece, emails: [email protected], [email protected], [email protected] Abstract Role-based mechanisms usually provide a sufficient way to establish access control in most information systems. Passive security permission assignment cannot however support efficiently the dynamic aspects of many modern information systems. Health Care information systems provide a good example of such an environment. In dynamically changing clinical workflow environments there is a need for active security permission activation. In order to address this problem we propose to utilize the concept of a clinical task, together with a number of factors that characterize clinical activities for particular patient cases. The specific values of those factors form a context that could identify particular clinical tasks. In every clinical task a number of users might be involved that collaborate for taking care of a particular patient. However, the assignment of a number of different contexts to each one user usually causes a significant administrative overhead. This could be eliminated by using the team concept in a similar way as roles. The participation of particular users in teams is based on their assigned roles already defined. The role-based permission set of a particular user is a combination of the permissions of all the roles activated by the users participating in the same team. The final permission set of the user is derived by applying the team context in order to filter the role-based permission set and let only the tuples of particular patients to be accessed during the execution of his task. Our approach is implemented as an extension to our existing eMEDAC security policy we have developed and implemented already for use in health care environments. Keywords: access control, active security, collaboration, context, role. 1 Introduction Role-based access control is an emerging approach for applying sufficient security to large organizations due to the significant advantages it provides for the administration of centrally controlled and organization depended authorizations of users. According to [Sandhu, 1998], many enterprises within industry and civilian government base access control decisions on the roles that individual users take on. They also prefer to centrally control and maintain access rights according to the organization protection guidelines since end users do not “own” the information for which they are allowed access as is often assumed by traditional discretionary access control. Instead, the organization is the actual “owner” of data objects.

Healthcare organizations are characterized by the need to support specific requirements for the protection of personal and medical patient data, as well as the increased adoption of IT technologies for electronic storage, transfer and processing of such information. However, the increasing use of computerized data management has presented new challenges to the way healthcare establishments approach security for medical data and has increased the need for clinical workflow security ([ORA 1996]). An example of clinical workflow security is a case of a patient admitted to a hospital where he may be treated by several individuals at various times during the course of his stay, each of whom will require access to various aspects of his clinical records. Healthcare environments are a representative case of collaborative environments since the individuals (e.g. doctors and nurses) in many cases do not act in isolation, but they collaborate with others in order to provide care to patients in a more efficient way (e.g. by forming care-teams, [Thomas 1997]). Each member of a team carries with him the authorizations of his active role in the healthcare institution (e.g. physician). However, in special cases, when the user acts not individually but as member of an organized team, these role-based permissions could be modified (enriched and/or filtered). The parameters of such a modification are related to the particular context for accomplishing a specific task. As a result, the modification of role-based permissions could be influenced by the control of the context wherein user tasks are initiated and accomplished. For example, a particular doctor’s access requests must be satisfied or not depending on the identities of the particular patients he is taking care of. The combination of a role-based and a context-based access control leads to a hybrid access control policy, which is described in this paper. In section 2 below, we discuss the security requirements in collaborative environments as the healthcare ones. In Section 3 we outline role-based passive access control provided by our known eMEDAC security policy. In section 4 we outline the related work and a number of factors affecting our approach for context-based active access control. In section 5 we describe our proposal of a hybrid access control model. In section 6 we present a formal description of our model and in section 7 we describe the way user permissions are activated during the runtime. Our conclusions together with future work directions are given in section 8. 2 Security Requirements in Collaborative Environments The protection of sensitive personal data stored in database systems from unauthorised access, illegal modification or system failure is a major concern in healthcare information systems. For example, it is important to ensure that no patient’s life is endangered due to information-system error or to illegal modification of medical information. Another concern that is equally important is the assurance of the patient’s privacy by allowing access to the medical record (especially sensitive information) only to authorised users. As a result, security of healthcare information systems (HIS) requires the use of special security policies that are able to preserve all three-security components at the same time: confidentiality, integrity and availability ([Pangalos and Khair, 1996]).

2

There are three major categories of security policies that are commonly used in computer systems: the discretionary policies, the mandatory policies, and the role-based policies. However, as it has been demonstrated ([Pangalos, Khair et. al, 1995], [Pangalos, Gritzalis et. al, 1995]), both discretionary and mandatory features when used separately are not sufficient in health care environments. Therefore, a previously proposed security policy called eMEDAC (enhanced Medical Environment Database Access Control) based on both MAC1 and DAC2 security models and defined on the basis of role-based components, has been proposed and proved to be able to satisfy all the needed security requirements ([Mavridis, Pangalos et. al, 1999]). A security policy is expressed by access rules, which determine how accesses are controlled and access decisions determined ([Sandhu and Samarati, 1997], [Castano, Fugini et. al, 1994]). It is usually enforced by various security mechanisms, which can be classified in the following categories: identification, authentication, authorization, access control, integrity, consistency, auditing. Access control in information systems ensures that accesses to the system objects occur according to the modes and rules fixed by the corresponding security policies ([Sandhu, 1998]). Access mechanisms can prescribe not only who may have access to a specific resource, but also the type of access that is permitted. However, an important aspect of access control mechanisms, recently introduced in the area of research, has to do with their active or passive character. The majority of wellknown security models are characterized as passive ones in the sense that they include subject-object models for access control, which are implemented using access control matrices, as well as lattice-based access controls. These models do not distinguish between permission assignment and activation. According to [Thomas, 1997], the security issues for clinical workflows associated with patient care are related to provide very tight, just-in-time permissions so that only the appropriate clinical staff could get access to a patient’s records and only when they are providing care for the patient without adding any significant administrative overhead. As a result, there is a need for access control based on the emerging context associated with tasks and activities. More precisely, depended on the particular patient, the location of where the activity takes place and the moment when access requests are submitted. 3 Role-based Access Control With role-based access controls, access rights are grouped by role name. This approach offers significant advantages on administration issues since the workload of security administrator is reduced. Each user is assigned one or more roles, and each role is assigned one or more permissions that are permitted to users in that role ([NIST, 1999]). Users are granted membership into roles based on their competencies and responsibilities 1

MAC provides a means for restricting access to objects based on the sensitivity (represented by a label that is consisted of a level and a category set) of the information contained in them and the clearance (represented by a similar label) of subjects that request to access such information ([TCSEC, 1985]). 2

DAC permits the granting and revoking of access control privileges to be left to the discretion of the individual users that are said to be the owners of the objects under their control ([NIST, 1995]).

3

in the organization. User membership into roles can be revoked easily and new memberships established as needed. This simplifies the administration and management of permissions since roles can be updated without updating the permissions for every user on an individual basis ([NIST, 1995]). Moreover, the use of role hierarchies provides additional advantages since one role may implicitly include the operations that are associated with another role. A recent well-known role-based approach is RBAC ([Sandhu, 1998]), which has received considerable attention as a promising way to enhance traditional mandatory and discretionary models. Our role-based approach for access control in healthcare environments is called eMEDAC and provides both discretionary and mandatory access control, a feature that is useful in order to protect patient privacy without sacrificing the overall system performance ([Mavridis, Pangalos et. al, 1999]), [Pangalos and Khair, 1996], [Pangalos, Gritzalis et. al, 1995]). The eMEDAC security policy uses RBAC components in the form of the Hyper Node Hierarchies that is a unique mechanism for inheriting permissions (for discretional control) and deriving security labels (for mandatory control). The mechanism of Hyper Node Hierarchies (HNH) is used to construct user roles and data sets hierarchies of any depth, according to the refinement requirements, which is not strictly equal to the number of mandatory security levels. These types of hierarchies are used to derive security levels and categories instead of storing them. As a result, access control data are stored separately from the application data holders. Because MAC, DAC and RBAC are all supported in eMEDAC at the same time, access control becomes efficient and hence particularly suited to security critical environments, like the health care ones, where all three aspects of security are important ([Pangalos, Gritzalis et. al, 1995], ([Pangalos, Khair et. al, 1995]). In spite of the fact that eMEDAC provides a sufficient way to establish an access control system for healthcare information systems, it is characterized as a passive access control system since it does not distinguish between permission assignment and activation. Furthermore, eMEDAC is not considering any type of context during the processing of a user access request. As a result, we recognize that there is a need to add a number of dynamic components, which form a context, to be used during the runtime in order to control in a fine-grained way the activation of user permissions. 4 Context-based Access Control The way the medical and ward services are provided in healthcare establishments (HCEs) can be characterized as "patient-centric". This means that every new patient initiates a new case. Such a case is consisting of a different number of particular tasks according to the initial and current patient needs for care. As a result, the case of a patient is the main target of a group of doctors and nurses who are qualified to play specific roles and finally consist a team of users that collaborate in order to provide efficiently their services. During their work, the users (doctors and nurses) are supported by the IT infrastructure of the HCE. The access of sensitive personal and medical patient data is controlled by the access control system of the HIS.

4

However, in order to provide an access control system that supports variable access authorizations without being intrusive to medical staff and introducing additional administrative overhead, there is a need for a hybrid access control model that incorporates the advantages of role-based permission administration together with a finegrained control of individual user permissions activation. 4.1 Related Work The notion of roles and their hierarchies help up to alleviate complexity of controlling access to patient data, but it has to be used in conjunction with other information, such as affiliation, relationship, location and so on ([Beznosov, 1998]). Access decisions must include other factors, in particular, relationships between entities, such as the user and the object to be accessed. In [Barkley, Beznosov, et. al., 1999] is also used the term dynamic security attributes in contrast to traditional “static” attributes. Dynamic attribute values must be obtained at the time an access decision is required while static attribute values are usually obtained when a session is established. Workflow technology could provide a very interesting solution, but according to [Dadam, Reichert et. al 1997] it seems to be not applicable in real life’s clinical environments. The reasons for this conclusion are that most of the workflow proposals concentrate on certain aspects of the problem only. Especially the aspect of supporting dynamic changes which is very important for the clinical application domain, it is addressed in a limited way. A significant approach to restrict the access on subsets of data objects, but not in collaborative settings, is given in [Giuri and Iglio, 1997]. Concepts as parameterised privilege and role template are introduced to allow the specification on security policies in which the permissions on a system object may depend on the content of the object itself. Context-sensitive roles are proposed as new RBAC features, in order to specify context-based permissions. So, having the role and its permissions indexed by parameters, the same role definition may apply to multiple contexts. Another interesting approach ([Lupu and Sloman, 1997]), questioning in the same area, is proposing role classes and authorization policy templates. Roles are used as groups of policies. An Object Oriented role model is defined in this way. It uses inheritance for re-use of the policy templates that are grouped in a role class. The importance of context information associated with collaborative tasks and the ability to apply this context to decisions regarding permission activation is recognized in [Thomas, 1997]. The collaboration context of a team contains two pieces: the user context, which could be the current members (users) of a team, and the object context, which could be the set of object instances required by the team to accomplish its task. However, the main advantage of RBAC, which is a significant savings of administrative work for centrally defined user permissions, is undercut by the need for specifying the additional access privileges of users participating in a particular case. Furthermore, this process has to be repeated for any subsequent case with a daily period less.

5

4.2 Our Approach In our approach, we acknowledge a number of factors that affect the desirable behaviour of a medical database access control system during the runtime. For example, the actual location of users and patients is important. Some times these locations, for subjects-users and objects-patients, are referred to the same place. This is the case for example, when a doctor is requesting an access while he is in a surgery room and the patient is also admitted there for the operation. On the other hand, the user and patient locations are frequently two different things. For example when a doctor asks access for a patient’s data while he is in his office in hospital and the particular patient lies in a hospital bed. These parameters differentiate the function of permission evaluation depending on the relativity of user places or particular administrative domains wherein the users are acting. In health care environments, a user-identity based access control is usually required, due to temporary increased need-to-know requirements for accomplishing specific tasks ([Thomas, 1997]). For example a patient with cardiological problems is guided to the surgery room (location), where the members of the cardiological team provide for the next two hours their specific services. The cardiological team in this example is a group of users with various roles and same context parameters. These characteristics of clinical activities are introducing the notion of dynamic tasks. The above task example has a scope (e.g. take care of the patient), is executed in a specific place, by specific roles/users and has a start and a finish point. The result of a task influences the execution of the following, if any, task. However, when we analyse a particular case, we cannot define any standard task in it. This means that in every treatment point of a clinical workflow we consider just one identifiable task, which is the collaboration of particular medical users in different roles in order to provide care for a patient. Therefore, tasks in healthcare environments cannot be predefined (or statically defined). Instead, we propose the definition of clinical tasks to be accomplished during the runtime and based on the following factors: • patient: a user (doctor, nurse) gains additional permissions for a specific patient he is in care of. This factor could be extended to the area of an administrative domain where the user is responsible of all the patients are hospitalised therein. • location: the collaborative activity depends on the specific area wherein the users of a particular team are working. When this area is identical to the current place of a specific patient then he can be charged to this team, as a way for a self-administering system. • time: all permissions are valid during a certain time (periodic) interval. To handle these factors we need an active access control system that supports contextbased permission activation. Our perspective is that all these factors have to be considered in order to specify the context associated with a particular clinical task. This context, finally, identifies the specific user need-to-know requirements in order to provide his services efficiently. These requirements are common to the members of his team. So, each member of the team needs to obtain a set of additional permissions that are coming from the roles activated by the users-members of the team. As a result, the final rolebased permission set of members of the same team is identical. The final activated permissions, which are called context-based, can be seen then, as the result of the final

6

line of defence: any specified action could be taken as long as it does not violate the context or scope of the teamwork. The team concept is used for administrative purposes. Because particular user contexts are too many to handle individually, usually in a daily manner, we may consider teams as groups of contexts. In the same way that roles in RBAC provide an efficient way of handling the various users responsibilities in enterprises, teams can be a proportional means for handling the contexts for various activities. There are of course many cases where individual users act in isolation and not as members of a care-team. We can also cope with this situation, by allowing in our model teams with one member. So every user, who wants to act as an individual, is also activating transparently his default private team. Our model can be used therefore in all HCEs since it can cope both with team and individual work of the users. 5 The Proposed Hybrid Access Control Model Our proposed Hybrid Access Control (HAC) model is based on the RBAC ([Sandhu, 1998]) and eMEDAC ([Mavridis, Pangalos et. al, 1999]) models. The HAC model consists of five sets of entities called users, roles, permissions, teams and contexts, as well as a collection of sessions, which are shown in the diagram of figure 1. A user (U) is simply a person (doctor or nurse). A role (R) is a job function within the organization with some associated semantics regarding the authority and responsibility conferred on a member of the role. Permissions (P), equivalent to privileges, authorizations and access rights are approvals of a particular mode of access to one or more data objects. The nature of permission depends on the implementation details of a system and the kind of system that it is. Thus, in our case, for a relational database management system, the objects of protection are relations, tuples, attributes and views using modes of access operations such as SELECT, INSERT and UPDATE. Deletion of sensitive data must be prohibited in medical databases for follow up reasons ([Khair, Mavridis et. al, 1998]). The permissions of users can be defined as data views (e.g. by using the SELECT statement of the Structured Query Language - SQL). Using views of the relational model results in a view-based protection ([Pernul 1994]). A significant advantage of this definition is the use of a flexible granularity for the definition of objects to be protected ([INFOLAB, 2000]). So, it is ease to introduce detailed specifications of specific items (e.g. fields) as well as more general declarations for groups of data sets (e.g. tables) in order to save storage space.

7

User assignment (URS) and permission assignment (PRS) are both many-to-many relations. A user can be a member of many roles, and a role can be assigned to many users. Similarly, a role may have many permissions and the same permission can be assigned to many roles. These relations are the fundamentals concepts in RBAC. Therefore, it is a user who exercises permissions. Using roles as intermediaries to enable users to exercise permissions provides more control advantages than directly relating users to permissions ([Sandhu, 1998]). An important property of a session (S) is that the user associated with a session, via the session-user function defined below, cannot change. The association remains constant for the life of a session. Sessions are also considered under the control of individual users. The distinction between a user and a session is useful only if users exercise discipline regarding the roles they normally invoke. A user should be allowed to login to a system with only those roles appropriate for a given occasion, in order to support the principle of least privilege. So, each session is a mapping of one user to a set of roles, i.e. a user establishes a session during which the user activates some subset of roles that he is a member of. The permissions available to the user are the union of permissions from all roles activated in that session. In addition, active roles in a session can be changed at the user’s discretion. ROLES USER ROLE HIERARCHY A

Level 5

B

URS USER TO ROLES ASSIGNMENT

C

D

E F

G

I

J

H K

Level 4

PRS PERMISSION ASSIGNMENT

Level 3

PERMISSIONS

Level 2 L

L

Level 1

SESSIONS CONSTRAINTS USERS . . . CTS CONTEXT ASSIGNMENT

UTS USER TO TEAMS ASSIGNMENT

CONTEXTS TEAMS

assignment activation

Figure ÓöÜëìá! ¢ ãíùóôç ðáñÜìåôñïò áëëáãÞò.- Context and Role based access control

Ongoing activities, processes or tasks need some information to be able to complete successfully. This context (C) information defines mainly the required users and the required data objects for any specific activity. In addition, other factors such as location and time may also be taken into consideration. The team (T) term is used as a concept that sums up a group of users in specific roles with the objective of completing a specific activity in a particular context. However the team concept is more useful as a grouping 8

mechanism that associates users with contexts. The placement of a team as an intermediary to enable a user to obtain a context is similar to the role usage. Even when a user is acting alone, we may consider him as the only member of his private team. During a session, a user can participate in a number of teams. So, each session is also a mapping of one user to a subset of teams that he is a member of. The contexts available to the user are the union of contexts from all teams that he participates in. Moreover, “active” teams in a session can be changed at the user’s discretion, just like his active roles. A team can also be seen as a mapping to multiple users. The roles activated by these users identify the permission set available to the team as the union of permissions from all roles participating in that team. Context assignment (CTS) and team assignment (UTS) are both many-to-many relations. A team may have many contexts and the same context can be assigned to many teams. Similarly, a user can be a member of many teams, and a team may have many users. However, there are constraints when assigning user to teams. An obvious constraint is related to the roles already assigned to the user. There are mutually exclusive roles and teams, e.g. a user that has been assigned the roles Physician and Director cannot participate to a care-team as a Director. 6 Formal Description of HAC model The following definition, which is based on the definition of RBAC0 ([Sandhu, 1998]), provides some formalization to the above discussion. Definition 1: Our model has the following components: •U, R, P, S, T, C, stand for users, roles, permissions, sessions, teams and contexts, respectively •PRS ⊆ P × R, is a many-to-many permission to role assignment relation •URS ⊆ U × R, is a many-to-many user to role assignment relation •CTS ⊆ C × T, is a many-to-many context to team assignment relation •UTS ⊆ U × T, is a many-to-many user to team assignment relation •session-user : S → U, is a function mapping each session si to the single user user(si) that is constant for the session’s lifetime •session-roles : S → 2R, is a function mapping each session si to a set of roles roles(si) ⊆ {r | (user(si ), r) ∈ URS}, which can change with time, and session si has the permissions U r ∈ roles(si) {p | (p, r) ∈ PRS}

•session-teams : S → 2T, is a function mapping each session si to a set of teams teams(si) ⊆ {t | (user(si), t) ∈ UTS}, which can change with time, and session si has the contexts U t ∈ teams(si) {c | (c, t) ∈ CTS}

•team-users : T → 2U, is a function mapping each team ti to a set of users users(ti) ⊆ {u | (u, ti) ∈ UTS} ∧ ∃sj : user(sj) = u}, which can change with time •team-roles : T → 2R, is a function mapping each team ti to a set of roles roles(ti) ⊆ {r | (users(ti), r) ∈ URS}, which can change with time, and team ti has the permissions U r ∈ roles(ti) {p | (p, r) ∈ PRS}

9

According to the already proposed eMEDAC security policy and the definition methodology ([INFOLAB, 2000]) of security mechanisms in a HCE, we define the initially assigned role-based permissions as well as the user roles, the data sets and their corresponding HNH hierarchies. In general, this procedure depends on static conditions. So, it has to be executed once for the first time and then it has to change rarely. For the construction of hierarchies we use the HNH mechanism that is defined in a formal way below: Definition 2: The HNH mechanism: §N, C, are sets of nodes and connections, respectively §HN ⊆ N x C, each hyper node HN is a double {N, C} §HNH ⊆ HN x HN, is a totally ordered hyper node hierarchy §HN and DN, disjoint sets of (regular) hyper nodes and dummy nodes respectively §BC and LC, disjoint sets of branches and links respectively §a node Ni has a level (depth in the hierarchy) of number i §BC : Ni → N′i ± 1 , branch is a function mapping a node to its ancestor node at the above level §LC : Ni → N′i, link is a function mapping each node to its ancestor (hyper) node at the same level The security labels (consisting of a security level and a category set) are implemented in a HNH as defined below: Definition 3: Implementation of the security level and the category set in a HNH: §a hyper node HNi has a security level of number i §the category set of a hyper node HNi is consisted of all its possible first ancestors The HNH concept is used to construct role and data set hierarchies. The implementation of the role hierarchy (as a HNH) is expressed as following: Definition 4: Implementation of a role hierarchy: •URH ⊆ UR x UR, is a totally ordered hyper node hierarchy of roles (UR) that is also known as a dominance relation (written as ≥ in infix notation) The following definition, which is based on the definition of RBAC1 ([Sandhu, 1998]), provides a redefinition of session-roles and team-roles functions according to the implementation of the role hierarchy in eMEDAC: Definition 5: Redefinition of our model: •session-roles : S → 2R, is a function mapping each session si to a set of roles roles(si) ⊆ {r | ((∃r' ≥ r) [(user(si ), r') ∈ URS]}, which can change with time, and session si has the permissions U r ∈ roles(si) {p | (∃r" ≤ r) [(p, r") ∈ PRS]} and a security level that is the maximum of security levels of roles(si) and a category set that is the union of category sets of roles(si)

10

•team-roles : T → 2R, is a function mapping each team ti to a set of roles roles(ti) ⊆ {r | ((∃ r' ≥ r) [(users(ti ), r') ∈ URS]}, which can change with time, and team ti has the permissions U r ∈ roles(ti) {p | (∃ r" ≤ r) [(p, r") ∈ PRS]} and a security level that is the maximum of security levels of roles(ti) and a category set that is the union of category sets of roles(ti) 7 Activation of Final User Permissions Our approach provides role-based permission assignment and team-based permission activation in order to access particular objects in a short period of time. After the completion of the user identification and authentication process, user has to select a subset of roles from the set of roles assigned to him. According to this selection a particular set of role-based permissions is activated, called session-roles permissions (figure 2). Until this point, our model behaves just like a typical passive-security model, as the current set of permissions is not capable of representing any levels of context when processing an access request on an object. User identification and authentication

Role activation

Team participation T e a m -R o l e s p e r m i s s i o n s

S e s s i o n -R o l e s p e r m i s s i o n s SELECT A FROM … SELEC T B F R O M … …

Team context

SELECT C FROM … SELECT D FROM … …

SetOfPatients: (pid1, pid2, … ) TimeZones: ([str1;end1], [str2;end2], … ) SetOfLocations: (locid1, locid2, … )

COMBINATION R o l e -b a s e d p e r m i s s i o n s SELECT SELECT SELECT SELECT …

A B C D

FROM FROM FROM FROM

… … … …

FILTERING C o n t e x t -b a s e d p e r m i s s i o n s SELECT A FROM …

SELECT B FROM …

SELECT C FROM …

SELECT D FROM …

WHERE AND AND WHERE AND AND WHERE AND AND WHERE AND AND

CurrentPatient IN SetOfPatients CurrentTime IN TimeZone CurrentLocation IN SetOfLocations; CurrentPatient IN SetOfPatients CurrentTime IN TimeZone Cu r r e n t L o c a t i o n I N S e t O f L o c a t i o n s ; CurrentPatient IN SetOfPatients CurrentTime IN TimeZone CurrentLocation IN SetOfLocations; CurrentPatient IN SetOfPatients CurrentTime IN TimeZone Cu r r e n t L o c a t i o n I N S e t O f L o c a t i o n s ;

MDB

Figure ÓöÜëìá! ¢ ãíùóôç ðáñÜìåôñïò áëëáãÞò.– Context-based permissions activation.

After the role selection, the user has to select a subset of teams to participate and gains the additional permissions from the roles activated by other users that currently participating in the same teams. As we have already mentioned before, teams can be seen

11

as groups of current task contexts. As a result, by selecting a team, the user obtains also the context of his task. The team context is consisted of particular data objects and conditions, expressed in terms of ranges of values such as time, patients and location (see figure 2). For every team there are available system variables, capable to hold in them sets of values for our chosen factors. The binding of these variables to actual values is accomplished during the runtime by the administration staff of the hospital. Team contexts can be seen also, as limitations or restrictions on objects and/or on conditions concerning the filtering of the access request, providing in such a way selections of the result sets. The final permission set of a user is filtered by using the context of the current task of his team. Any subsequent user access request is permitted only for the objects included in the context and during the period of his current task. In this way only the medical records of the patients charged to the user's team are accessible during the teamwork. Summarizing the above discussion, the activation of user permission is accomplished in two-step procedure. Step 1: Considering a user who has activated a subset of roles and participates in a subset of teams, initially the role-based permissions of this user are derived with the following definition, where ⊕ means “combined with”: • Role-based Permissions = Session-Roles Permissions ⊕ Team-Roles Permissions Step 2: The final permissions activated are the context-based permissions, which are derived from role-based permissions (step 1) with the following definition, where ⊗ means “filtered by”: • Context-based Permissions = Role-based Permissions ⊗ Team-Context 8 Conclusion In healthcare environments, which are a representative case of collaborative and dynamically changing clinical workflow environments, there is a need for active security permission activation. To address this problem we have stated the dynamic characteristics of clinical activities and we introduced a number of factors that identify clinical tasks for particular patient cases. The specific values of those factors form a context that could identify clinical tasks in a dynamic way. Users, who are involved in a particular clinical task, collaborate for taking care of a particular patient, consisting therefore a care team. The notion of teams is useful for the assignment of a number of different contexts and is used in a similar way as roles. The participation of particular users in teams is based on their assigned roles already defined. The role-based permission set of a particular user is a combination of the permissions of roles of all the users participating in the same team. The final permission set of the user is derived by applying the team context in order to filter the role-based permission set and let only the tuples of particular patients to be accessed during the execution of his task. The advantages of our model are related to minimization of effort for security administrators by using centralized control for frequently changing security metadata. In our future work we intend to develop a selfadministering access control system based on the proposed model.

12

9 References Barkley J., Beznosov K. and Uppal J. (1999) Supporting Relationships in Access Control Using Role Based Access Control, Proceedings of the Forth ACM workshop on RoleBased Access Control, October 1999, Fairfax, VA, USA. Beznosov K., (1998) Requirements for access control: US Healthcare domain, Proceedings of the Third ACM workshop on Role-Based Access Control, October 1998, Fairfax, VA, USA. Castano S., Fugini M., Martella G. and Samarati P., (1994) Database security, Addison Wesley. Dadam P., Reichert M. and Kuhn K., (1997) Clinical Workflows – The Killer Application for Process-oriented Information Systems?, Ulmer Informatik-Berichte, Nr. 97-16. Giuri L. and Iglio P., (1997) Role Templates for Content-Based Access Control, Proceedings of the Second ACM Workshop on RBAC, Fairfax, VA, USA INFOLAB, (2000) Internal Technical Report 03/2000, Informatics Lab., Faculty of Technology, Aristotle University of Thessaloniki, Greece. Khair M., Mavridis I. and Pangalos G., (1998) Design of Secure Distributed Medical database Systems, in Proceedings of 9th International Conference, DEXA’98 (Database and Expert Systems Applications), Vienna, Austria, August 1998, pp.402500. Mavridis I., Pangalos G. and Khair M., (1999) eMEDAC: Role-based Access Control Supporting Discretionary and Mandatory Features, Proceedings of 13th IFIP WG 11.3 Working Conference on Database Security, Seattle, Washington, USA. Lupu E. and Sloman M., (1997) Reconciling Role Based Management and Role based Access Control, Proceedings of the Second ACM Workshop on RBAC, Fairfax, VA, USA NIST, (1995) An Introduction to Role-Based Access Control, NIST CSL Bulletin on RBAC, National Institute of Standards and Technology, available in URL: http://csrc.nist.gov/nistbul/csl95-12.txt NIST, (1999) Role Based Access Control, National Institute of Standards and Technology, available in URL: http://hissa.ncsl.nist.gov/rbac ORA, (1996) Security in Workflow Processes, Odyssey Research Associates, Inc., available in URL: http://www.oracorp.com/Projects/Current/Workflow.html Pangalos G. and Khair M., (1996) Design of a secure medical database systems, in IFIP/SEC’96, 12th international information security conference. Pangalos G., Gritzalis D., Khair M. and Bozios L., (1995) Improving the Security of Medical Database Systems, Information security - the next decade’, J. Eloff and S. Von Solms editors, Chapman & Hall. Pangalos G., Khair M. and Bozios L., (1995) An Integrated Secure Design of a Medical Database System, MEDINFO’95, The 8th World Congress on Medical Informatics, Vancouver, Canada. Pernul G., (1994) Database Security, Advances in Computers, Vol.38, M.C. Yovits (Ed.), Academic Press. Sandhu R. and Samarati P., (1997) Authentication, Access Control, and Intrusion Detection, The Computer Science and Engineering Handbook. Sandhu R., (1998) Role-Based Access Control, Advances in Computers, Vol.46, Academic Press.

13

TCSEC, (1985) Trusted Computer Security Evaluation Criteria, Department of Defense, 5200.28-STD Thomas K. R., (1997) Team-Based Access Control (TMAC): A Primitive for Applying Role-Based Access Controls in Collaborative Environments, Proceedings of the second ACM workshop on Role-based access control, Fairfax, VA USA.

14