Stream: implementers
Topic: Resource identity upon forward
Alexander Henket (Jun 15 2020 at 12:44):
We are running into a rather unexpected issue that we need some guidance on. The situation:
- I authenticate myself with a care provider (not SMART on FHIR, but that is irrelevant)
-
I send a query to the domain with my OAuth token:
GET http://domain.nl/fhir/Resource -
As response I receive:
Content-location: http://someotherdomain.nl/Resource<Bundle with link and fullUrl pointing to someotherdomain.nl/>
My questions:
-
How am I to understand the identity of the resources contained in the response? It would seem that the only possible response is that the resources belong to a server I never authenticated with (someotherdomain.nl). Relative reference are thus to be understood relative to Content-location (if present)?
-
If I authenticate with FHIR facade/proxy X: should the facade then be allowed to reroute me to an unknown secondary server that allows me to bypass that same facade/proxy upon subsequent requests?
-
Should I assume this next server understands the same security context that I was in at the facade/proxy?
John Moehrke (Jun 15 2020 at 13:20):
I would expect that when you try to GET those resources at someotherdomain.nl you will need to satisfy THAT domain's security / privacy needs. It is possible that is the same security, or might be aligned security in a federation, or might be totally different.
John Moehrke (Jun 15 2020 at 13:27):
In the IHE cases of federations, one would get a Bundle of resources from domain.nl; and these resources might have elements that point at someotherdomain.nl. That is to say that it would be unusual to query domain.nl and get back a Bundle containing Resources with .id located at someotherdomain.nl. So it seems you have something more like a api gateway proxy that is not re-writing the resources to the api gateway location (domain.nl).
John Moehrke (Jun 15 2020 at 13:27):
do you think they are expecting you to continue to address domain.nl when trying to retrieve the resources at someotherdomain.nl?
René Spronk (Jun 15 2020 at 13:33):
Well, if one has a FHIR gateway of sorts that just (without any persistence layer of its own) routes requests to multiple backend servers and bundles the responses, that just means that the requester would have to know that there is a gateway that acts as a (security-) proxy to the systems it represents. I would not assume you'd get access to someotherdomain.nl at all. That after all is what the proxy is for.
Bu what's new? Bundles have always had the capability contain resources that may have fullURLs that point to multiple different servers, so to me this sounds like an extension of that mechanism.
Alexander Henket (Jun 15 2020 at 14:27):
@John Moehrke rewriting is indeed not done here which is why we're considering how that works out. In IHE XDS/MHD using FHIR Documents everything is contained in the Bundle so there would no need to go back to any secondary system based on fullUrl or reference (my assumption). I believe IHE XDS/MHD has an edge here in those cases. Otherwise you are in my boat exactly. If the proxy at domain.nl would rewrite the Bundle we would not have these questions. However: what would you rewrite to if the proxy serves multiple back-ends with potential overlapping resource ids? Would it not be costly to really rewrite a potentially large Bundle?
Another thing is that while Content-location is in the HTTP standard, there is no explicit reference in the FHIR API to it. I think it would help here. Maybe a ticket is in order?
@René Spronk This is a MedMij DVZA talking to a care provider back end (XIS). You authenticate with the DVZA as proxy for a care provider based on a domain on a white list. When you then get data from an unknown domain (i.e. not white listed) with no know relationship to that same care provider, the security implication on the client side is also unknown. Why did I get data from someotherdomain.nl? Do the same policies apply? Am I still talking to the same care provider here?
René Spronk (Jun 15 2020 at 14:36):
(related) What if a care provider has multiple systems that support FHIR APIs ? Are they then allowed to use different server URLs or does MedMij force them to use one single server URL?
Alexander Henket (Jun 15 2020 at 15:16):
Not entirely sure, but it seems the latter. MedMij Afsprakenstelsel only recognizes DVZA/Gegevensdienst, not the backend care provider systems. On the other hand: DVZA operates under responsibility of the care provider, so logically speaking it does not matter. It's just that the location (url) is hard to match against the logical entity
John Moehrke (Jun 15 2020 at 16:16):
if we look at a specific use-case, such as a patient specific CarePlan. This CarePlan resource will point at many other resources that have been contributed to the CarePlan from various locations. Thus I would expect a CarePlan to have many divergent resource pointers. These contributions would all be published within different resource servers. (For example the surgery published in the resource server of the surgery center, physical therapy in the resource server at the physical therapy site, patient contrutions such as regular home measurements of blood presure published in the patient specific (or device specific) resource server.
If I query on the CarePlan and ask for _include; would the results be pulled from the other resource server and included in the one bundle?
If this is done, would provenance be clear? If this is done, would access control be clear? If this is done would audit logging represent facts of who got access?
Alexander Henket (Jun 15 2020 at 16:23):
If I query on the CarePlan and ask for _include; would the results be pulled from the other resource server and included in the one bundle?
I expect so if the CarePlan server respects _include (which is server discretion afaik)
If this is done, would provenance be clear?
I'd expect fullUrls pointing to different sources. Would that satisfy this question or would you expect inclusion of a Provenance resource?
If this is done, would access control be clear?
If the server respects my _include, it can only do so if my security context that allowed me access to the CarePlan, holds for the things it points to as well?
If this is done would audit logging represent facts of who got access?
Good question... if the CarePlan server queried the third party systems for the _include data, you could probably preserve original context. In practice I'd expect that for the third party systems it's as if the CarePlan system requests data on its own?
John Moehrke (Jun 15 2020 at 16:25):
understood.. note that I twisted the orginal question into a specific example where I could see a proxy service could act as a front-door for many respositories... This might not be the case originally... But I feel more concrete is sometimes more clear to discuss.
John Moehrke (Jun 15 2020 at 16:26):
so, I agree that the _include implementation would be dependent on lots of things... hence why it is a good example of why one would get a bundle with multiple sourced resources.
John Moehrke (Jun 15 2020 at 16:27):
and even in the CarePlan case, there is not guarantee that to pull an instance of an Observation that is referenced by the CarePlan will succeed as a direct GET or as a query to that resource server.
John Moehrke (Jun 15 2020 at 16:29):
this careplan example has been tested at multiple FHIR Connectathons, so they might have experience. @Emma Jones @Bo Dagnall ?
Last updated: Apr 12 2022 at 19:14 UTC
