Stream: implementers
Topic: Fine-grained access control on references
Xiao Yang (Nov 26 2020 at 22:50):
I'm wondering what others think about the fine-grained access control regarding to the resource references. I feel like for Read, it seems that the convention is that users will get the whole resource content, and if there are references on that resource, users will be able to infer that the referenced resources exist (though technically users may not have access to those referenced resources directly).
But Write is more interesting: users can construct a Write request with outgoing references to resources they do not have access to. And if the request is accepted / rejected (assuming server enforces referential integrity), users now know those referenced resources do / don't exist. That seems to provide a way for users to poke the existence of resources they have no direct access.
It'd seem very awkward if we start check access on references.
I feel like it ultimately comes down to how much sensitive info the resource IDs and the existence of resources of those IDs reveal. I'm wondering what others think. Thanks!
Lloyd McKenzie (Nov 26 2020 at 23:16):
I generally think of resource ids as being very similar to primary keys - and the caveats about "don't make meaningful primary keys in your database" hold just as true for resource ids.
Xiao Yang (Nov 27 2020 at 00:32):
I think a caveat is that FHIR allows client to set resource ID in PUT (https://www.hl7.org/fhir/http.html#upsert). So from an implementer point of view, I can't predict what my clients will put in as resource IDs.
Richard Townley-O'Neill (Nov 27 2020 at 03:38):
I expect most systems that allow upsert will have very tight control over who can use it and how they act.
They will not want to be surprised and will be able to predict what clients put in as resource IDs.
Lloyd McKenzie (Nov 27 2020 at 03:44):
In most cases, if you're allowing clients to upsert records (i.e. creating and assigning the id), the ids are going to be GUIDs or you're only going to have one client that has that privilege. Otherwise, you risk collisions.
John Moehrke (Nov 30 2020 at 14:37):
A system that has update privilege that starts to misbehave will be detected by a good audit logging system. Hence why I recommend minimally the use of CRUDE based AuditEvent that is automated by the Resource Server informed by the security tokens it is given. More accurate view can be achieved by clients also logging. Deviations from normal patterns (once normal patterns are learned) can flag pointed review.
Last updated: Apr 12 2022 at 19:14 UTC
