Stream: implementers
Topic: Policy based Authentication and Authorization
Dexter (Dec 08 2020 at 09:52):
I've been asked to implement a system where patients, practitioners are assigned some policies and access to various resources should be enforced based on those policies. How do I go about implementing this?
For example, a practitioner is assigned a few patients, recorded by using the CareTeam
resource. So, a practitioner is a part of a bunch of careteams. Now, I thought of implementing a proxy or an API Gateway to modify the query URL to limit the response to only those they're supposed to see, but this doesn't scale at all, and is a probably going to be a nightmare to extend, debug and maintain.
I also looked at SMART on FHIR
, but this doesn't seem to meet the requirements, or am I mistaken?
HAPI FHIR docs suggest I use the @Interceptor
to implement custom authentication and authorization checks, but I'm facing some difficulties understanding them. For example, say a practitioner searches for all patients that have BP greater than some threshold, how do I limit the response to only those that have been assigned to him? I'm also worried in case of somewhat larger transactions, it might be possible to figure out some information (say if a patient has a condition) based on how long a response takes to process (exiting early due to access denied) or going through and taking a few seconds.
How do I proceed with implementing this policy based access control?
Dexter (Dec 08 2020 at 09:53):
I'm pretty new to this, so I hope this place is appropriate to ask such questions. If not, please do let me know, and where such questions are better suited
René Spronk (Dec 08 2020 at 12:44):
In general you'll have to build your own 'access control engine', which may filter a query (decide whether it should be processed at all) as well as the response (remove any matching or included resources that this user isn't allowed to see). This is quite common in implementations. Potentially this could be very tricky depending on the complexity and amount of different policies that may exist in your context, let alone if one starts working with XACML based policies. SMART on FHIR offers an implementation guide for OAuth / OpenID which is one of the core foundations of an access control engine. It also has the concept of scopes which will also impact the functionality of your access control engine. This is the right forum to ask, some who have actually implemented this (I haven't) will undoubtedly pitch in as well.
Lloyd McKenzie (Dec 08 2020 at 14:17):
You generally won't want to change the API to enforce your access control. The way clients interact with your interface should remain unchanged even if your access control rules change. Your access control rules will be handled as "business rules" within your system after a call has hit your interface, but before you've executed your query/returned your results.
Dexter (Dec 09 2020 at 10:19):
Thank you very much for the info!
So my access control must be based on approaches that use filtering, and perhaps ones that also modify the final query sent to the DB by changing/adding logic to HAPI. Are there examples for both the approaches I can look at, so that I can start to get an idea on how the huge codebase works and interacts?
Lloyd McKenzie (Dec 09 2020 at 15:40):
That sort of question is probably best raised in the #hapi stream
Dexter (Dec 10 2020 at 04:13):
Okay, will do, thanks!
On a small sidenote, how do I keep track of all the threads I've started or interracted in?
Jim StClair (Feb 23 2022 at 15:55):
@Dexter outside of FHIR it sounds like your describing an authorization based access control (ABAC) which is typically enabled through an XACML based system. i'm also not familiar with orchestrating this governance through HAPI.
Jim StClair (Feb 23 2022 at 15:57):
It looks like @René Spronk was heading down the same direction I was suggesting, sorry if I was redundant.
Last updated: Apr 12 2022 at 19:14 UTC