Stream: implementers
Topic: limit who can edit specific resources
Severin Skillman (Nov 12 2019 at 15:54):
I'm looking for an authorization mechanism to ensure resources can only be edited by the original author of a resource.
In a simpler data model this would be trivial - resources would have a "createdBy" field which can be compared to the id of the authenticated user of a write request against that resource. However I haven't come across an appropriate generic way to do this in FHIR.
It looks like using some combination of security labels, provenance and/or history (+ JWT information) would seem like the way to go. I can see a number of possible approaches though and am curious how other implementers have approached this? And how this approach would differ when the author is not an individual, but a system for example?
Jose Costa Teixeira (Nov 12 2019 at 16:02):
if you need a createdBy, you could have an extension
Severin Skillman (Nov 12 2019 at 16:07):
An extension would allow to add a "createdBy" field, but my understanding is that this information is covered by the Provenance resource so its use should be preferred over adding an extension, right?
Severin Skillman (Nov 12 2019 at 16:08):
The only thing that strikes me as odd is that provenance is application-prepared, until now I always thought of this information as being set by the server (trusted)
Lloyd McKenzie (Nov 12 2019 at 16:10):
It depends on the use-case. Some Provenance information is usually included inside the resource. However, if the use-case is that you're always going to need it when determining access permissions, joining to Provenance isn't going to be terribly efficient/reasonable. A redundant extension would be acceptable in that case.
Severin Skillman (Nov 12 2019 at 16:50):
Yes, often there is some provenance in the resource that can be used to perform these kinds of checks.
I will probably opt for using Meta.source. which will enable my use-case with minimal complexity.
John Moehrke (Nov 13 2019 at 02:39):
Yes Meta.source is one model for this. Another is to use meta.security where you tag each resource as it is created with a 'security compartment' code. Where you are managing the 'security compartment' codes, one for each user (aka, the user's name becomes a compartment code). Then when an Update or Delete is attempted, you can just compare the user identity to the resource.meta.security... In this way you can evolve to multi-ownership of resources, and even group ownership.
John Moehrke (Nov 13 2019 at 02:40):
Both of these models (meta.source or meta.security) would be examples (simple) of Attribute Based Access Control (ABAC).
Last updated: Apr 12 2022 at 19:14 UTC
