Stream: implementers
Topic: Security tags in a transaction
Sean McIlvenna (Mar 29 2019 at 20:58):
Let's say my system uses security tags to limit what the user can do with specific resources...
Now, I have a transaction bundle that has a bunch of resources in it, some are creates, some are updates. Is there a way to indicate that the updates should only occur if certain security tags are already on the resource?
Grahame Grieve (Mar 29 2019 at 20:59):
no. there's no way to make transactions dependent on anything but existence of a resource
Sean McIlvenna (Mar 29 2019 at 20:59):
damn
Grahame Grieve (Mar 29 2019 at 21:20):
it doesn't sound like a crazy idea but it would be a change proposal...
Grahame Grieve (Mar 29 2019 at 21:20):
or you could use patch
Sean McIlvenna (Apr 01 2019 at 06:12):
how would PATCH make a difference @Grahame Grieve
Sean McIlvenna (Apr 01 2019 at 06:13):
?
Grahame Grieve (Apr 01 2019 at 06:35):
ah no. I thought I added a conditional thing to the patch but I see that I didn't
Brian Postlethwaite (Apr 07 2019 at 08:07):
I would have thought that if the user didn't have access to the version of the resource being updated, you'd get errors.
John Moehrke (Apr 08 2019 at 15:16):
That is likely true of the current security models, as they are most fine grain at the Resource level (Permit vs Deny). However there will be needs for more fine grain security/privacy models that might have ability to have rules at a much more fine grain than Resource. Patch offers a pathway for updating portions that one would not have full access too.
This said, there is nothing preventing a full POST to be used, where the server notices that only an allowed element is actually changing, thus the resulting allowed change very similar to Patch on that element alone.
Brian Postlethwaite (Apr 14 2019 at 20:38):
Yes John, we're currently mid way through that implementation at the moment.
Brian Postlethwaite (Apr 14 2019 at 20:38):
(I.e. Non patch patching)
Grahame Grieve (Apr 14 2019 at 21:46):
I've done something similar. The problem is deletion - is something missing because it's not being changed, or because it's being deleted?
Grahame Grieve (Apr 14 2019 at 22:03):
also, matching changes in a list - change or deletion + insertion. There's no general purpose solution to these problems
Brian Postlethwaite (Apr 14 2019 at 23:13):
Our implementation knows what the previous version from that system provided, so can detect the deletion.
Grahame Grieve (Apr 15 2019 at 10:50):
but what makes it a deletion? that it was omitted? isn't that the point: don't delete what is omitted...
Joel Schneider (Apr 16 2019 at 17:21):
Maybe I'm missing something. Is there a case in which a client-orchestrated full-resource update wouldn't completely overwrite what was there before? (e.g. server-side house rules?)
Lloyd McKenzie (Apr 16 2019 at 17:57):
Servers are allowed to ignore some bits of what comes in. Most common would be to throw away extensions or core elements they don't support. However, in principle, a server could accept an update but not allow changing of a particular element based on its own business rules (e.g. some other system is the authoritative source for names or addresses). If this happens, the server SHOULD produce a warning indicating what it's done. If the resource gets echoed back instead, the client can see exactly which parts of the update "stuck".
Joel Schneider (Apr 16 2019 at 18:42):
Thanks Lloyd. Digging further, I see the FHIR spec discusses variations between submitted and retrieved data here:
http://www.hl7.org/fhir/updates.html
However, I didn't find text there saying the server SHOULD produce a warning indicating what it's done.
Lloyd McKenzie (Apr 16 2019 at 18:46):
Would probably be a good thing to add to the spec. Do you want to submit a change request?
Joel Schneider (Apr 16 2019 at 18:47):
Will do.
Joel Schneider (Apr 16 2019 at 19:45):
Grahame Grieve (Apr 16 2019 at 22:23):
I don't know how it would provide such a warning. OperationOutcome. presumbly, if it is returned, but there's no obvious way to say anything more than human readable
Joel Schneider (Apr 17 2019 at 07:01):
I don't have an immediate use case for a more formal warning mechanism. Would defer to others regarding whether adding something like that would make sense.
Jenni Syed (Apr 17 2019 at 14:33):
RE: operationOutcome - the client also has to request the operationOutcome in the response, a server can't send one unless it's requested with the prefer header: http://hl7.org/fhir/r4/http.html#ops
Jenni Syed (Apr 17 2019 at 14:35):
so the warning would be hidden unless the app specifically requested it
Lloyd McKenzie (Apr 17 2019 at 15:29):
Right. If you're in an environment where it's possible the update might not be applied exactly as you requested, you should either ask for a copy of the stored record back or for OperationOutcome.
nicola (RIO/SS) (Apr 18 2019 at 03:41):
@Sean McIlvenna in Aidbox transaction internally calls same endpoints as if you send entry requests one by one, i.e. we interpret transaction at a server routing level as multi operation request. With this interpretation we run all security checks on updates/deletes and fail transaction is access denied for some of them.
Last updated: Apr 12 2022 at 19:14 UTC
