Stream: implementers
Topic: Advice on FHIR server authentication/authorization pattern
Jo-Jo Feng (Aug 25 2021 at 00:05):
Hello everyone!
I work for a healthcare technology startup. We have embedded a FHIR server in what seems to be a fairly unusual backend architecture and I am seeking advice on how to manage authentication/authorization within this architecture.
We are currently building out a FHIR server as a backend microservice, which will be responsible for handling all transactions on our FHIR data. We have a separate microservice that serves as our core application backend (call it our "API server"), which is the server that our frontend clients make direct requests to. In our current conception, when a patient wants to query their data, the patient frontend clients make requests to the API server, which in turn makes requests to our FHIR server. We want to implement some sort of authentication pattern by which we can restrict access to our FHIR server. Based on my reading, it seems like the backend services authorization profile (https://hl7.org/fhir/uv/bulkdata/authorization/index.html) is most relevant to our architecture. For example, we can treat our API server as a pre-authorized client with global scopes to access/modify all data in the FHIR server, and then rely on existing access-control code in the API server to prevent patients from requesting/modifying data from the FHIR server that does not belong to them. This seems feasible, but in an ideal world, we would implement patient-level scopes for requests from the API server to the FHIR server, which we imagine would be more secure. That is, instead of issuing a client-level access token to the API server, we could issue multiple end-user-level access tokens to the API server. This model does not seem aligned to any of the FHIR auth profiles I have seen online, and would be a significant deviation from the backend services authorization profile.
I wonder if anyone has any insight into an authentication pattern that would be suitable in this scenario, or if I am missing something? We are trying to keep our FHIR server implementation as close to well-documented standards as possible.
Please let me know if you have any questions, suggestions, or advice! This is my first time posting in this forum so forgive me if I'm posting in the wrong place :)
Thank you!
Lloyd McKenzie (Aug 25 2021 at 01:20):
Welcome @Jo-Jo Feng. This this the right 'default' place to ask about anything. However, you might find more bulk-data folks here: #bulk data and there's also a stream dedicated to #Security and Privacy
Cooper Thompson (Aug 25 2021 at 13:58):
Do you intend to support delegated access (a parent accessing their child's chart)? And do you have a data access control layer that defines what data a user can see? If so - is that in your API layer or FHIR layer? Some component of your system will need to understand who the requesting user is, and filter the FHIR resource content appropriately. If that logic is happening in your FHIR server, then I think you'd need user context to be passed to the FHIR server. I suppose you could do that with some custom header or something that you send from your API server to your FHIR server in addition to the backend services auth. If that data filtering is happening in your API layer, then.... ¯\_(ツ)_/¯ - it seems like the the API server is really your front door, and how you connect from that to the FHIR server is just an internal implementation detail for you.
Jo-Jo Feng (Aug 25 2021 at 15:06):
@Cooper Thompson Thanks for the thoughtful response! Our access control logic resides in the API server, and your impression is correct that our API server currently serves as the "foot in the door". This is helpful, and we will likely go with the simple client-based auth scheme to handle API server -> FHIR server requests, with the API server providing access control.
We actually used to support delegated access of a sort on our platform, but no longer do, and it is not currently on our roadmap. We probably want to keep this option open, but the data access control logic in our API layer should be able to support a form of delegated access.
In the future, we would also likely want to allow some of our internal frontend clients to interact directly with the FHIR server (without the API server as an intermediate), in which case we will likely need to implement a different protocol to identify the party using the frontend client and provide access control depending on their identity. The SMART App Launch profiles seem like they could be relevant in this situation (it "connects third-party applications to Electronic Health Record data, allowing apps to launch from inside or outside the user interface of an EHR system"), but it doesn't seem to me that internally managed clients should fall under the umbrella of "third-party clients", in which case we might be able to do something else. Do you have any ideas as to how we could handle authentication/authorization in this case? I may be a little bit confused on whether there are existing, published standards to handle these "internal" auth scenarios, or if we should just follow guidelines set out in the HL7 security docs (https://www.hl7.org/fhir/security.html).
Jo-Jo Feng (Aug 25 2021 at 15:06):
@Lloyd McKenzie Thanks for letting me know! I'll post over there as well :)
Gino Canessa (Aug 25 2021 at 15:20):
You could also consider token introspection - the call from the API server could just present the user token the FHIR server and the FHIR server could resolve permissions around it. If you plan to expose your FHIR server directly at some point, using the same tokens will simplify that process.
nicola (RIO/SS) (Aug 26 2021 at 12:29):
I wrote a post about FHIR & Access Control when we were designing Aidbox auth - https://medium.com/@niquola/access-control-model-for-fhir-generic-server-dd66deb7cae6
Last updated: Apr 12 2022 at 19:14 UTC
