Stream: subscriptions
Topic: Signed FHIR Requests
Morgan (Feb 11 2021 at 13:49):
I'm currently looking at AWS HealthLake, in particular trying to use a HealthLake DataStore to be the target HTTP hook endpoint for a FHIR subscription created on a remote server.
All requests to AWS HealthLake need to be authenticated using a HTTP header containing a signed digest of the message (signed with an AWS IAM user access and secret key). AWS Docs
It's my understanding that both the R4 and R5 specs only allow for setting a static HTTP header (e.g. bearer token), and that it won't be possible to subscribe to a FHIR server and tell it to sign any subscription bundles that it's sending back?
Josh Mandel (Feb 11 2021 at 16:27):
This sounds like it'd need to be a custom channel (something we're introducing in R5) rather than a standard REST Hook.
Josh Mandel (Feb 11 2021 at 16:31):
Would be a great project to prototype in time for the May Connectathon if someone's interested in developing server-side support for this. The "scaling" issue though is: every server you care about would need to support this custom method specifically for talking with AWS. Two alternatives:
- develop a proxy (e.g., maybe a small cloud function / lambda) to receive FHIR Rest Hooks inbound, and sign/forward to HealthLake
- standardize a signature algorithm that AWS and other "catchers" could agree to
Paul Church (Feb 11 2021 at 17:30):
Google had somewhat similar conclusions from looking into the bearer token on REST hook subscriptions - it's really problematic for the server to hang onto a bunch of very sensitive bearer tokens from various clients, plus managing their renewal etc. Our solution-level answer has been Josh's first suggestion, have an API proxy on the client side that holds the credentials to a cloud service account and can forward inbound requests. Then you can lock down that proxy so only the right server can talk to it, its service account can only do certain operations, and it can be monitored.
It might be nice to standardize something but I suspect it will be tricky.
Morgan (Feb 11 2021 at 19:09):
Thanks. We'd also thought of proxying the requests, it does feel a shame to bypass AWS's quite nice security mechanisms, but needs must I guess.
Paul Church (Feb 11 2021 at 19:13):
Well this is a bit of a standards vs. reality situation, if you control the server implementation you could make it send subscription notifications with proper AWS auth (or GCP, Azure, etc.) This group is likely open to standardizing something to address this use case if we can just come up with what it would be!
Gino Canessa (Feb 11 2021 at 19:23):
Yep, +1 to what they said =). I think the proxy solution will be the most 'generic' (e.g., any server will know how to communicate with it), and will definitely be easier to spin up in the short term.
That said, I do hope to see 'platform' channels in time (again, with a fallback to a REST proxy). Especially since the cloud providers typically also have custom protocols that may be desired over stock FHIR + REST.
Last updated: Apr 12 2022 at 19:14 UTC
