Stream: implementers
Topic: Access control on FHIR
Yosbel Esperón González (Oct 24 2018 at 17:28):
We have a SPA application (unsecured, runs on the browser), we are adding Authentication using OpenId Connect. We are trying to find a solution for the authorization and access problem:
We have a couple of views where a practitioner can view a list of patients, now, depending on the practitioner he/she should only have access to a subset of the patients stored in the fhir server.
We were considering implementing it as implicit filters on the server side, e.g: if the user gets the /Patient endpoint, the server would filter the resulting bundle to only list the allowed patients. This would cause the server to behave differently for different users, that is: same query would return different results depending on the user.
We are wondering whether this is a good idea.
Or should we just return unauthorized if the user (or the app) is asking for more data than it should and force it to always do the filtering and joining on the app side.
We think the first solution (implicit filters on the server side) makes life easier for the app but we are not sure if it's going to bring issues along the way.
What are the best practices for this kind of problem?
John Moehrke (Oct 24 2018 at 17:52):
yes what you are thinking of doing is typical. This is mentioned on the security pages, and is part of the SMART-on-FHIR specification. Typically this is implemented, as you have indicated, as business rules on the API implementation of the server, and is based on the OAuth token and scopes.
Yosbel Esperón González (Oct 24 2018 at 18:34):
Thanks @John Moehrke
Last updated: Apr 12 2022 at 19:14 UTC
