Stream: implementers
Topic: permissions, hateoas, can-i?
Josh Mandel (Feb 12 2018 at 20:25):
GF#5884 asks for more HATEOAS-style capabilities, so that a client knows "here's what you're allowed to do with this resources." Another thing we could consider here would be to introduce an explicit permissions API like what Kubernetes does with commands like
kubectl auth can-i list pods
In the context of FHIR this might look something like:
GET /Patient/123/$can-i?interaction=update GET /Patient/123/$can-i?operation=$everything GET /Patient/$can-i?interaction=search GET /$can-i?interaction=history
This is more client-driven (i.e. the client can choose to ask questions) rather than server-driven (i.e. the server pushes a list of allowed transitions to a client).
Pros: no wasted work to compute a long list of permissions that may be irrelevant the vast majority of the time. Cons: clunky; sometimes the answer will depend not just on an interaction name but also the specific arguments (or request body) that would go along with it (but this applies to HATEOAS too).
Thoughts @Grahame Grieve, @Ed Costello , and others?
Grahame Grieve (Feb 12 2018 at 20:27):
I like this a lot more except that I wonder (a) should it cover transactional integrity (e.g. given version X as a header $can-i? (b) does it matter that I can't serve up permissions in the same transaction? not sure about these
Ewout Kramer (Feb 15 2018 at 15:53):
Although it's definitely an improvement, I do wonder how many server implementers would implement it if we would add it to the spec.
Grahame Grieve (Feb 15 2018 at 20:28):
I would because we added it. But I wouldn't have much interesting to say about this in my server other than 'yes'
Grahame Grieve (Feb 15 2018 at 20:29):
but some people have asked for it
John Moehrke (Feb 19 2018 at 14:39):
I like this, it looks much like one of my proposals. And that was ignorant of this. In that I recognized that we have some common query parameters that could be composed into scopes. https://healthcaresecprivacy.blogspot.com/2017/05/fhir-oauth-scope-proposal-using-fhir.html
Christiaan Knaap (Feb 20 2018 at 06:51):
I think there are a lot of details in the authorization that you can not easily convey in the response:
- GET Observation/456/$can-i?interaction=update => Yes, but only if you do not change the Observation.subject, otherwise it may fall out of your compartment.
- GET Patient/123/$can-i?operation=$everything => Yes, but you will not really get everything because your authorization scopes only allow you to see Observation and AllergyIntolerance.
- GET Patient/$can-i?interaction=search => Yes, but not if you do a chained search on general-practitioner, because you don't have authorization to read Practitioner.
For individual requests it is more efficient to simply try the statement. 200 or 401 is the answer you wanted to know. And on a 200 you don't need to re-query for the result. But that does not fulfill the need of the original question: en-/disable buttons on a form based on available interactions.
John Moehrke (Feb 20 2018 at 14:25):
You should never expect an authorization denial to be conveyed to you. It might, but it might be silent. There are two very different policies, one that says that the client is trustable enough to tell it that it is NOT authorized, the other that says that if the client is not authorized then they are not authorized to know that they are not authorized. So you will simply have the results you are not authorized to receive filtered out silently. Often just returning a successful empty Bundle. See http://build.fhir.org/security.html#AccessDenied
Grahame Grieve (Feb 20 2018 at 19:54):
it has to be conveyed on POST/PUT/DELETE
Chris Grenz (Feb 21 2018 at 17:25):
@Grahame Grieve as in you'll know if it works when you try it? Should we add a "try" flag somewhere that would allow a client to check the action without actually executing the action? Useful for things like "before I make my user fill out this form I'll check to see if I can submit the form"?
Chris Grenz (Feb 21 2018 at 17:25):
Of course, all of @Christiaan Knaap 's points about the specifics of the data would still apply.
Grahame Grieve (Feb 21 2018 at 19:36):
you can validate a resource as a put/post - that's pretty much the same thing
Ed Costello (Feb 23 2018 at 03:02):
Certainly the original problem that led to that suggestion is the UI presentation one. For any FHIR APIs exposing mutation operations to and end user context there are going to be operations the people are not authorized to perform. If there is a goal of people building direct end user facing applications that write back and are inter-operable across different back ends then we're going to need to have some standard way of exposing this information, at least at a course level.
Alternatively, if the primary target of FHIR is going to be towards exposing data for query, and mutation is only expected in a more system to system data exchange context then there is a lot less need for something like this. The limits will be far less dynamic and per-record so it's far more reasonable to use a "just try it" kind of approach. Or the kubernetes style that kicked off this discussion.
Since I originally raised that request, I've certainly came to the conclusion that FHIR API mutations are really only going to be inter-operable at the system to system level. User facing applications really do need specific APIs to back them, whether these are using the FHIR resources with application specific surrounds to deal with these kind of authorization considerations, or pure application APIs I don't expect a user facing application to be portable across them, and to be honest I struggle to see a case where it would be valuable to have such portability.
Where as interoperability in querying the data actually is a valuable goal and can be achieved without trying to bake this authorization information into the spec.
I'm curious about what contexts people are thinking about when discussing FHIR interoperability now.
John Moehrke (Feb 23 2018 at 13:45):
The FHIR specification is an Interoperability specification. It should be usable with many security and privacy models. Including security models that are really good, and really bad... This is not a statement of goodness, just an emphasis that the FHIR specification needs to be independent of the security model. This is also not to say that there won't be security models that will be published by HL7 (or other organizations like IHE or Katara); in fact that is happening. In those publications they express clearly how the security model interacts with the FHIR model.
Last updated: Apr 12 2022 at 19:14 UTC
