Transcript Leveraging Attribute Based Access Control to Ensure Fine Grained

Leveraging Attribute Based Access
Control to Ensure Fine Grained
Access to FHIR Resources
Subhojeet Mukherjee, Hossein Shirazi, Toan Ong, Indrakshi Ray,
Indrajit Ray, Michael Kahn
Department of Computer Science, Colorado State University
Anschutz Medical Campus at University of Colorado, Denver
Agenda
1.
2.
3.
4.
5.
6.
Introduction and Motivation
Previous Work
Background Knowledge
Solution
Security Discussion
Future Work
Agenda
1. Introduction and Motivation
2.
3.
4.
5.
6.
1. FHIR Overview
2. FHIR Authentication and Authorization Specifications and Drawbacks
3. Access Control Systems
Previous Work
Background Knowledge
Solution
Security Discussion
Future Work
FHIR
Overview
• Fast Healthcare Interoperability Resources
• Efficient standard for exchanging healthcare information
GET [base-uri]/Patient/1234
electronically.
• Resources are the basic building blocks.
•
E.g. Patient, Practitioner, AllergyIntollerance etc.
• Resource are
•
•
•
Expressed using standardized list of attributes.
Exchanged in XML or JSON form.
Accessed using RESTful API queries.
• Can be clubbed into special blocks called Bundles.
<Patient>
<id value=“1234”/>
…….
<name>
<family value=“McBroom”>
…
</name>
…..
</Patient>
FHIR
Authentication and Authorization
Specifications
• O-Auth 2.0
• Security Labels
• Break the glass
O-Auth 2.0
Abstract Protocol Flow and Features
• Data requester requires
explicit permission from
data owner.
• Permission is required for
each requested resource
2. I give you access
4. Here you go!!
5. Give me patient’s resource
6. Here is patient’s resource
O-Auth 2.0
Abstract Protocol Flow and Features
• Data requester requires
explicit permission from
data owner.
• Permission is required for
each requested resource
2. I give you access
4. Here you go!!
5. Give me patient’s resource
6. Here is patient’s resource
O-Auth 2.0
Issues
Aggregate Requests
Computer, give
me data for all
patients admitted
at FlowerBloom
Health Centre.
You have
To ask permission
From 39 doctors
At that
institution
O-Auth 2.0
Issues
Aggregate Responses
OK!!
Doctor…please don’t
release my information to
researchers who hail from
outside the country and
are not HIPPA compliant!!
Is there an
easier way to
do this?
You have
data release
requests
from 370
researchers
O-Auth 2.0
Issues
Emergency Situations
I am sorry. Your general
physician is on holiday. I
do not have access to view
your data. Please come
back tomorrow.
Doctor!! I need urgent
attention.
Security Labels
Overview
• Access Control Mechanism
• Attached to resource metadata.
• Can solve the issues posed by OAuth 2.0
Issues
• Limited to a finite set of categories
defined by FHIR.
• Does not take requesting users
attributes into account.
• Has to be attached to each
individual resource.
Break The Glass
Overview
• Valid for emergency scenario.
• Provided by specific security label.
• Requires assigning emergency
privileges to the requester.
Issues
• Lack of implementation at the
FHIR level.
• Privileges need to be ascertained
prior to access.
• Must be attached to each individual
resource.
Access Control Systems (ACS)
Overview
• Can mitigate the issues posed by OAuth 2.0 and Security Labels.
• FHIR specifies using access control
systems.
• Previous attempts made in
formalizing ACS on FHIR.
Issues
• No publicly available
implementation.
• Few attempts in formalizing ACS
on FHIR.
Agenda
1. Introduction and Motivation
2. Previous Work
3.
4.
5.
6.
1. RBAC Based
2. ABAC Based
3. Our Contribution
Background Knowledge
Solution
Security Discussion
Future Work
RBAC Based
List
1. M. Anwar and A. Imran, “Access control for multi-tenancy in cloudbased health information
systems,” in Cyber Security and Cloud Computing (CSCloud), 2015 IEEE 2nd International
Conference on. IEEE, 2015, pp. 104–110.
2. X. Dong, R. Samavi, and T. Topaloglou, “Coc: An ontology for capturing semantics of circle
of care,” Procedia Computer Science, vol. 63, pp. 589–594, 2015.
3. G. C. Lamprinakos, A. S. Mousas, A. P. Kapsalis, D. I. Kaklamani, I. S. Venieris, A. D. Boufis,
P. D. Karmiris, and S. G. Mantzouratos, “Using fhir to develop a healthcare mobile
application,” in Wireless Mobile Communication and Healthcare (Mobihealth), 2014 EAI 4th
International Conference on. IEEE, 2014, pp. 132–135.
4. T. NAMLI, S. POSTACI, M. GENC¸ TU¨ RK, A. DOG˘ AC¸ , A. YALC¸ INKAYA, and C.
TAS¸KIN, “Addressing the adoptability challenges of the phr systems: Sharingcare,” in
eChallenges e-2013 Conference Proceedings Paul Cunningham and Miriam Cunningham
(Eds) IIMC International Information Management Corporation, 2013.
RBAC Based
Issues
• RBAC itself suffers from the following issues
• Lack of granularity in policy definitions.
• Allows similar privileges to individuals belonging to same roles.
• Does not reflect owner choices properly.
• Overall RBAC is not suited to the medical domain [IRAY2016]
• I. Ray, T. C. Ong, I. Ray, and M. G. Kahn, “Applying attribute based access control for privacy
preserving health data disclosure,” in Proceedings of the The IEEE International Conference on
Biomedical and Health Informatics. 2016
ABAC Based
List
1. M. P. Machulak, E. L. Maler, D. Catalano, and A. Van Moorsel, “Usermanaged access to web resources,” in Proceedings of the 6th ACM
workshop on Digital identity management. ACM, 2010, pp. 35–44.
2. M. H¨uffmeyer and U. Schreier, “Efficient attribute based access control
for restful services.” in ZEUS, 2015, pp. 55–62.
3. “Restacl: An access control language for restful services,” in Proceedings
of the 2016 ACM International Workshop on Attribute Based Access
Control. ACM, 2016, pp. 58–67.
ABAC Based
Issues
• Not focused towards FHIR
• Do not specify how access requests and policies should be defined and evaluated in
coherence with FHIR standards..
• Deal with SQL queries instead of REST queries.
• Do not consider resource attributes while making access decisions.
Our Contribution
• ABAC based Access Control System.
• Defining access requests and policies
• Following FHIR resource and REST API standards
• Releasing data at individual resource level for both singular and batch queries.
• Authorizing and Authenticating
• Data Providers
• Policy Providers
• Data Requesters
Agenda
1. Introduction and Motivation
2. Previous Work
3. Background Knowledge
1. ABAC Engine
2. XACML
4. Solution
5. Security Discussion
6. Future Work
ABAC (Attribute Based Access Control)
Engine
• Policy Enforcement Point (PEP)
•
•
•
•
• Receives requests.
• Sends responses.
Context Handler
• Creates XACML requests.
Policy Decision Point (PDP)
• Makes decisions.
Policy Administration Point (PAP)
• Stores policies.
Policy Information Point (PIP)
• Fetches missing attributes.
XACML (eXtensible Access Control Markup
Language)
• Structure
•
Policy Set
•
•
Policy
•
•
Aggregation of policies
Contains Target and Rules
Rule
•
May contain Conditions
• Policy combining algorithms
• Attributes
•
•
•
•
•
Resource
Action
Subject
Environment
Custom
Agenda
1.
2.
3.
4.
Introduction and Motivation
Previous Work
Background Knowledge
Solution
1. Architecture and Components
2. Use Cases
5. Security Discussion
6. Future Work
Architecture and Components
•
•
Validation Server
•
Validates user attributes
•
Updates Attribute Database
Policy Admin
•
•
ABAC Engine
•
•
•
Makes Access Decisions
PEP
•
•
Front-End for creating/editing/deleting policies
FHIR server access front-end
Attribute Database
•
Stores user attributes
•
PIP fetches missing attributes
Owner Database
•
Tracks owners of resources
Registration
• User fills up Validation Server front-end form.
• System wide unique id is generated for new user.
• Role must be “Poster” for data provider.
• Attributes are validated using
• Predefined predicates
• Custom business logic
id
attribute values
• Attribute Database populated with new attribute
field names
Attribute Database Schema:
id, role, address.city, name.given
values.
• Primary key : id
Create/Update (POST/PUT) Use Case
Protocol Flow
Create/Update (POST/PUT) Use Case
Example
id
role
address.city
2334
Poster Denver
owner id
resource id
2334
ABC435
Permit
done
name.given
Peter
<Policy PolicyId = "DEF-POST"
rule-combining-algorithm="deny-overrides">
<Target><Request>
POST https://[fhir-server]/Patient
:action
AnyOf:
id: 2334
Create
: :action-id :POST
:id :2334
AllOf::access-subject
<Patient>
<Patient>
:resource
:resource-id
:access-subject
:role :Poster:Patient
<id
value=“1234”/>
<id value=“ABC435”/>
admin:
:resource
:xacml:resource-id
:.* :admin
…….:resource-owner
…….
</Request>
<name>
:action
:xacml:action-id
:POST
<name>
<family
value=“McBroom”>
:admin :resource-owner
:admin
<family
value=“McBroom”>
</Target>
… …
</name>
</name>
<Rule RuleId
= "P" Effect="Permit">
…..
…..
</Rule></Patient>
</Patient>
</Policy>
Create/Update (POST/PUT) Use Case
Example Continued…
id
role
address.city
2336
Poster Boulder
owner id
resource id
2334
ABC435
Deny
Permit
sorry
name.given
Jack
<Policy PolicyId
POST https://[fhir-server]/Patient
Create
: = "DEF-POST"
rule-combining-algorithm="deny-overrides">
id: 2336
<Request>
<Target><Bundle>
<Request>
:action :action-id :POST
AnyOf:<Patient>
:action :action-id :POST
:access-subject
:id :2336
AllOf: :access-subject
<id value=“ABC435”/>
:id :2336
:resource
:Patient
:access-subject
…….:resource-id
:role
:Poster
:resource :resource-id :Patient
admin:
:resource-owner
:admin
<name>
:resource
:xacml:resource-id
:.* :2334
:admin
:resource-owner
<family value=“Carlton”>
</Request>
:action
:xacml:action-id
:POST
</Request>
…
:admin :resource-owner :admin
</name>
</Target>
…..
<Rule RuleId
= "P" Effect="Permit">
</Patient>
</Rule>……….
</Policy><Bundle>
Create/Update (POST/PUT) Use Case
POST vs PUT
POST
PUT
• FHIR Specification
• FHIR Specification
• Function
• Function
•
•
Create and Update
• Quota
•
Single or batch resource(s)
• Protocol Flow
• Owner check required.
• Owner database updated.
Update
• Quota
•
Single resource
• Protocol Flow
• Owner check not required.
• Owner database not updated.
Search/Delete (GET/DELETE) Use Case
Protocol Flow
Search/Delete (GET/DELETE) Use Case
Example
id
role
address.city
2336
Researcher
Denver
owner id
resource id
1675
1234
2334
ABC435
Deny
Permit
Patient ABC435
<Policy PolicyId = “P-2334"
rule-combining-algorithm="deny-overrides">
GET https://[fhir-server]/Patient?gender=“female”
<Target><Request>
<Request>
id: 2334
name.given
:actionall
:action-id
AnyOf:
Search
female :GET
Patients
:action
:action-id
:GET
<Bundle>
:access-subject
:id
:2336
Peter
AllOf: :access-subject :id :2336
<Patient> :resource-id :Patient
:resource
:access-subject
:role
:Researcher
:resource
:resource-id
:Patient
<id value=“1234”/>
:admin
:resource-owner
:2334
:resource
:xacml:resource-id
:Patient
…….. :resource-owner :1675
:admin
:Patient
:Patient.id.none
:action
:xacml:action-id
:GET :ABC435
</Patient>
:Patient
:Patient.id.none
:1234
:Patient
:Patient.address.city
:Den
:admin
:resource-owner
:2334
<Patient>
:Patient :Patient.address.city :We
…….<id value=“ABC435”/>
</Target>
…..
</Request>
….."P" Effect="Permit">
<Rule RuleId
=
</Request>
:Patient</Patient>.
:Patient.address.city :We
</Rule></Bundle>
</Policy>
Search/Delete (GET/DELETE) Use Case
GET vs DELETE
GET
DELETE
• FHIR Specification
• FHIR Specification
• Function
• Function
•
•
Search
• Quota
•
Single or batch resource(s)
• Protocol Flow
• Query forwarded to FHIR by PEP
•
unchanged form.
Delete
• Quota
•
Single resource
• Protocol Flow
• Query forwarded to FHIR by PEP
•
DELETE verb replaced with GET.
Policy Management Use Case
Protocol Flow
Policy Management Use Case
Example (Login)
id
role
address.city
2336
Poster Boulder
Permit
name.given
Jack
<Policy PolicyId = “DEF-POLICY"
rule-combining-algorithm="deny-overrides">
<Target><Request>
AnyOf::action :action-id :Manage
AllOf::access-subject :id :2336
:resource :resource-id
:access-subject
:role :Poster:Policy
admin:
:resource-owner
:admin
:resource
:xacml:resource-id
:Policy
</Request>
:action
:xacml:action-id :Manage
:admin :resource-owner :admin
</Target>
<Rule RuleId = "P" Effect="Permit">
</Rule>
</Policy>
Policy Management Use Case
Example (Create Policy)
id
id role
role
address.city
address.city name.given
name.given
<Policy PolicyId = “P"
“P-2334"
rule-combining-algorithm="deny-overrides">
<Target>
AnyOf:
AllOf:
organization
:access-subject :role
:role:Researcher
:Researcher
:resource :xacml:resource-id :Patient
:action :xacml:action-id :GET
</Target>
:admin :resource-owner :2334
</Target>
<Rule
RuleId = "P" Effect="Permit">
<Condition>
<Rule RuleId = "P" Effect="Permit">
<Condition>
:access-subject :organization :CSU
</Condition>
:access-subject :organization :CSU
</Rule>
</Condition>
</Policy>
</Rule>
</Policy>
Policy Management Use Case
Example (View Policy)
P
Policy-Admin
Policy-2
P-2334
Policy Management Use Case
Example (Delete Policy)
P-2334
Agenda
1.
2.
3.
4.
5.
6.
Introduction and Motivation
Previous Work
Background Knowledge
Solution
Security Discussion
Future Work
Motivating Scenario
A
Creates resource: B and C
B
Allows B to view his resource
Allows Doctor B to view/edit Patient C resource
Refers Patient C to Doctor B
treats
treats
C
B
Researcher from city ``Mounds”
Security Scenarios
Agenda
1.
2.
3.
4.
5.
6.
Introduction and Motivation
Previous Work
Background Knowledge
Solution
Security Discussion
Future Work
Discussion and Future Work
Summary
• Fine grained access to FHIR
resources.
• Asynchronous authorization.
• Mandatory identity validation.
• Subject and resource attribute
based access control.
Future Work
• Validation Server logic open to future
development.
• Integrating with OpenId Connect 1.0.
• Evaluating effectiveness of policies.
• Releasing resources at finer granularity
• Selectively suppressing fields if
necessary.