Access Control in e-Health Portal Systems
Descrição do Produto
Access Control in e-Health Portal Systems Shuo Lu, Yuan Hong, Qian Liu Department of Computer Science Concordia University 1455 de Maisonneuve Blvd. West, Montreal, Quebec, Canada {lu_shuo, y_hon, liu_qian}@cs.concordia.ca
Abstract Many e-Health portal systems are implemented using off-the-shelf software components. The security features provided by such components are usually insufficient. This paper addresses the issue from the access control perspective. More specifically, we first propose a two-tier approach to access control for eHealth portals. The approach supplements existing Role Based Access Control (RBAC) capabilities with a rule-based access control module based on the classical Flexible Authorization Framework (FAF) model. We study conflict resolution and interaction between the two modules. We also address authentication for real-time services provided by remote service providers.
1. Introduction Security is critical to e-Health systems since a security breach may threaten a patient’s privacy (leakage of private information), his/her health (improper use of medical services), or even life (malicious modification of diagnosis data). As a key security component, access control ensures any service to be only accessible to legitimate users with appropriate privileges. e-Health systems naturally demand fine-grained control of accesses. For example, the access to a real-time ECG (Electrocardiograph) monitoring service should be granted to only previously registered patients at the appointment time. Unfortunately, the role-based access control (RBAC) module adopted by many off-the-shelf software components can only enforce temporal constraints, such as the duration of an appointment, on each role but not on a per-user basis. To enforce user-specific constraints will require a role to be created for each
978-1-4244-1841-1/08/$25.00 ©2008 IEEE
Lingyu Wang, Rachida Dssouli Concordia Institute for Information Systems Engineering Concordia University 1455 de Maisonneuve Blvd. West, Montreal, Quebec, Canada {wang, dssouli}@ciise.concordia.ca
user, which diminishes the value of RBAC in simplifying security administration. In this paper we adopt a two-tier approach to address the above issue. More specifically, we take advantage of the existing RBAC capability and supplement it with a rule-based access control module. The role activated by a user determines which services are visible to him/her, but whether the user can actually use the service depends on other conditions specified in applicable rules, such as temporal constraints. We address the potential conflict and interaction between the two access control models. We also investigate how authentication can be enforced for real-time services that bypass portal servers and are provided by remote service providers. The rest of this paper is organized as follows. Section 2 reviews related work. Section 3 describes an architecture for e-Health portals. Section 4 studies access control of such systems. Section 5 addresses implementation options. Section 6 concludes the paper.
2. Related Work The increasing demand for e-Health services has led to many research efforts [1]. Different architectures have been proposed for e-Health or other healthcare purposes, such as the European pre-standard HISA (Healthcare Information System Architecture) based on CORBA or DCOM middleware [2], the SAMTA architecture [3], the Telemedicine System Interoperability Architecture [4], the distributed webbased telemedicine system architecture [5], and the SOA-based e-Health services architecture [6]. Instead of pursuing such special-purpose architectures, this paper studies a general e-Health portal that focuses on the integration of existing healthcare systems, applications, and services. The security and privacy issue of e-Health systems has attracted significant attentions, as reviewed in [7].
The confidentiality of medical records and its implication on patients’ privacy is addressed by law [8]. This paper will focus on the access control aspect of e-Health portals, which have not been thoroughly studied to our best knowledge. On the other hand, as an important security component, access control has received comprehensive studies in generic information systems. Various abstract models of access control exist, such as the access control matrix, access control list, and capability list model. Traditional policy-dependent access control models include discretionary access control (DAC) in which accesses are assigned by the owner of objects, mandatory access control (MAC) in which accesses are based on security clearances and levels. Policy-neutral access control models and mechanisms also exist, such as the role-based access control (RBAC) that leverages roles to simplify access control administration [9] and the Flexible Authorization Framework (FAF) that uses meta-policies for conflict resolution and policy derivation [10]. Our work is based on a combination of RBAC and FAF and we shall focus on their applications to e-Health portals.
3. Architecture Design Figure 1 illustrates the proposed architecture for eHealth portals (notice that we shall delay the discussion of the access control aspect to later chapters). In our design, the e-Health portal is a webbased application that integrates various medical services (such as Blood Pressure monitoring and ECG monitoring services as shown in Figure 1) provided by multiple hospitals and other medical organizations. An end user, such as a patient or doctor, directs a web browser to the portal server. The portal server displays a webpage, namely, portal interface to the user. The portlets inside each portal interface correspond to a collection of correlated services provided by medical organizations. The user may trigger various actions of a service by clicking on corresponding buttons encapsulated in a portlet (real-time applications, such as ECG monitoring, will bypass the portal server due to a more rigid performance constraint; other non realtime services may expose their interfaces as web services which are published and can be discovered via UDDI (Universal Description, Discovery and Integration). Our design provides a uniform and easy-to-use interface to users by hiding implementation details of services and their providers. It also enables single signon (SSO) for backend and remote services. Moreover, the design also simplifies the administration and maintenance of services at medical organizations,
because the presentation layer (that is, the portal server) is separated from the implementation layer (that is, medical organizations).
Figure 1. An Architecture for e-Health Portal
4. Access Control for Portal Servers Section 4.1 first describes the limitation of off-theshelf products in their RBAC capabilities and then proposes a solution based on a two-tier approach to access control. Section 4.2 studies interactions between the two tiers. Finally, Section 4.3 discusses authentication for remote real-time services.
4.1. Two-Tier Access Control Many e-Health portal systems are built with off-theshelf software components, such as BEA WebLogic [11] used in our implementation. As a widely accepted standard, the role-based access control (RBAC) is typically a built-in feature of those softwares and can usually meet the basic security requirements of simple applications. However, such RBAC features become insufficient once applied to a complex environment like an e-Health portal (notice that the limitations we shall describe are about the implementation of RBAC, but not in the RBAC model itself [9]). An e-Health portal naturally demands access control capabilities that go beyond the limited support of RBAC found in commercial software components. First, accesses to medical services are usually subject to conditions that depend on specific users instead of roles. For example, the real-time ECG monitoring service can only be accessed by a registered patient during his/her appointment time. Enforcing the first half of the requirement, that is only a registered patient can use the service, is straightforward with RBAC. An administrator can create a role named ‘registered patient’, and assign the permission to use the service to this role. Any user must thus activate the role in order to use the service. However, to enforce the second half of the
requirement, that is the service can only be accessed during an appointment, is not as simple because appointment time is unique for each patient. Such a user-specific requirement can be handled by constraints in the original RBAC model [9]. However, as an add-on feature of RBAC, constraints receive only limited support in many built-in RBAC modules. For example, WebLogic only allows constraints to be specified for roles. In order to accommodate a userspecific constraint, such as a patient’s unique appointment time, a separate role may have to be created for every user, which leads to too many roles and essentially diminishes the value of RBAC. Second, some medical services may be intended for public accesses by any user with only a few exceptions. That is, they are controlled by an open policy where accesses are by default allowed unless explicitly denied. The negative permissions required for denying accesses are supported in the RBAC model through constraints [12]. However, the co-existence of both positive and negative permissions raises some subtle issues like conflict resolution. The support for RBAC constraints found in many commercial software components is typically insufficient for dealing with such issues. To remove the limitation of existing RBAC modules, we adopt a two-tier approach as shown in Figure 2. We leverage the existing RBAC capability and supplement it with a rule-based access control module. The RBAC tier provides coarser-grained control by assigning users to roles and roles to portal interfaces (that is, collections of portlets). The rulebased access control tier provides finer-grained control through user-specific conditions expressed in logic rules. Informally, the RBAC tier determines whether a user can see a requested service, whereas the rulebased access control tier determines whether the user can use the service in a specific way. To trigger an action, such as starting a service, a user must first activate an appropriate role, so RBAC will direct the user to a portal interface containing the requested portlet (service). After the user clicks on an action button on the portlet, the rule-based access control engine verifies the legitimacy of this request against applicable rules stored in the rule repository. Potential conflicts between positive and negative permissions are resolved based on predefined meta-policies, as we shall discuss in more details shortly. This design choice of using a two-tier model has advantages over other alternatives. First, we can certainly stick to the RBAC model and supplement the existing module with full-fledged support for constraints. However, this is possible only if the existing RBAC module is fully extensible, which is
usually not the case with commercial softwares. Moreover, the administration of access control rules is usually less intuitive than with roles. Completely discarding RBAC may thus render access control less manageable. Third, we can let the portal server to simply pass the responsibility of access control to backend services. However, this diminishes the very advantage of using a portal server, such as the central control of accesses.
Figure 2. Two-Tier Access Control To express fine-grained access control requirements as rules, we apply the classical Flexible Authorization Framework (FAF) [10] to our design of e-Health portals. FAF employs stratified first-order logic to represent access control rules, which gives it a welldefined semantics. User-specific conditions can be represented as a single rule with variables, which will be instantiated on the fly for each request. Logic inferences based on pre-defined meta-policies can easily handle conflict resolution between positive and negative permissions. We extend FAF rules by defining application-specific predicates and metapolicies that are especially suitable for e-Health portals. We now demonstrate our approach through two scenarios. Scenario 1 shows how we represent user-specific conditions using a single rule with variables. Scenario 2 illustrates conflict resolution with a denials-take-precedence meta-policy. Scenario 1 (User-Specific Condition) Real time ECG monitoring can be started by users who have appointed with the service, with the appointment request approved, and with the start time of the service within the appointed time range. We use a closed policy as follows. cando(o, s, +start) ← typeof(o, ECG-Monitoring), hasAppointed (s, o), status(o, approved), timeValid(o, begin, end), serviceMode(o, real-time) do(o, s, +start) ← cando(o, s, +start) do(o, s, -start) ← ﹁ do(o, s, +start) The first rule states that a service o can be started by a user s if o is an ECG-Monitoring service, o has been
appointed for the user and approved (by a coordinator), the service mode is real-time, and the current server time is between the appointed time scope. The next two rules state that a user’s request for starting the service will be granted if he/she has a positive authorization (given by the first rule), and he/she will be denied if such a positive authorization is absent. That is, a closed policy is enforced. Clearly, this single rule is enough for regulating accesses to the service by any number of users. The rule will be instantiated by each user upon his/her request at run time. Scenario 2 (Conflict Resolution) A medical survey is conducted to investigate the relationship between blood pressure and living locations in Canada with the participants age between 40 and 60 except those who live in Yukon. We specify both positive and negative permissions and a meta-policy for denials-takeprecedence: cando(Survey-LS, s, +submit) ← ageBetween(s, 40, 60), CountryLocation(s, Canada) cando(Survey-LS, s, -submit) ←CountryLocation(s, Canada), ProvinceLocation(s, Yukon) do(Survey-LS, s, + submit) ← cando(Survey-LS, s, + submit) ,﹁ cando(Survey-LS, s, - submit) do(Survey-LS, s, - submit) ← ﹁ do(Survey-LS, s, + submit) The first rule states that the people who live in Canada and whose ages are between 40 and 60 are authorized to complete the survey. The second rule states that those who live in Yukon, Canada are not allowed participating in the survey. Conflicts will arise for those who satisfy both rules. To resolve such conflicts, the next two rules together enforce the denials taking precedence meta-policy.
4.2. Consistency between the Two Tiers The two-tier approach allows us to inherit the advantage of both RBAC (such as the ease of administration) and rule-based access control (such as the support for conflict resolution). However, we need to consider potential inconsistency that may arise between the two tiers. For example, a user’s role may allow him/her to see a portal interface but some rules disallow his/her requests for using a service on that portal interface. This situation is quite normal (the reason of the denial may be, say, the absence of an appointment). On the other hand, a user may be allowed to use a particular service by the rule-based access control but at the same time he/she is denied for accesses to the portal interface containing the corresponding portlet (service). This second situation
is not desirable because the user will not be able to use a service if he/she cannot even see it. To model the phenomenon that a user must be able to see a portal interface before using any of the services contained by the portal interface, we define a partially ordered set (poset) < P ∪ A ∪ I , ≤> where P denotes the set of portlets, A the set of actions on portlets, and I the set of portal interfaces. The relation ≤⊆ P × A × I is defined so that i ≤ ( p , a ) holds for each portal interface i, every portlet p on i, and every action a on p. That is, any action on a portlet dominates portlet interfaces that contain the portlet. We incorporate this partial order on authorization objects into our system through enforcing a consistency checking as follows. For each positive permission on any action a on a portlet p, at least one of the portal interfaces i dominated by (containing) the portlet p must be accessible according to current RBAC policies. The condition is enforced upon adding a positive permission in the rule-based access control tier and upon removing a user-role or role-permission assignment in the RBAC tier (an inconsistency between the two tiers can arise in those cases).
4.3. Real-Time and Remote Services While authentication for normal services in a portal server is straightforward, some issues arise for realtime services, such as telemonitoring, provided by a remote portal. Real-time multimedia services may have a stringent requirement for performance that requires connections to be directly established between clients and the multimedia server. However, delegating authentication to the multimedia server is not always feasible because the server would need to store a copy of portal user accounts, which implies too much trust on the server. Similarly, business policies may prevent the authentication of users from being delegated to a remote server governed by another portal. Our solution for authentication for remote real-time services is to set up a Kerberos realm for each portal and its services. We integrate the Kerberos client-side code into an applet to accommodate the fact that many patients may not possess the skills required for installing a client-side application. The applet performs functions required by Kerberos authentication, such as generating secret keys using one-way function computed over passwords input by the user. Figure 3 illustrated our solution. A patient wants to perform the ECG monitoring service provided by hospital A under the supervision of the cardiologist. The patient logins to the portal server A and the browser transparently downloads the applet, which follows the standard Kerberos protocol to obtain a service granting ticket
for accessing the (local) service. On the other hand, the cardiologist-side applet connects to its local Kerberos server (Realm B) to obtain a ticket from the remote TGS of the Kerberos server (Realm A) and then uses that ticket to access the remote service.
access control extension. This design inherited the advantage of both models and was cost-efficient. For remote and real-time services, we proposed a solution based on inter-realm Kerberos authentication. As future work, we will extend rule-based access control engine to enforce authorization of workflow-based services.
Acknowledgements. This material is partially supported by Natural Sciences and Engineering Research Council of Canada under Discovery Grant. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the sponsoring organizations. The authors are grateful to the anonymous reviewers for their valuable comments. Figure 3. Authentication with Kerberos
5. Implementation Our e-Health system is deployed on the BEA WebLogic Portal server version 8.1. This product provides enterprise portal infrastructure for the ease of management and administration. In our prototype eHealth system, we integrate several demo services. First, we simulate a real-time ECG monitoring service. The client side is an applet based on the ECGSYN toolkit with message transmission and Kerberos features integrated. Second, we implement web-based services for BP monitoring and medical news. The BP value criteria are based on the US National Library of Medicine and American Medical Association Report. Finally, the EPR system and teleconsultation service are two standalone systems, which are implemented as separate components of this project. We implement the logic inference component of our rule-based access control engine using SICStus prolog and integrate this component via the SICStus Java extension. Our access control engine will expose its function as a web service so it can be invoked by other components of the portal. We set up Kerberos realms using the MIT’s Kerberos V5 implementation and authenticate users using JDK1.5 through Generic Security Services API.
6. Conclusion This paper studied the access control aspect of eHealth portals. We first presented a service-oriented architecture for such portals. We then pointed out limitations found in the access control module of many off-the-shelf software components. Our solution was based on a two-tier access control architecture that integrated existing RBAC modules with a rule-based
References [1] G. Kaur and N. Gupta, “E-Health: A New Perspective on Global Health,” Journal of Evolution and Technology, 15(1):23-35, 2006. [2] J.R. Scherrer and S. Spahni, “Healthcare Information System Architecture (HISA) and its Middleware Models”, Proc. AMIA Symposium, 1999. [3] SAMTA project. http://samta.offis.de/. [4] The Telemedicine System Interoperability Architecture. http://telemedicine.sandia.gov/. [5] Y. Xiang, Q. Gu and Z. Li, “A distributed framework of Web-based telemedicine system,” Proc. 16th IEEE Symposium on Computer-Based Medical Systems, pp. 108-113, 2003. [6] W.M. Omar and A. Taleb-Bendiab, "E-Health Support Services Based on Service-Oriented Architecture," IEEE International Conference on Services Computing, pp. 135-142, 2006. [7] R. Barrows, “Privacy, confidentiality, and electronic medical records,” Journal of American Medical Informatics Association, 13(2):139-48, 1996 [8] “Health Insurance Portability and Accountability Act,” United States Public Law, 104-191 [9] R.S. Sandhu, E.J. Coyne, H.L. Feinstein, and E. Youman, “Role-based access control models,” IEEE Computer, 29(2):38-47,1996. [10] S. Jajodia, P. Samarati, M.L. Sapino, and V.S. Subrahmanian, “Flexible support for multiple access control policies,” ACM Transactions on Database Systems, 26(4):1-57, Dec 2001. [11] BEA WebLogic, available at http://www.bea.com/ [12] R.S. Sandhu, “Issues in RBAC,” ACM Workshop on Role-Based Access Control, 1995
Lihat lebih banyak...
Comentários