This paper describes an application of authorization and access control based on ... including identification/authentication as well as digital signature functions.
- . #/
!"#$ %&' && ()'(&(
0 "12 3 & %&' 34& '
* +,*
- * + *
%&' && ()' &)
* +,*
term trust is usually employed for characterising the reliance of business actors and consumers on other actors or on IT systems. Trust covers a variety of issues including accountability, privacy, authenticity and safety.
ABSTRACT This paper describes an application of authorization and access control based on the Role Based Access Control (RBAC) method and integrated in a comprehensive trust infrastructure of a health care application. The method is applied to a health care business process that involves multiple actors accessing data and resources needed for performing clinical and logistics tasks in the application. The notion of trust constituency is introduced as a concept for describing the context of authorisation. In addition, the applied RBAC covers time constraints, hierarchies and multilevel authorization rules for coping with the multi-actor nature and the complexity of the application domain. The DRIVE RBAC model clearly distinguishes between static role assignment to users and dynamic allocation of roles at session time. The paper, while focusing on the authorization and access control approach, also describes how the RBAC functions have been integrated in a trust infrastructure including smart cards.
The health care domain is being revolutionised by the use of information and communication technologies to increase efficiency of health care provision whilst increasing safety of patients and reducing overall costs. This vision cannot however be realised without appropriate trust in the business processes and the information infrastructure. In particular the health domain has the following characteristics that strongly impact the need for a coherent but flexible approach to authorization management and access control: •
Health care provision is a complex knowledge intensive process. A large number of different actors from a variety of organizational entities create value on assets by participating in different tasks (diagnosis, therapy prescription, therapy validation, drug administration, drug data provision, etc) in the process.
•
Privacy has always been an important requirement in health care applications but gets a new dimension within a virtual health care enterprise environment in which critical data can cross established trust boundaries (e.g. crossing the physical boundaries of a hospital ward) due to distributed responsibilities and remote access. Privacy protection requirements can only be satisfied if they are consistently (but not necessarily uniformly) applied throughout the whole business process.
•
The safety dimension is of prime importance in health care. Adverse clinical events can be reduced by IT enhanced business process support. It is important that the HC professional has access to context dependent information drawn from different steps in the process to perform consistency checks at the point of care (e.g. checking potential drug interactions or matching patient therapy prescription and drug related data). In addition the integrity of critical needs to be preserved.
Categories and Subject Descriptors J.3 [Life and Medical Sciences]: Medical Information Systems
General Terms: Security Keywords: Role Based Access Control (RBAC), trust infrastructure, secure health care system 1.
!"#$
INTRODUCTION
Authorization and access control, respectively covering the determination and the control of rights of users to use IT assets, is a key component in the provision of comprehensive secure business processes that inspire trust for its participating stakeholders. In recent literature relating to e-business [9], the
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SACMAT’02, June 3-4, 2002, Monterrey, California, USA. Copyright 2002 ACM 1-58113-496-7/02/0006…$5.00
The aim of this paper is to describe a method for authorization and access control to resources and data based on Role-Based Access Control (RBAC) and to describe how such a method can be integrated in a wider trust infrastructure in order to comply with wider security and safety requirements. The authorization process
117
will be realised by means of credentials that are bound to users of the IT resources. The smart card will serve as secure access token including identification/authentication as well as digital signature functions. The method is applied to the health care domain but could as well be applicable to other domains in which multi-actor and context dependant (remote) access to digital assets is critical.
certificates for authorisation and access control can make their management procedures heavy and requires appropriate certificate management infrastructure. While referring to some of the proposed concepts, we opted for clearly distinguishing between static role assignment to users based on credentials and dynamic allocation of roles determined at session time.
The research that has lead to this paper is performed within the DRIVE1 project. DRIVE aims at the development of an information and trust infrastructure for optimising the clinical processes and the drug supply chain processes in a health care enterprise. Therefore, the DRIVE real case pilot covers all the value-makers involved in the drug therapy process. This includes the diagnosis and therapy prescription processes in the clinical domain of a Hospital including the controlled therapy administration to the patient, therapy validation by means of up to date drug data, the traceability of pharmaceuticals and related information flows from the drug supplier to the hospital logistics.
The following chapters describe the DRIVE authorization and access control approach by elaborating in separate chapters on trust constituencies, the RBAC principles adopted in DRIVE, the operational procedure and the integration of RBAC in a comprehensive DRIVE trust infrastructure.
2.
TRUST CONSTITUENCIES
The concept of trust constituency was briefly introduced in [8] but its use was not further elaborated. It covers individuals, organisations and business units that have a trust stake in the protection and in the engagement of their rights and obligations with regard to health records. We have adapted this concept to the DRIVE context linked to the notions of jurisdiction and trust engagement that we define below:
RBAC [12], as an alternative to traditional access control methods, associates roles which each actor who might have a need to access assets. With each role a specific set of access rights is associated that the actor in that role may perform. The question then remains how to define roles and their granularity. For instance, in health care, a role could be location-based (e.g. membership to ward) and may take the form of “Patient Clarke’s record can be accessed by” “any health professional assigned to the same ward as the patient”. However, grouping with strict location constraints such as ward may become tricky when the business process transcends physical perimeters, a situation facilitated by distributed computing and remote access. Or role could be based on job responsibilities in the organisation. So for instance, “Patient Clarke’s record can be written by” “any health professional assigned to the role of ward physician”.
Jurisdiction: Membership of the involved actors to the same institution/organisation that defines the actors’ trust engagement by means of organisational policies. In a complex health care environment different organisations are part of the value chain. Defining a jurisdiction and its boundaries even if the latter are virtual is important for determining responsibilities and obligations. Trust constituency: A DRIVE trust constituency is a logical entity within the context of a business process that encompasses process activities and actors and is determined by a trust engagement with regard to a certain type of asset. It should be noted that by focusing on activities and actors instead of physical location, one trust constituency in principle could transcend physical locations (e.g. a ward physician that is mobile, a remote consultant physician providing advice on a diagnosis or a patient consulting his records from home). In practice, a trust constituency will often correspond with a physical premise (e.g. a hospital ward).
The latter approach was adopted in the PCASSO project [1]. PCASSO developed a RBAC applied to a clinical domain and has defined a number of roles including Primary care Provider, Secondary Care Provider, etc. PCASSO also combines the role based access control with label-based access control that isolates different levels of sensitivity of data. Sensitivity levels could cover e.g.: low - non identifiable data, standard - identifiable patient data and high – genetic, mental health, HIV data.
Trust engagement: Prescription of a joint trust stake among actors, defining their respective rights and obligations with regard to certain assets handled in the course of certain process activities.
Whereas in PCASSO, the general approach was to assign generic clinical roles to actors independent from the clinical context in which these actors operate, the general approach in the DRIVE project is a business process-oriented approach. This implies eliciting roles that are business context dependent and directly associated with a task in the drug therapy process.
An important privacy principle is use limitation of personal data within predefined contexts. The trust constituency concept can be used for determining these contexts in defining authorisation rules. With respect to this, two key distinguishing factors determine a trust constituency, namely: the type of asset handled (e.g. patient-identifiable clinical data, demographic patient data, non-identifiable clinical data, drug logistics data, drug clinical data) and the jurisdiction. A hospital (corresponding to one jurisdiction) can have different trust constituencies based on the legitimate need for its users to access patient identifiable clinical data (e.g. identifiable clinical data should be handled only in the hospital clinical activities). Therefore, the concept of trust constituency imposes constraints on how actors can access the different assets. It also puts constraints on the transfer of assets from one constituency to the other. For instance if there is a legitimate need for transfering to third parties (e.g. insurance
In [10] a method is proposed for access control to distributed medical database systems using digital certificates. It proposes the use of attribute certificates for authorisation and introduces access-rule certificates for propagation of access control policy. The attribute certificate approach is currently under discussion in standards initiatives [7]. Moreover, the management of short-lived 1
DRIVE (Drug in Virtual Enterprise) is an EU funded R&D project conducted and supported in the frame of the EC IST programme (IST-1999-12040). The partners are: Scientific Institute San Raffaele, Joint Research Centre, ATOS-Origin, Karolinska Institute, Politechnico di Milano, AstraZeneca, Glaxowellcome.
118
Clinician
Patient
nonidentifiable clinical data
Drug clinical data
Patient demographic data H admin clerk
Drug Supplier
Drug logistics data
logistics operator
Drug data
Pharmacist
Administrative & logistics
Suppliers
Figure 1: Trust Constituencies in DRIVE
Time constraints: Determines role activation and permission assignment based on time.
As a general principle, access rights for assets are reduced when actors are not in the same trust constituency in which the asset originates. Furthermore, the context parameters implement the need-to-know principle, for example the need to know of patient identities for users outside the ward should be limited.
company) identifiable clinical data for the execution of the contract, then this becomes another trust constituency because it is a different jurisdiction. The transfer of data then needs to be done under controlled conditions by a trusted entity that is accountable (e.g keeping disclosure registers).
3.2
Figure 1 gives a schematic overview of four trust constituencies within the DRIVE system. For instance the clinical trust constituency, concerns activities performed on patient related clinical objects (the patient himself, biological samples) and acting on patient-identifiable clinical data. The trust constituency could be further fine grained for instance by covering a specific ward. The clinical support trust constituency is in the DRIVE pilot limited to pharmacy clinical support activities. It provides up to date drug related data to wards and accesses clinical data for validating drug prescriptions and keeps statistics on therapies effectiveness. The implication is that a pharmacist can belong to two trust constituencies because of his/her clinical support and logistics functions.
Dynamic properties
We need to extend the RBAC model with dynamic properties applied to the role activation function. This allows the system to be most flexible and most suitable for the Health Care environment. For instance there is a need to cope with specific access privileges of on-call physicians on night duty. For the dynamic extension of RBAC in DRIVE we introduce a set of expressions that allow specification of these properties. The basic expression is the event expression and the conditions that produce these events. The conditions are based on a set of context events, including time [2], trust constituency and an additional specific time related condition, namely formality context for specifying urgency. Event expressions
RBAC PRINCIPLES
1. Event expressions (Ei ) have the form activate (U,R) or deactivate (U,R), where U ∈ USERS and R ∈ ROLES.
The DRIVE authorisation and access control approach is based on establihed RBAC principles [12] and furher work. How these principles are applied or adapted is explained in this chapter.
2. Prioritized event expressions have the form p:E, where p ∈ PRIOS and E is an event expressions.
Context control
3. We say that two event expressions activate (U,R) and deactivate (U’,R’) are conflicting if U=U’ and R=R’; in symbols, we write:
Context control is highly important for authorisation and access control to resources in distributed health care processes in which multiple actors add value to critical assets. In [10], context control is primarily based on location (site, domain, etc). We propose to include the following parameters: -
-
Context control impacts the functional architecture of the RBAC system in two ways. First, it allows to distinguish between activated roles and predefined roles for a particular user. The set of predefined roles of a user is determined at registration time and based on user’s credentials. The working context (constituency, time) of a particular user combined with dynamic exclusion rules determine which subset of predefined roles allocated to that user can be activated at session time (e.g. on-call physician can only be activated during night time). Secondly, knowledge of the user context also contributes to refine the permission assignment to roles. Usually, permissions are statically assigned to roles (e.g. read and write therapy data is assigned to ward physician). It allows to dynamically adapt permission assignment for a particular role dependent on specific user context constraints, for instance based on the location of the user (e.g. no write access to therapy data if a ward physician is outside his default trust constituency, i.e. ward).
Clinical Support Pharmacy
Pharmacist
3.1
Mutual exclusion: In the organization of the DRIVE RBAC approach determines both static and dynamic exclusion rules. Static exclusion means that some actors cannot be authorised for different roles: e.g. nurse and ward physician; Dynamic exclusion means that an actor cannot act simultaneously in both roles: e.g. ward physician and on-call physician.
drug prescription profiles
Clinical
3.
Identifiable clinical data
conf(activate (U,R)) ≡ deactivate (U,R) conf(deactivate (U,R)) ≡ activate (U,R)
Trust constituency: Determines where an actor normally performs his functions, his rights and duties.
Role status
119
Role status expressions (Ci ) have the form active (U,R) or ┐active (U,R), where U ∈ USERS and R ∈ ROLES.
within a given application to execute operations on a specific group of data items in the asset (e.g. read patient clinical data or write therapy data in the patient record).
Context events
4.
Context events (CE) are of the form (I, P, W, F,p:E), where: I is a time interval of the form [begin, end]. If the expression is always true the form is [-∞,∞] P is a periodic expression (time context) W is a place expression (trust constituency or ward context) F is a formality expression (routine or emergency) p:E is a prioritized event expression
3.3
Hierarchies
The concept of hierarchy is important in multi-actor RBAC and it reflects the structure of the organization and the respective responsibilities of the roles. Hierarchies of user roles will be used for permission inheritance [5]. Refer to the RBAC model explained in chapter 4 for examples of role hierarchies.
3.4
DRIVE RBAC MODEL
In this chapter, we describe the DRIVE RBAC model according to the DRIVE application case and taking into account the RBAC principles from the previous chapter. Guidance is given by a proposed standard for Role-based access control [6] that describes how to specify a Core RBAC reference model. It is applied to the DRIVE requirements and adapted to cope with multi-level authorization rules, including access control to application functions as well as assets. The resulting RBAC model consists of specifying the following entities and associations (figure 2).
(UA) User Assignment Users User/ session
Multi-level Authorisation rules
A typical authorisation rule in DRIVE would be composed of: A user role within a user context has authority to access a function and has authority to access an operation on assets.
(PA) Permission Assignment
Functions
Ops_Fnc Roles Ops_Asset
Sessions
Session/roles
Assets PRMS
Figure 2: RBAC reference model
For instance a ward physician within the same ward of the patient has authority to access the therapy prescription function and has authority to read the patient record and write the therapy.
The set of users (USERS) is understood as the user categories that need accessing different resources in the DRIVE application servers, including clinical and logistics. For example, in Trust Constituency 1 (TC1 – Clinical), the clinical user category includes: Head physician, Ward physician, On-call physician, Service physician, Head nurse, nurse (figure 3). In DRIVE, a single user category can belong to different trust constituencies. For instance, in the hospital, a pharmacist belongs to TC2 – Clinical Support as well as to TC3 – Administrative & Logistics.
This rule differs from the 3DAM (3-dimension access matrix) rule described in [10] in that we have introduced an additional control level, namely at the functional level and this for two reasons. Firstly, in DRIVE the business process approach calls for a large set of functions within an application range covering clinical, logistics and collaborative logistics applications. These functions are accessible from a common DRIVE portal. Therefore, we want access control at application level. Second, this approach allows for a gradual implementation of the RBAC in DRIVE starting from access control to functions and subsequently addressing data access control.
The definition of roles (ROLES) in DRIVE is explicitly related with the business process tasks that are performed in the clinical and logistics trust constituencies. For instance, the roles that perform clinical activities in the clinical Trust Constituency include: Anamnesis Maker, Diagnosis Maker, Therapy Prescriber,
The levels of granularity of access control then comprise: •
•
•
Functions: At the highest level, access control to applications and functions (e.g. the therapy prescription function). This means the permission or not for a user role within a certain context to access a function.
C lin ic a l
Digital asset: Second level, access control to operations on whole assets. Operations would typically include: create, read, write, modify, delete. This means the permission or not for a user role within a certain context and within a given function to execute operations on whole assets (e.g. read the whole patient record).
N u rs e
Data items: Third level, access control to specific groups of attributes in an asset. The patient record for instance is composed of three broad groups: Patient demographic data, hospital stay data and patient clinical data. This means the permission or not for a user role within a certain context and
O n -c a ll P h y s ic ia n
H e a d N u rs e
W a rd P h y s ic ia n
S e rv ic e P h y s ic ia n
H e a d P h y s ic ia n
Figure 3: clinical user categories
120
clinical manager
anamnesis maker
on-call physician
diagnosis maker
prescriber
ward physician
pharmacy director
head nurse
head physician
prescription validator
consultant
therapy therapy preparator administrator
service physician
nurse
therapy validator
DUR HF-WP analyser definer
pharmacist
clinical support staff
clinical staff
request warehouse validator manager
logistics/admin staff
Figure 5: Role hierarchy for Pharmacist
Figure 4: Role hierarchy for clinical staff Consultant, Therapy Preparator, Therapy Administrator and Data Collector of patient health state.
covering respectively the clinical staff assignment and the clinical support staff. It is noted that therapy validator, DUR analyzer and HF-WP definition are clinical support roles performed by a pharmacists whereas request validator and drug warehouse manager are two logistics roles performed by pharmacists. The latter two roles can only be activated from the logistics trust constituency.
The roles in the Trust Constituency 2 – clinical support include: Therapy Validator, Hospital Formulary & Ward Profile (HP&WP) Definition, Drug Utilization Review (DUR) Analyser. The set of functions (FUNCTIONS) contains about 50 different functions (e.g. therapy prescription, etc) that are subdivided into the four application servers: clinical, logistics, collaborative logistics and Hospital Information System (HIS). They represent the main Use Case models for the DRIVE application.
By convention, more authorative roles are towards the top of the diagrammes. In figure 4, the head physician is senior to ward physician and inherits all permissions from ward physician. Session/Role association A user session is associated with a subset of the roles authorized for the user and this subset, often referred to as the active role set (ARS), is determined by dynamic exclusion rules and temporal constraints. The dynamic conditions are implemented by an activation/deactivation function. In the following table 1 we show an example of an activation/ deactivation function for the on-call physician role.
The CC standard [3] defines an asset as information or resources to be protected by the countermeasures of a target of evaluation (TOE). In DRIVE, within the RBAC context the set of assets (ASSETS) focuses on information assets. Access control to computing resources is covered by controlling the access to functions. The categories of information assets include patient data, drug data and health care professional data. The patient data comprise three groups of data items: patient demographic data, hospital stay data and clinical data. The clinical data are patient health data collected during the hospitalisation episode. The HC professional data include credentials and identity information.
Table 1. On-Call Physician session/role association (the trust constituency context parameter is the ward number) Time Context Nighttime Daytime Nighttime Daytime
The set of operations on functions (OPS_FNC) specifies the legitimate operations on the set of functions. The basic operations on functions are only binary: access to a function or no-access to a function. The set of operations on assets (OPS_ASSET) specifies the set of legitimate operations that can be performed on whole assets or groups of attributes contained in them. In Drive, we identify: create (constructs an object and initializes its data); read (reads an object or a subset of attributes of them); write (inserts the data in an object or in a subset of attributes of the object in append mode); modify (writes an object or a subset of attributes of it in update mode); copy (copies the data of an object in a different object); delete (delete an object and the data related with them).
Ward Formality Context In wards Routine/ Emergency In wards Routine/ Emergency In ward Routine/ Emergency OutRoutine/ Ward Emergency
Priority
Event
H
Activate (On-CallPhysican, Prescriber) Deactivate (On-Call Physican,Prescriber) Activate (On-CallPhysican, DiagnosisMaker) Deactivate (On-Call Physican, DiagnosisMaker)
H H H
Finally as last step in the procedure, the permission assignments define access policies for different roles. Permission assignment 1 covers the Role/OPS_FNC association. For each role, the access rights on applications and functions are defined. For example covering applications: Clinical staff → clinical application server; For example covering functions: Ward Physician → all clinical functions; service physician → Diagnosis.
The User assignment (UA) is a key association in an RBAC policy definition. It assigns roles to each individual user category based on the specific profile of the user. In principle more than one role can be assigned. Static exclusion rules and hierarchies will be taken into account for defining user assignment. As an example, two role hierarchies are shown in the figures 4 and 5
121
Permission assignment 2 covers Role/OPS_ASSET association. For each role, permissions on assets are defined. The RBAC model should allow for roles having overlapping permissions. For example, read permission rights may be allowed for all clinical staff (physicians and nurses) belonging to the trust constituency (ward) where the patient record originates, while writing the therapy on the patient record may be specific for the “therapy prescriber” role. The framework should also leave the possibility for more restricted ACL’s, in particular lists containing a single named health professional (e.g. in case of very sensitive health data or in case of celebrity patients).
User assignment: authorization credentials (roles) are assigned to user
User/session association: Identification and authentication of user
Session/role association: User activates roles and the user context is determined
For example: Prescriber, Consultant → Read (Patient Demographic Data, Hospital Stay Data, Patient Clinical Data, Therapy Sheet); Prescriber, Consultant → Read (Drug product data); Prescriber→ Create/Write/Modify (Therapy Sheet); Prescriber → Create/Write/Modify (Therapy Data); Consultant → Write(Therapy.Therapy Advice)
5.
Access a function in a particular session
Access control to the application/function
FUNCTIONAL ARCHITECTURE
Taking into account the RBAC principles and model explained in the previous chapters, the functional architecture for authorisation and access control in DRIVE consists of the following instances (figure 6).
Access control on the operations on assets
The first instance, user assignment, is executed off-line. Each potential DRIVE user of clinical or logistics systems registers with the DRIVE Certificate Authority (CA) and obtains an X509 identity certificate. Authorisation credentials (Roles) are assigned based on the identity of the user and additional identity properties (profession, specialty, etc..). In addition, the default trust constituency of the user is specified (e.g. ward number 5 or pharmacy or logistics, etc). This assignment is performed on behalf of a Credential Issuer (e.g. clinical director of a Hospital for clinical roles or personnel department for other roles). By issuing a credential certificate next to the identity certificate, the Credential Issuer certifies that the user owns a specific property that determines his/her role(s) in the business process. Static exclusion rules are applied here for roles assignment. Credential systems are not new in IT security. In [3], a credential system is described but applied to identity management and anonymity services on the Internet. In DRIVE, its prime use is RBAC applied to a multiuser health care business environment.
Log out of the session
Figure 6: DRIVE RBAC functional architecture control applies and some form of automated control is possible here. Indeed, the dynamic exclusion rules explained in the previous chapter put constraints on the choice of roles in a certain context. For instance, time context for an on-call physician. The set of activated roles and the user context form a session/role association. After activation of a subset of roles and determination of the context, the actual access control decision-making process takes place following a 3-level process. The decision making process is specified as a set of permission assignments on applications, functions and assets as outlined in the RBAC model. The user requests access to one of the functions in the DRIVE application servers. For instance the therapy prescription function in the clinical application system. Also here dynamic context control applies based on context parameters for refining the permission assignments.
The subsequent instances of the architecture apply online; i.e. during a session of a user. During user/session association, before users can start a new DRIVE session with one of the DRIVE applications, they are identified and authenticated. Strong authentication supported by smart card and identity certificates are used.
The first level access control mechanism is activated for determining if the session/role association is authorized or not to access the function. Then second level checking determines if operations on whole assets can be performed.
The subsequent instance covers Session/role association. After successful authentication, the user context is determined (time, place from which a session is started). The user activates one or more of the roles previously assigned to him in order to accomplish a certain task in the business process. As a general approach and for efficiency reasons, we allow users in DRIVE to choose a common role with less authority (towards bottom in the role hierarchy) with the possibility to specialise the role subsequently if needed. Thus a ward physician, would typically log a session as ward physician for performing all the normal ward tasks. Dynamic context
The third-level access control mechanism checks permissions on the groups of data items. Permitted access requests are performed by the database server and results returned. The session is logged off and the cycle starts again at step 2: user/session association. It is noted that the functional architecture explained above is privacy enhancing because it allows for selective access to critical personal assets in the complex multi-user environment of DRIVE.
122
Strong authentication of actors is necessary for accountability reasons. Privacy concerns primarily regard patient data protection. In some instances of the business process, there are also privacy needs of the actors themselves. For instance, clinicians’ identity should not be disclosed when patient records are legitimately accessed from outside the clinical trust constituency. In this case, RBAC needs to be combined with anonymity technologies. In an e-commerce environment on the other hand, privacy can be enhanced notwithstanding the need for strong authentication. Indeed, the approach allows for a clear separation between user/session association on one side and session/role association on the other. The former can be performed by means of strong authentication of the user to a trusted third party. For the latter the trusted third party performs the session/role association on behalf of the service provider without disclosing the real identity of the user to the service provider.
6.
The RBAC authorization and access control approach is integrated in the DRIVE trust infrastructure. The DRIVE trust infrastructure covers a wider set of trust functions needed to support the safety and security requirements, and is composed of: Real-time validation and verification: Covers data correlation and integrity checks on physical and digital assets.
•
Authorisation and access control: Covers the role-based access control policy and mechanisms.
•
Authenticity assurance: Covers the authenticity of the (critical) data content by creating digital signature envelopes around changed parts of critical assets.
Identity protection: Covers anonymising technology applied to patient records for protecting patient and clinician’s privacy after patient dismissal from ward.
•
Trust support functions: A set of functions that support the implementation of the trust functions specified above. They include for instance identification/authentication, key/certificate management, digital signature, encryption/decryption.
•
IT infrastructure protection: Covers secured communication channels that assure integrity and confidentiality between systems in the distributed DRIVE system architecture.
The part of the DRIVE trust infrastructure that supports the authorsisation and access control functions covers the following instances (figure 7):
TRUST INFRASTRUCTURE WITH RBAC FUNCTIONALITY
•
•
•
DRIVE CA: Certificate Authority. Issues identity certificates to users and to the Credential Issuer. In addition, manages the life-cycle of keys and certificates. All published and certified keys can be fetched from its directory function.
•
The Credential Issuer: Assigns roles to the different users of the DRIVE applications. By issuing a role, the credential issuer certifies that the user owns a specific characteristic. Therefore, the data structure containing the roles of a particular user is digitally signed by credential issues. In addition it publishes its public key that can be used to verify these roles.
•
Smart Card: Hardware/software token to store in a secure way a number of data structures needed for digital signature, authentication, authorisation and access control. These include: user’s private key, certificate and PIN number.
Certificates generation
Directory
DRIVE CA
LDAP server
Roles Assignment
Certificate services
Crypto services
Credential issuer DRIVE Authentication Server Smart Card
DRIVE actor
session login
User Work station
Figure 7: RBAC in the DRIVE trust infrastructure
123
API signature/en (de)cryption
R B A C
DRIVE Application servers
•
9.
Authentication Server: Authenticates user, fetches roles assigned to the user from the directory and passes them on to the application server.
A key requirement is to conceive the RBAC system as middleware that can be easily integrated with the different applications covering clinical and logistics and running on different computing platforms. In addition, it must interoperate with the appropriate trust infrastructure components. Existing software security packages, predominantly based on proprietary solutions, are still lacking maturity with this respect. Java-based API’s with crypto libraries for accessing security functions, key exchange and certificate verification mechanisms are emerging on the market. Similarly, an open RBAC API would in turn promote interoperability and portability.
7.
REFERENCES
[1] Baker, Dixie. “PCASSO: A model for Safe Use of the Internet in healthcare”. Journal of American Health Information Management Association (AHIMA), March 2000. [2] Bertino E., Bonatti P., Ferrari E. “TRBAC: A Temporal Role-based Access Control Model”. ACM Transactions on Information and System Security, 4(3), 2001 [3] Clauss S., Kohntopp M. “Identity management and its support of multilateral security”. In Computer Networks 37 (2001) 205-219, Elsevier Science B.V. [4] Common Criteria for Information Technology Security Evaluation. CC version 2.1, August 1999. (aligned with ISO 15408:1999). Common Criteria project Sponsoring Organisations.
CONCLUSIONS AND OUTLOOK
This paper has described the requirements for authorization and access control of an integrated health care business process. We outlined how state-of-the-art RBAC models can be applied and adapted for satisfying these requirements and how an RBAC can be integrated in a wider trust infrastructure including the use of Smart Cards.
[5] Ferraiolo, Cugini, Kuhn “Role Based Access Control: Features and Motivations". Computer Security Applications Conference, 1995. [6] Ferraiolo D. F., Sandhu R., Gavrila S., Kuhn D. R., Chandramouli R. : “ A proposed standard for Role-Based Access Control” December 18, 2000.
The emerging health care domain is characterised by complex business processes with multiple actors interacting on critical assets. Safety and privacy are key requirements. There is a need for an authorization and access control approach that is coherent but not uniform across different business units and organizations. At the same time it must be flexible and easy to manage.
[7] Health Informatics: Public Key Infrastructure: Part 1: Framework and overview. ISO/TC 215 N188, Draft Technical Specification ISO/DTS 17090-1. [8] ISO TC 215/WG2: Healthcare Informatics – Trusted End-toEnd Information flows. Technical report, 1 November 2000.
RBAC as an emerging technology provides potentially interesting solutions for these needs. The flexibility should however not be hampered by specific implementation constraints imposed by proprietary solutions. Therefore, RBAC should be designed as a platform independent middleware solution that is applicable to distributed heterogeneous application environments. The role of standards will be important with this respect, in particular for supporting RBAC solutions combined with authentication infrastructures and PKI’s. Apart from the standards initiatives referred to in this paper, another important initiative is XACML, an XML based standard for exchanging authorisation information over the Internet, being defined by the OASIS [11].
[9] Jones S., Wilikens M., Morris P., Masera M. “Trust requirements in e-Business”, Communications of the ACM (Association for Computing), Vol. 43, No 12, December 2000.
An open question to be further investigated also in the DRIVE pilot is the function and level of autonomy given to smart cards. For instance, evaluating the trade-off between storing authorisation information (roles) on the smart card and a more centralised management of authorisation credentials. For this evaluation, apart from performance criteria, we also need to consider risk criteria related to fraudulent use of roles (identity theft) and privacy.
[12] Sandhu R, Coyne E.J., Feinstein H.L., Youman C.E.. Rolebased access control models. IEEE Computer, 29 (2), February 1996.
8.
[10] Mavridis I., Georgiadis C., Pangalis G., Khair M.: “Access Control based on Atrribute Certificates for Medical Intranet Applications”. Journal of Medical Internet Research (JMIR) 2001:3(1):e9. [11] OASIS: Organization for the Advancement of Structured Information Standards. eXtensible Access Control Markup Language (XACML). See http://www.oasis-open.org/committees/xacml/
ACKNOWLEDGEMENTS
We would like to thank the whole DRIVE project team for their contributions to the development of the DRIVE trust infrastructure, in particular Stefania Petrini, Sandro Buso, Gunnar Klein and Francesco Faenzi.
124
