1. Dynamic Context-Aware Access Control for Protecting Medical Records
Master's Project Presentation
Junzhe Hu
July 26, 2004
Good morning, everyone. Today, I’ll give you a presentation about my master project of “Dynamic…”. My work is advised by Prof. Alfred Weaver, This project is sponsored by Microsoft.Research and corporated with UVA Hospital.

2. Outline Introduction to our medical data security project
Prior work in access control
Dynamic context-aware access control
CAAC schema
Policy specification
Policy enforcement
Demonstration
Conclusions and Future Work
Here is what I’m going to talk about in today’s presentation. At first, I’ll give you some background about our project and what are the problems we are going to solve in this project. And then I’ll talk about the current status of research in access control area. My main contribution in this project will be discussed in section 3, which is the main idea of dynamic context-aware access control. In that section, our detailed context aware access control schema will be presented. And based on this schema, how to specify those context aware authorization policies at design-time and how to enforce them dynamically at run-time. After you get some knowledge about our ideas, I’ll show you several demo in section 4. And finally I’ll talk about what we have learned from this project and what are the problems we still need to solve in future research.

3. Our Security Architecture
All right, here is the overall architecture of our research project. The goal of this project is to provide a secured and distributed healthcare system for every entities in healthcare service, such as patients, hospitals, pharmacies, health insurance companies and etc. So, users of our system can access their interested data via the medical data portal by using various kinds of devices, such as PDA, tablet pc, desktop and even cell phone. In addition, we applies different types of authentication devices to make our system get more secured than just using username and password. These devices include some biometric ones like, fingerprint scanner, iris scanner. There are also some non-biometric devices like e-token, RAS secureID and RFID.
Now, I’ll give you a simple example to show the main steps that our system will follow to handle user’s request. Suppose a doctor wants to view the lab result of one of his patient from the PDA. He navigate to our medical portal and our system will ask him for some credentials to authenticated this user. The doctor use his fingerprint to get an authentication token from Secure Token Service, and our medical portal will store this token in the client cookie, so that user’s following data request will pass through medical portal without additional login. After this doctor get authenticated, he click some button on the web page to issue a data request for patient’s lab result. This data request is sent to backend medical data service along with the authentication token. Before this request get served, our data service will check if this user is authorized to see the required data. Our authorization engine retrieve the rules and make decision upon them. If the decision is permit, then the lab results data will be shown on the web page, otherwise his data request will be rejected.
In this project, my work is mainly focused on authorization module of our system. I designed a context aware authorization engine which is able to make authorization decision based on various parameters rather than just which roles the user is playing. I’ll give you detailed explaination about my work in following slides.

4. Authentication Issues
We must provide flexible authentication
Many devices and techniques
what you have (e-token, RFID)
what you know (password, SecurID)
who you are (fingerprint, iris, signature, voice)
How reliable is the authentication?
incorporate trust level in the authentication token
allow specification of trust level in the authorization rules
Authentication on demand
User can choose how to be authenticated
More secured authentication is required when needed.
After viewing the main architecture of this project, let’s think about what are the problems we need to solve to achieve our goal.
In the previous slide, we see that, compare to other ordinary security system that only use password to authenticate users, our system needs to handle much more kinds of authentication devices and techniques. It’s natural to ask users to be authenticated by different devices according to different operations users want to perform. For example, patient can view their own medical data by password authentication. While administrators of our system may need to be authenticated by iris scanner, which is regarded as the most secured methods in our system, because the operations that an administrator would make should get more restriction. From this point, the authorization engine should be aware of the reliability of different kinds of authentication devices.
In order to differentiate the reliability of those authentication devices, we introduce the trust level concept, which is defined as a sequence of relative numeric values to indicate the reliability of authentication tokens. For instance generally, we think the reliability of password is lower than iris scanner, so we can define trust level of password as one, and trust level of iris scanner as 5. And we can even define the trust level of fingerprint scanner as 2.5 if we feel its reliability exisit between the range of password and iris scanner.
Although trsut level helps our authorization engine to be aware of different reliability of authentication devices, ask users to be authenticated only based on the role of users is still not flexible enough, the ideal way is to let user get appropriate authentication token when needed. Suppose our system allows administrators to delete data only when he is authenticated by some device with the higher trust level than password. Even with this rule, administrators is still able to login the system by password to read some data of the system, and when they want to delete some user data, they will be asked to be authenticated by a device of higher trust level than password. To support on-demand authentication, authorization engine has to know more than just the role of users.

5. Authorization Issues
Authorization engine must enforce complex rules. Examples:
Medical student can not see a patient's record unless authorized by patient's attending physician
A technologist can see only the data related to his/her specialty (e.g., cardiology)
Physicians must authenticate at the trust level of a fingerprint or higher
Security changes require administrator status and iris scan identification
Only employees of the medical records group can delete patient data
So let’s look at what our authorization engine has to know when it is making access control. In traditional software system, data access rules are defined mainly on the role that users are assigned. For example, in a hospital, physician can read …(we can add some more to make Sam happy). However, from previous slide, we find out that sometime our system has to decide whether allow a user to perform an operation or not based on some runtime parameters. Trust level is a typical example of such kind of parameters. Here, I just list several possible examples of access rules that might be applied in our system. These rules impose the similar requirements on us, that is access control is dependent on some other information instead of roles. For the example, that medical student… Although we can write some code to handle those special cases in our program, it is not a general solution to this problem. And it is also not reasonable if we take dynamic changes of those rules into consideration.

6. Authorization Issues
Authorization process must be responsive to frequent changes
Existing rules may be periodically adjusted
Physicians, patients, employees, etc. are a rapidly changing group
Access rules may be suspended during public health emergencies
Access may be sensitive to the location, time, and/or method of the request
Solution: a dynamic, context-aware, access control infrastructure
Besides the security requirements of our healthcare system may change frequently at runtime, there are also other factors that require us to provide a very dynamic authorization process. Patients visit or leave the hospital every day and employees of the hospital also rapidly change, which results very dynamic user to user relationships in our system. Sometime, rules need to be changed according to some special requests. For example, suppose in our system, physician are required to submit electrical prescriptions by using fingerprint. Let’s say one day doctor Weaver get his finger hurt, we have to let he still be able to do his work with password authentication. And in public heath emergency, many access rules have to be disabled when patients lives get threatened.
Therefore, in order to solve the problems we mentioned above, flexible authentication, context-aware authorization, and dynamic authorization process, here we proposed our solution: to provide a dynamic, context-aware access control infrastructure.

7. Previous Work
Sandu et al. formalized Role-Based Access Control in 1996
User U acting in role R is granted permission P
Advantage: greatly improved efficiency
Disadvantage: cannot specify fine-grained rules
User
Role
Permission
Main idea of RBAC
Before I begin to talk about our proposed solution, I’d like to give you some background on the prvious work that have been done in access control research area.
Role based access control is the most popular access control model that is applied in current software systems. The most famous paper about RBAC was published by Sandu and et all in In that paper, they give the formal definition of RBAC model which contains 3 components: User, Role, Permission. The main idea of RBAC is to assign permissions to different roles instead of individual users. Since the number of roles in a system is much less the number of users, RBAC make access control not to be a big burden for administrators any more. But role is the only parameter that RBAC will take into consideration when making access control, administrators are not able to specify rules that are aware of other context information, such as time, location, trust level.

8. Previous Work Bertino (2001) introduced Temporal RBAC
Covington (2001) added location and system status constraints
Moyer and Abamad (2001) incorporated roles for subjects, objects, and environments
Georgiadis and Mavridis (2001) used team-based access control
Kumar (2002) formally proposed context-based access control
Taylor and Murty (2003) described authentication and access in distributed systems
Bonatti and Samarati (2000) regulated service access and information disclosure on the web
After Sandu’s work, many other researchers tried to make some extension to RBAC model, so that more complex rules could be enforced. So, Bertino introduce time parameter and Covington added location into RBAC in Later, Moyer and Abamad incorporated environmental information into RBAC. Georgiadia did some research on how to apply RBAC in team-based scenario in which access control is made according to workflow status. In 2002, Kumar first proposed context-sensitive access control model which is able to make authorization decision on some context factors. In addition, Taylor and Murty discuss some issues about how to apply RBAC in distributed environment. And Bonatti gave some insights on how to make RBAC applicable for web-based service.

9. Context-Based Access Control (CBAC)
What is context?
Context is “any information that can be used to characterize the situation of any entity. An entity is a person, place or object that is considered to be relevant to the interaction between a user and an application.”
Name
Age
User ID
Role
Time
Location
IP Address
CPU speed
Bandwidth
Among all those various extension to RBAC model, the most important one is context-based access control. So I’ll use two slides to give a simple introduction to CBAC. In CBAC, context is defined as …! Based on this definition, context could be some kind of information that we are farmiliar with in daily life, such as time, location, CPU speed and etc. And it can also be any abstract concept that we need to describe an interaction. For example, the trust level we introduced in section one is also one kind of context.

10. Context-Based Access Control
Associate contextual parameters with every component in traditional RBAC
Advantage: access control is context-aware
Disadvantage: this is still a static model
The main idea of CBAC is to define different context for every component in traditional RBAC. For instance, it defines UserID, username as user context of Users. And role context could be role id, role activation time. Object context include object id, object type and etc. By such kind of extension, CBAC can make access control according to various context information not just on the role. Although, CBAC make access control become context-aware, this model is still a static one, because all these context are staticlly defined in this model and it doesn’t provide us a strcuture that would allow administrators to define new context later after system is running.

11. Context-aware access control schema
CAAC Schema
Context-aware access control schema
Basic terminology
- Data Object: the smallest unit to be accessed in an application
- Data Type: a group of data objects with the same attributes
  - Data Set: the set of all data objects
  - User Set: the set of potential entities that access the data objects
Well, after I gave you some simple background on CBAC, let’s take look at what we proposed to solve the limitations of traditional RBAC and static CBAC. At first, I’m going to describe of CAAC schema on which dynamic context-aware access control becomes possible. Basically, access control schema defines the rules of how users can access data in the system, so I’ll define some terms to help us understand our schema definitions in following slides. We define Dataobject, datatype, dataset to describe data in an application. They are very simple concepts.

12. Definition 1: Context Type (CT)
CAAC Schema
Definition 1: Context Type (CT)
A context type is defined as a property related to every participant in an application when it is running.
Context Set: a set of all context types in an application.
CS = {CT1, CT2 … CTn}, 1  i  n.
Context Implementation: a function of context types defined by
CI: CT1 CT2  …  CTn  CT, n  0
The most important concept in our schema is context type which we use to describe different kind of context information. As we have already seen in previous slides, time, location, trust level can be defined as context types. Some other complex concept can also be regarded as context type as long as we need it to make some access decision. For the example, that medical student, We can define a context type of Is Authorized by physician to show that relationship between a medical student and a physician. Generally, when the designers of an application begin to develop the application, they will define a set of context type that are required by application security requirements. That’s the context set of an application. Although context set is defined before system development, our schema would allow administrators to define new context type even after system has been put into running. In order to make the abstract context type applicable during authorization, our schema requires every context type to be implemented by context implementation, which is defined as a function to compute the value of correspondant context type. For example, we define the context type “Time”, then we can use a function getCurrentTime() to get its value. For the purpose of dynamic evaluate of those context type, we require that every context implementation should take several context type as inputs and get the result of correspondent context type. IsAuthorized example.

13. CAAC Schema Definition 2: Context Constraint
We define a context constraint as a regular expression as follows:
Context Constraint := Clause1  Clause2 …  Clausei
Clause := Condition1  Condition2 …  Conditioni
Condition := <CT> <OP> <VALUE>
CT is an element of CS
OP is a logical operator in set {>, , , , , =}
VALUE is a specific value of CT
Based on context type, we are able to define context constraint which is a regular expression like this. The context constraint is a conjunction of several clauses, and every clause is disjunction of a sequence of conditions. Each condition is in the format of normal boolean expression, like which expresses the relationship between current value of the required context type and the expected value of it. For example, we might specify that some permission can be authorized after 9:00am, then context type here is Time, expected value is 9:00am, op is greater than. For another instance, we require some operation can only be performed when the trust level is >= T(password). With this format, context constraint can be used to express very complicated combination of context type requirement.

14. CAAC Schema Definition 3: Authorization Policy (AP)
An authorization policy as a triple, AP = (S, P, C) where
S: is the subject in this policy, which could be a user or a role
P: is the permission in this policy, which is defined as a pair <M, O>, where M is an operation mode defined in {READ, APPEND, DELETE, UPDATE} and O is a data object or data type
C: is a context constraint in this policy
After we define the context constraint based on context type, we can use context constraint to specify context awared authorization polices. In our schema, an AP has three elements, subject, permission and constraint. We can interprete an AP as “subject S is assigned permission P give the context constraint C is true. From this interpretation, we can see that our authorization policy just extends the traditional RBAC access rules by attaching a context constraint with it, so that it becomes aware of contextual parameters in the authorization process. If the context constraint in an AP is empty, our access rules will go back into original RBAC rules, so that our module can work perfectly compatibalbe with RBAC system.

15. CAAC Schema Definition 4: Data Access (DA)
We define data access as a triple, DA = (U, P, RC) where
U: is a user in the User Set who issues this data access
P: is the permission this user wants to acquire
RC (runtime context): is a set of values for every context type in the Context Set
DA (U, P, RC) is granted iff there exists an AP (S, P, C),
(1) U  S and
(2) P = P and
(3) C is evaluated as true under RC
Since AP is used to permit or deny some data access, we try to give a formal definition of data access as well, so that our authorization policies could be enforced very easily in our schema. According to this definition, a data access is granted if and only if there

16. CAAC Schema Visualization of a CAAC authorization policy has given
C: constraint
S: user or role
P: permission
Clause 1  …… 
Clause n
condition  …… 
condition
Here is the visualization structure of our CAAC policies. I hope this picture could help you to understand the concepts that we’ve introduced in previous slides. This is the main structure that we used to specify an authorization policy. For the left part (S and P), they are the same as RBAC, but by attaching context constraint with it, we can decide to allow that permission or not based on the context type values that we computed from those context implementations.
context type
A predicate of
context
implementation
Evaluated by

17. Prescription accepted
Policy Specification
Security polices must be exchangeable between different applications.
Hospital
Pharmacy
Send prescription
Policy response
After we designed our CAAC schema, we need to specify those policies in an exchangeable and understandable format. So that it could help users or other applications that may use our system know what’s the meaning of a particular policy. The reason that we want our policies to be exchangeable with other applications is that in some special scenario, context type value has to be retrieved from outside of the application. For example, in our healthcare system, doctors in UVA hospital can submit electrical prescriptions to CVS pharmacy. the pharmacy may have an access rule says the doctor who submit a prescription that contains some restricted drugs, like narcotics, must have appropriate DEA license. In this scenario, the policy defined by pharmacy CVS has to be understandable by UVA hospital system.
License requested
Prescription accepted

18. Policy Specification There are several XML-based policy languages
WS-Policy (from Microsoft)
SAML (Security Assertion Markup Language)
XACML (eXtensible Access Control Markup Language)
We chose WS-Policy as our specification language because it is inherently supported in the Microsoft .NET framework.
XML is used most often in current distributed environment to exchange data between applications, we also want to define our schema in XML format as well. Some XML-based policy language have been developed to help administrators specify access rules. WS-policy is proposed by Microsoft to specify the access rules for web service. SAML and XACML are two other options that could be used to specify role based access control policies. Because our project is totally built up on Microsoft .NET framework, we choose ws-policy as our policy specification langurage. However, WS-policy is initially used to specify the access control rules for web-service, we need to make some extension to fulfill our own needs.

19. Policy Specification Our customized WS-Policy tags
For any authorization policy AP = (S, P, C)
<wsa:DataType>
specifies the data object or data type of permission P
<wsa:AccessType>
specifies the operation mode of permission P
<wsa:Permission>
specifies the permission P in an AP
<wsse:SubjectToken>
specifies the security token issued to S
<wsse:ContextToken>
specifies one context condition in C
<wsse:ContextType>
specifies which context type is used in one context condition of C
Here are the six customzied tags that we extended WS-policy to define our CAAC authroization policy. I’ll explain these tags in following example.

20. A Sample Policy <wsp:Policy> <wsp:AppliesTo>
<wsa:EndpointReference>
<wsa:DataType>PatientRecord</wsa:DataType>
<wsa:AccessType>Delete</wsa:AccessType>
<wsa:Permission>DeletePatientRecord</wsa:Permission>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wsse:SubjectToken wsp:Usage="Required">
<wsse:TokenType>Medical Records Staff</wsse:TokenType>
</wsse:SubjectToken>
<wsp:OneOrMore wsp:Usage="Required">
<wsp:All>
<wsse:ContextToken wsp:Usage="wsp:GreatThan" wsp:Preference="T(password)">
<wsse:ContextType>Trust Level</wsse:ContextType>
</wsse:ContextToken>
</wsp:All>
</wsp:OneOrMore>
</wsp:Policy>
Here is a sample policy says that Medical Records Staff can delete patient records if he/she is authenticated by a device with trust level higher then password. In the first section of this policy, we use those three tags to define the permission that this policy is applied. In the second section, we use subjecttoken tag to specify the subject of this policy, In the last section, we use contexttoken and contextype to define the context constraint of this policy.

21. Dynamic Policy Enforcement
Dynamic context evaluation
initialize candidate policy set PS = { }
for every AP in policy set,
if (U in DA  S in AP) and (P in DA = P in AP)
put AP into PS
end if
end for
result = “Reject”
for every AP in PS
if (EvaluateContexts (C in AP))
result = “Accept”
break
else
return result
After the admin define the authorization polices in our system, the left work for the authorization engine is to enforce those rules dynamiclly at runtime. Here is the basic algorithm to that is used by authorization engine to apply rules for incoming data access. At first, the authorization engine tries to pick up the candidate policyes that could be applied on this data access. And then, it eveluate context constraint in every candidate policy to see if the constraint is satified or not.

22. Dynamic Policy Enforcement
Implement context as web service
Context implementation is separated from application
Easy to deploy
Protected by WS-Policy
The main difficulty in previous algorithm is to dynamic evaluate the value of context type, and then we can get the final result of the context constraint. In order to get the final value of the context constraint, we must be able to dynamically evaluate every context at runtime. In fact, there are several ways to implement context type, such that it corresponding function can be invoked dynamiclly at runtime. We choose to implement context type as web service, because it has some advantages over other options. By implementing context type as web service, not only the development but also the deployment of context implement. And those web services can also get protection from Ws-policy.

23. Dynamic Policy Enforcement
Context implementation hierarchy
Primitive context:
A context type CT is a primitive context type if it has no parameters
We define five primitive context types:
(1) Time— when this access request was issued
(2) Location—where the access request was issued
(3) User ID—who sent the request
(4) Object Type —what type of data object is being accessed
(5) Object ID —which particular data object is being accessed
However, when we want to invoke a web service dynamiclly at runtime, we need to consider how to pass the parameters into it. Before we solve this problem, let’s look back at the definition of context implemtnation. According to this definition, we find out there exist some special context type whose implementation function doesn’t takes any parameters at all. With the aid of primative context type, we can construct the context implementation hierarchy of our system.

24. Dynamic Policy Enforcement
Based on the context implementation hierarchy, any context type CTn can be dynamically evaluated along some evaluating path
Time
Location
UserID
ObjType
ObjID
Trust Level
CTi ……
IsAuthorized
CTj
CTn
CTk
Therefore, in this picture we can see that any context type can be dynamically evaluated along some path in the context implementation hierarchy.

25. Demonstration Demo to illustrate context-aware access control
dynamic rule enforcement
extensibility of our schema

26. Conclusions
RBAC and CBAC, even with extensions, cannot meet the access requirements of modern healthcare environments
CAAC is an extension to CBAC that is consistent with implementation via web services
CAAC permits dynamic specification and dynamic enforcement of arbitrary access rules
Context implementation is separated from the main business logic of target applications.
From this project, we learned that RBAC and CBAC are not able to provide a solution to support flexiblie authentication, context-aware authorization and dynamic enforcement. So, We propose our CAAC model which make a very concise extension to RBAC,
We apply WS-policy to specify our policy and enforce them via web service.
Although our research is focused on how to protect medical records in healthcare industry, CAAC can still be application in other applications with similar security requirement, because seperated

27. Future Work Check for potential conflict between policies
Determine whether an access policy should be exposed
Enforce access control across trust domains
Comparison of WS-Policy vs. SAML vs. XACML
How to check
Although we specify our polices in XML, we don’t want everyone to know it. Policy exposure
How to make access control decision if the operation or transaction needs to be accomplished by several coorated systems, we can them a trust domain. When some transaction has to be made between several parnter system, like hospital Access control made by multiple paties.

28. Publications
Junzhe Hu and Alfred C. Weaver, A Dynamic, Context-Aware Security Infrastructure for Distributed Healthcare Applications, Pervasive Security, Privacy and Trust (PSPT2004), Boston, MA, August 2004
Junzhe Hu and Alfred C. Weaver, A Security Infrastructure for Distributed Healthcare Applications, submitted to 14th International Workshop on Research Issues on Data Engineering, Boston, MA, March 28-29, 2004.
Alfred C. Weaver, Samuel J. Dwyer III, Andrew M. Snyder, James Van Dyke, James Hu, Xiaohui Chen, Timothy Mulholland, Andrew Marshall, Federated, Secure Trust Networks for Distributed Healthcare IT Services, IEEE International Conference on Industrial Informatics, Banff, Alberta, Canada, August 2003.
We have 3 publications so far on this project and our next opptunitu to present is at pSPT 2004 next month boston. That’s all I have, and if you have any questions, I’ll be glad to answer them.

29. Acknowledgements
Past and present members of our research group: Xiaohui Chen, James Van Dyke, Andrew Marshall, Xiuduan Fang, Zhengping Wu, Andrew M. Snyder, Timothy Mulholland
David Ladd at Microsoft Research