Realization of a Context-Dependent Access Control Mechanism on a Commercial Platform

Transcription

1 Realization of a Context-Dependent Access Control Mechanism on a Commercial Platform U. Nitsche Dept. of Electronics and Computer Science, University of Southampton Southampton, SO17 1BJ, United Kingdom, un@ecs.soton.ac.uk R. Holbein, O. Morger, S. Teufel Department of Computer Science, University of Zurich Winterthurerstrasse 190, CH-8057 Zurich, Switzerland, fholbein, omorger, teufelg@ifi.unizh.ch Abstract Recently, context-dependent access control mechanisms were established: Information about the state of a business process is combined with general knowledge about a person to grant or revoke access to sensitive data. Though being understood very well in principle, many different problems arise when context-dependent access control is realized for an application of practical relevance on a concrete platform. We present in this paper the implementation of context-dependent access control for a client-/server-based hospital information system. The system is WindowsNT-based and is implemented with MS Visual Basic on an MS SQL Server database. Additionally there is an Action Technology workflow system that provides the required context information. We will demonstrate how the context-dependent access control can be implemented taking into account the constraints of the given platform. Keywords Context-dependency, access control, business processes, implementation 1 INTRODUCTION In (Holbein et al. 1997) and previous papers (Holbein et al. 1995, Holbein et al. 1996), the concept of a context dependent access-control has been introduced and discussed exhaustively. (Holbein et al. 1997) also presents the implementation of the concepts on an experimental academic platform. It is the aim of cifip Published by Chapman & Hall

2 2 Realization of a Context-Dependent Access Control Mechanism the present paper to prove that the implementation of a context-dependent access control is also possible on a commercial, widely used platform which is lacking some of the experimental platform s features. The current paper does not address the issues of security design according to (Holbein et al. 1996, Holbein 1996). These papers show that context-dependent access definitions are inherent to business process models (BPMs). Moreover these papers show how to address the problem of conflicting roles or role activation conflicts which must be considered during definition of role based access rights already. In context-dependent access control mechanisms, information about the state of a business process is combined with general knowledge about the organizational role of a user to grant or revoke access to sensitive data. The basic concepts of such an access control scheme are understood very well (Holbein 1996). However, when starting with the development of a concrete system facilitated with a context-dependent access control, one faces several minor and major problems: existing access control mechanisms of the given platform have to be adapted to support context-dependency, drawbacks of the platform in order to implement context-dependency have to be overcome, missing but necessary features have to be implemented indirectly, etc. Technological support for the inter-departmental co-operation in hospitals taking into account security concerns is the focus of the Swiss National Science Foundation granted project MobiMed (Fischer et al. 1995). The hospital information system discussed in this paper was and still is developed in the MobiMed project. The overall system will be used as a prototype within the Clinical Research Centre of the University Hospital of Basel in order to demonstrate the potentials of IT-support in a hospital. It is PC-based (Windows NT) and implemented in MS Visual Basic accessing MS SQL Server. The context information which is used for the evaluation of whether to grant or revoke data access to a user dynamically, is delivered by an Action Technology workflow system, which builds the core control component of the implementation. We discuss in the present paper our implementation solution for a contextdependent access control for the platform described above. After a short introduction into context-dependent access control, we present the different components of our system, including a discussion of the interfaces. Then we present the implementation of the context-dependent access control mechanism. Finally, we conclude by briefly discussing our experience with the access control mechanism, its suitability to the application area of a hospital and the platform of our implementation respectively. MobiMed (Privacy and Efficiency of Mobile Medical Systems) is a project of the Swiss Priority Programme (SPP) for Information and Communications Structures (ICS; ) of the Swiss National Science Foundation (SNSF) aiming at the development of mobile access to data in a clinical environment. Its contributing members are the Computer Science Department of the University of Zurich, the Gastroenterological Department of the University Hospital of Basel, Triangle Micro Research AG, Liestal, and Plattner Schulz Partner AG, Basel.

3 Context-Dependent Access Control 3 2 CONTEXT-DEPENDENT ACCESS CONTROL Role based security approaches fit well the hierarchically structured setting of a hospital (Ting et al. 1991, Ting et al. 1992). Each level in the hierarchy can be mapped to a so called organizational role that a person plays in the hospital (e.g. medical personnel, care personnel, etc.). After an analysis of each role s demands on obtaining particular data to perform work, access rights are assigned to each role. The access rights determine which records in the database that contains information about the patients (patient records) may be read, written, or changed by a person playing a particular role. When logging in, a person identifies herself or himself by, for instance, using a chipcard and a PIN, and then a role is assigned to the person according to user/ role lists, determining her or his access rights. Simple role based access control mechanisms have the advantage of being implementable rather easily but the drawback of certain inflexibilities. A more sophisticated access control technique refining the role based approach takes into account the question of whether it is reasonable that a person playing a particular role needs access to certain data, for instance at the current state of a health care process. Obviously, it is not necessary to have access to all data about a particular patient all the time. The question of what does one need-to-know? gave the considered principle its name: the need-to-know principle. Moreover, what does one need-to-know right now (at the time of an access request) is the context-dependent access control scheme that we consider in this paper. A possible realization of the need-to-know principle can be achieved by combining user role information with state information of a workflow ( Is it reasonable to grant access to a person (playing a particular role) in the given workflow state? ). A workflow system which can be used to determine context-information is the Action Workflow approach (Medina-Mora et al. 1992). From a generic point of view the conceptual overview of our comprehensive context-dependent access control system consists of two parts as presented in Figure 1: First, there is a security design subsystem that is connected to the access control system for administration of access rights according to a need-to-know policy. The security design system includes a number of interfaces that allow to import business models, e.g. business process models (BPM), to automatically derive security information and to establish need-to-know security models (Holbein et al. 1996, Holbein et al. 1996). These need-to-know security models can be exported to a number of access control systems. Again, there are interfaces that translate the security model to specific access control information that can be interpreted by the target system. Second, there is a context authentication subsystem which can be linked to different access control systems (ACS). In general, it is very useful when BRS and BAS (see Figure 1) are interrelated (e.g. it simplifies implementation), for example workflow management systems (WFMS; in our case the WFMS is

4 4 Realization of a Context-Dependent Access Control Mechanism Business Representation System (BRS) 1...n, e.g. Business Process Modelling BRS Interface 1...n Business Automation System (BAS) 1...n, e.g. Workflow Management BAS Server Interface 1...n Universal Security Design (Sub-)System Context Authentication (Sub-)System ACS Interface 1...m Management Interface Administration of Access Rights ACS Client Interface 1...m Context Authentication Hook Evaluation of Access Requests Access Control System (ACS) 1...m Figure 1 Conceptual overview of the access control system. the Action Workflow system, AWS) that usually include a business process modelling component as well as a workflow control engine (AW Administrator). However, this is not necessary in principle. 3 REALIZATION OF THE CLIENT-/SERVER-SYSTEM Our target for implementing context-dependent access control is a workflowbased client/server solution for the technological support of nursing as well as medical and administrative duties in health care environments, i.e. our solution follows the idea of a WFMS-based solution as mentioned in the previous section. The server s database contains information on both, the patient record as well as the current state of the patient s examination and treatment which we would like to call a health care process. This means, there is a common database management system (DBMS) for both, the hospital information system as well as the WFMS. This SQL-database also handles access rights of users and performs access controls. Each state in a health care process determines who has to perform what next. An add-on workflow engine keeps track of these states and controls health care processes. Medical data is stored directly in the database; process information is stored there via the workflow engine. Control is given completely to the workflow engine which may trigger additional programs to collect or update data in a patient s record. Clients are, in a simplified picture, terminal applications to access information about patient records and tasks of clinical staff. A user logs in and, depending on his/her role in the hospital s hierarchy as well as involvement in certain health care processes, receives information about pending duties, may enter information according to his/her current tasks, and may access information necessary to do his/her actual work. In accordance to developments in the EU project EXODUS (Francis et al. 1997), these clients will run

5 Realization of the Client-/Server-System 5 Client (on which the applications are running) flat LCD screen (high resolution) keyboard terminal fixed to the hospital bed to the network trigger application program Server SQL Database Workflow Engine outside interactions Figure 2 The hospital bed unit (HBU). on a personal computer that is fixed to a hospital bed. Hospital beds plus their PC units are called mobile hospital bed units (HBU). HBUs can be moved all across the hospital and connected to the network at different physical locations. Such an HBU and the server platform to which it establishes a connection are presented in brief in Figure 2. The client platform at the HBU is a WindowsNT Workstation. The client software is written in MS Visual Basic. The server platform is also WindowsNT running an Action Technology workflow system (the AW Administrator) as well as an MS SQL Server database system containing both, the patient records as well as the complete workflow information (AW Administrator is added on the MS SQL Server). The MS Visual Basic client applications are the parts of the system which access the patient records in the MS SQL Server database. What remains is to adapt this system configuration to the requirements of the context-dependent access control scheme described in the previous section. We present how context-dependent access control can be realized for our given platform. To do so, we have to find a solution for adapting the given MS SQL Server security mechanisms that allows to include contextdependency for access control decisions, i.e. the CARDS component as introduced in (Holbein et al. 1997). MS SQL Server uses a user and a group concept to grant or revoke access to tables or even table entries. This concept is explained in Figure 3 showing a detail of a patient record. Figure 3 denotes

6 6 Realization of a Context-Dependent Access Control Mechanism inherit access rights of group care personnel to group medical personnel by making it a subgroup of group care personnel grant access to table "Department/Room" to group care personnel Department/Room InvestigationDept/A401 MedicineI/B323 MedicineI/B311 Radiology/Lab1 Type of Examiniation Gastroscopy Gastroscopy Coloscopy Gastroscopy grant access to table "Type of Examination" and to table "Department/Room" to group medical personnel Figure 3 The group and inheritance concept of MS SQL Server. that only care personnel has access to column Department/Room (the department and room where the patient is located) whereas medical personnel only has access to column Type of Examination (indicating what examination has to take place with the patient). Neither members of group care personnel can access column Type of Examination nor can members of group medical personnel access entries in column Department/Room (the solid lines). By making a group a subgroup of another group, access rights can be inherited. Figure 3 in addition shows how the peculiar situation of medical personnel not having access to column Department/Room can be overcome by inheriting the access rights of group care personnel (the dashed lines). Users are assigned to groups according to their organizational roles in the hospital. The first constraint we have to consider for our real world environment is that the group assignments in a given hospital should not be changed, meaning that the access rights to existing tables for which no context-dependent access control is established should be left unchanged. On the other hand, for the tables in the database containing highly sensitive medical data (the patient records; the database containing the patient records is called MobiMedDB), context-dependent access control is to be established, implying that for none of the existing groups access is granted a priori to MobiMedDB. This is very important to note. Access rights are only given temporarily to users for a single access. Hence we generate a new group which we call MobiMedDBAccessGranted. No user and no group is assigned to the group MobiMedDBAccessGranted initially and permanently. To change the group membership of a user temporarily, we can use the SQL stored procedure named sp change group which exactly changes the group membership of a user. This is how we add context-dependency to access control decisions. After checking the need-to-know of a user to perform an access (Holbein et al. 1997), he or she receives temporary membership in the group MobiMedDBAccessGranted, the access is performed, and the group membership of the user is reset to the previous one. To perform the SQL stored procedure sp change group access rights of the SQL Server s administrator are needed. These could not be granted if the context-dependent access control itself were implemented as an SQL stored procedure. Hence we decided to implement it as a DLL (dynamic link li-

7 Realization of the Client-/Server-System 7 trigger application User (Application) access request 1 get request s results 7 2 get context information AW Administrator 2 2 DB query AWS DB (Workflow Data) Dynamic Link Library evaluate access rights using context information 4 and user role 3 get user role set user to group MobiMedDBAccessGranted perform DB query 6 reset user to old group MS SQL Server 7 7 MobiMed DB (Patient Data) Figure 4 How are access rights assigned to a user? brary) on the server. The DLL offers the only way to access the MobiMedDB database and can be linked to any application program. Hence, our technical solution for implementing a context-dependent access control for the database MobiMedDB on the given platform consists of the following steps (refer to Figure 4): 1. An application (started by a user or triggered by the workflow system) sends an access request to the server via the dynamic link library (DLL). 2. The DLL requests and receives from the AWS context information about the workflow of the patient whose record is intended to be accessed. 3. The DLL requests and receives role information about the user who is requesting the access from the MS SQL Server s registry. 4. Both, the context information and the role information are combined and the authority of the user to perform the access (depending on whether it is a read or a write access) to the patient record is evaluated. In the following it is assumed that the user has authority to perform the request (otherwise the request would be rejected at this point). 5. The user is set temporarily to group MobiMedDBAccessGranted. 6. The request (query) is performed on the database MobiMedDB.

8 8 Realization of a Context-Dependent Access Control Mechanism 7. The results of the query are delivered to the application. 8. The DLL resets the user to his/her previous group. Now we will present an access control trial that illustrates how success or failure of access requests depends on the current state of the health care process. For that reason, we consider a nurse s opportunity for misuse of MedicalHistory information. Herein we explain the influence of process states on the evaluation of an access request that corresponds to the need-to-know access right. We have to keep in mind that a person who is assigned to the nurse role is also assigned to all functional roles that correspond to the business transactions where the nurse role occurs. According to our example this is the business transaction called GastroCycle. That means, a nurse s need-toknow access rights concerning a patient s medical history are restricted to the GastroCycle within the Health Care process. We consider the following scenario: the user Maggi Smith was assigned to the Nurse role as well as the functional role that was defined according to the GastroCycle business transaction. Now, we assume Maggi Smith has activated the Nurse as well as GastroCycle roles and sends a request for read access concerning the MedicalHistory SamBrown information object to the access control system. This object is an instance of class MedicalHistory where the information owner is a person named Sam Brown. Obviously, the first step of evaluating the access request succeeds because an appropriate role based access right exists. However, within the access right there must be a context authentication for successful evaluation of the access request. In order to explain the possible evaluation results we consider the following four states of the workflow engine concerning the actual business transactions: 1. A Health Care process instance exists, GastroCycle is the current business transaction within this process and a person named Sam Brown acts as customer within the Health Care process. 2. A Health Care process instance exists and a person named Sam Brown is the customer but GastroCycle is not the current transaction within this process, i.e. must currently not be accomplished or has already been accomplished. 3. One or more Health Care process instances exist but Sam Brown is not the customer within one of these processes. 4. No Health Care process instance exists. Now it is important to note that although a role based access right exists the only case where the access request succeeds is the first. The access control trial shows that the nurse s opportunity for misuse of personal information can be restricted if a context authentication is part of the evaluation procedure. The context authentication ensures that the access request succeeds in case of a current need-to-know but not at any time.

9 Discussion 9 4 DISCUSSION Taking into account that the group MobiMedDBAccessGranted is an empty group in the MS SQL Server s registry, it is obvious that access to the MobiMedDB database can only be granted by the DLL described in the previous section. Although this is quite simple, we still have to discuss whether the presented implementation is feasible with respect to administration of the access control system and its concrete application. First of all, protecting the DLL properly is very important (the DLL knows the administrator log in procedure of the MS SQL Server to be able to perform the sp change group stored procedure). Since the DLL is kept on the server containing the database system rather than being distributed on several client platforms, protecting the DLL is not difficult. The only drawback is that whenever the system administrator password (the password of user sa ) of the MS SQL Server is changed, the DLL has to be recompiled by the system administrator. Though not being the most comfortable solution, its administration is not complicated. So we claim that the presented solution is both, simple and feasible. There is only one solution that we would prefer: the implementation of the DLL s functionality as an SQL stored procedure. However this is not possible given the constraints of the platform we consider. Considering the example presented at the end of the previous section, only in a few of many possible situations access is granted to a request. One can easily figure out that a very careful design of the workflow which delivers the context information is necessary in order to avoid errors in the access control mechanism. To be sufficiently cautious in order to handle possible design errors like incorrect context information for the need-to-know access control, one would have to implement an emergency mechanism to bypass the need-to-know principle, for instance by running a simple role based access control mechanism, which has to be recorded very carefully in a log file to keep its potential misuse ascertainable. 5 CONCLUSION We have presented a concrete implementation of context-dependent access control that realizes the need-to-know principle. Taking into account the constraints determined by a given platform (WindowsNT, MS SQL Server, MS Visual Basic, Action Technology workflow system) we have shown that a context-dependent access control indeed can be implemented for such an environment even if the required mechanisms are not built in these products. We have not considered questions of performance and user acceptance. These questions will be answered after installing a prototype system at the University Hospital of Basel and thoroughly analysing its benefits and drawbacks. We would like to thank Prof. Dr. K. Bauknecht for the support that made this work possible.

10 10 Realization of a Context-Dependent Access Control Mechanism 6 REFERENCES J.C. Francis, D.V. Polymeros, G.L. Lyberopoulos, V. Van de Keere, A. Elberse, P. Rogl, and L. Vezzoli. Project EXODUS: Experimental mobile multimedia deployment in atm networks Submitted to the Journal of the ACM. H.-R. Fischer, S. Teufel, Ch. Muggli, and M. Bichsel. Privacy and Efficiency of Mobile Medical Systems (MobiMed). Technical report, Bewilligtes Forschungsgesuch des Schwerpunktprogramms Informatikforschung SPP IuK, Modul: Demonstrator, Nr , R. Holbein. Secure Information Exchange in Organizations. PhD thesis, University of Zurich, Switzerland, Shaker Verlag, Aachen. R. Holbein and S. Teufel. A context authentication service for role based access control in distributed systems CARDS. In J.H.P. Eloff and S.H. von Solms, editors, Information Security the Next Decade IFIP/SEC 95. Chapman & Hall, London, UK, R. Holbein, S. Teufel, and K. Bauknecht. A formal security design approach for information exchange in organisations. In D.L. Sponner, S.A. Demurjian, and J.E. Dobson, editors, Proc. 9th IFIP TC11 Annual Working Conference on Database Security Chapman & Hall, London, UK, R. Holbein, S. Teufel, and K. Bauknecht. The use of business process models for security design in organisations. In S.K. Katsikas and D. Gritzalis, editors, Information Systems Security Facing the Information Society of the 21st Century IFIP/SEC 96. Chapman & Hall, London, UK, R. Holbein, S. Teufel, O. Morger, and K. Bauknecht. A comprehensive needto-know access control system and its application for medical information systems. In L. Yngström and J. Carlsen, editors, Information Security in Research and Business IFIP/SEC 97. Chapman & Hall, London, UK, R. Medina-Mora, T. Winograd, R. Flores, and F. Flores. The action workflow approach to workflow management technology. In Proceedings of the Conference on Computer-Supported Cooperative Work (CSCW 92), pages , Toronto, ACM Press. T.C. Ting, S.A. Demurjian, and M.-Y. Hu. Requirements, capabilities, and functionalities of user-role based security for an object-oriented design model. In C.E. Landwehr, editor, IFIP WG 11.3 Workshop on Database Security, pages , Sheperdstown, West Virginia, Elsevier. T.C. Ting, S.A. Demurjian, and M.-Y. Hu. A specification methodology for user-role based security in an object-oriented design model. In B.M. Thuraisingham and C.E. Landwehr, editors, IFIP WG th Working Conference on Database Security, pages , Simon Fraser University Burnaby, Vancouver, British Columbia, Elsevier.

11 Biography 11 7 BIOGRAPHY Ralph Holbein studied information science and computer science, receiving a Dr. phil. from the University of Zurich, Switzerland, in He is working in industry as an IT-Security Manager as well as a guest scientist at the University of Zurich, Switzerland. Major research interests: Security, Workflow Management Systems, and CSCW. Othmar Morger studied computer science and economics. From the University of Zurich, Switzerland, he received a lic. oec. publ. in He is working in industry as a Business Analyst as well as a guest scientist at the University of Zurich, Switzerland. Major research interests: CSCW, Workflow Management, Security, and Economical Aspects of Computer Science. Ulrich Nitsche is a lecturer at the Department of Electronics and Computer Science of the University of Southampton, United Kingdom. He was a research assistant at the University of Zurich, Switzerland, from 1996 to 1998 and a junior scientist at GMD TKT Darmstadt, Germany, from 1991 to Under a DAAD HSP II/AUFE fellowship he visited the University of Liège, Belgium, in He studied computer science and physics and received a Dr. phil. nat. from the University of Frankfurt, Germany, in March For a joint paper with Pierre Wolper he won the best student paper award of ACM PODC 97. Major research interests: Verification, Formal Methods, Security. Stephanie Teufel studied computer science at the Technical University of Berlin and the Swiss Federal Institute of Technology (ETH), Zurich. Assistant researcher at the Department of Computer Science between 1987 and 1991, where she received her Doctor s degree in May Between 1989 and 1990 teaching fellow and lecturer at the University of Wollongong, Australia. Since 1991 Senior Researcher and lecturer at the Department of Computer Science of the University of Zurich. Major research interests: Information Systems, Security, Information Management, and CSCW.