Stream: subscriptions
Topic: security token for callback
John Moehrke (Sep 10 2017 at 21:21):
Has there been discussion on how the subscription carries a security token for the callback?
Grahame Grieve (Sep 10 2017 at 23:00):
no. there's been no discussion
John Moehrke (Sep 10 2017 at 23:22):
In a project I was on, we used Subscription on DocumentReference as a way to produce a RESTful (FHIR) API that was asynchronous. We found that he callback needed some kind of security token. Initially we were thinking of adding an extension to carry this token. But what we were able to do is just do the callback without security token, given very constrained environment. Having a way to put a security token into the subscription might be a useful feature. Seems this would also be a good way to deal with this similar problem in cds-hooks. Where this security token is just for the 'next' call (callback in subscription, but call forward for cds-hooks). WHere as the http auth token is then focused only on if the subscription requiest is authorized... sound reasonable?
Grahame Grieve (Sep 10 2017 at 23:25):
follow the logic of conforming to cds-hooks, but there's a much wider range of implementation contexts for subscription (as opposed to cds-hooks)
Grahame Grieve (Sep 10 2017 at 23:25):
didn't follow the 'next' bit
John Moehrke (Sep 10 2017 at 23:40):
sorry. I am discussing cds-hooks and subscription as if they are the same thing... but they are only the same thing in that Party ONE is asking Party TWO to have a transaction with Party THREE.. where Party TWO needs to have some security token when communicating with Party THREE. In subscrption the Party THREE is the callback service endpoint, in cds-hooks it is the prefetch target server... right? Are there others that need this kind of an interaction model, so that we can look to a pattern? The main point is that security token for TWO-->THREE does not need to be (and should not be) the same securty token used b ONE--> TWO.
John Moehrke (Sep 10 2017 at 23:41):
and where the security token is only usable by TWO for the purpose of transaction with THREE.
Kevin Shekleton (Sep 10 2017 at 23:57):
I'm not sure if I'm following this conversation (not having worked on Subscriptions this weekend) or the analogies, but I believe the Party THREE you are referring to in CDS Hooks is the EHR FHIR Server.
Kevin Shekleton (Sep 10 2017 at 23:58):
I'd be interested to chat with you both on this further. It may be beneficial to discuss offline - perhaps at the bar later :-)
Grahame Grieve (Sep 10 2017 at 23:58):
in the FHIR subscription model, it may also be the EHR FHIR server. but it may be all sorts of other things as well.
Grahame Grieve (Sep 11 2017 at 00:04):
for now, there is no security arrangements on subscription for the push at all. You can do a push without any content, if there's no security arrangements. or else, the system may now the appropriate arrangements out band. The space in the middle is punted to the future
Grahame Grieve (Sep 11 2017 at 00:05):
each of the channels has it's own security token requirements/options
Grahame Grieve (Sep 11 2017 at 00:21):
sms: no security
email: security by direct, or none. For direct, there's nothing to say in the subscription resource
message: what security applies depends on the delivery method. We describe a HTTP post method, but indicate that MLLP, MQ series etc could be used. All these have different tokens
Isaac Vetter (Sep 11 2017 at 00:21):
Hey Guys,
Interesting conversation. @John Moehrke - I'd love to hear more about your experience using Subscriptions with Document Reference.
Grahame Grieve (Sep 11 2017 at 00:22):
websockets - has it's own model that isn't replicated into the subscription resource
Grahame Grieve (Sep 11 2017 at 00:22):
rest-hook- either a bearer token or a user name and password, and potentially a certificate identity
Isaac Vetter (Sep 11 2017 at 00:24):
In addition to Grahame's points, note that the current spec's optional Subscription.channel.payload element. Lack of a specified payload in the Subscription causes the server to simply "ping" the subscribed client, such that there's no data in the notification's body and the client must query the FHIR server to understand the recent change. (This neatly sidesteps the exact security need you're describing).
Grahame Grieve (Sep 11 2017 at 00:25):
yes that's why it exists as an option
Isaac Vetter (Sep 11 2017 at 00:25):
For the rest-hook specifically, @Niklas Svenzén and I had briefly talked through the use of the OAuth access_token created either via an actual "front-end" SMART app integration and/or via the OAuth client credentials / SMART Backend Services flow.
Grahame Grieve (Sep 11 2017 at 00:27):
that's one logical option, yes
Isaac Vetter (Sep 11 2017 at 00:31):
Thanks, @Grahame Grieve :)
Lastly,
in that Party ONE is asking Party TWO to have a transaction with Party THREE..
in the case where ONE is the FHIR Server, TWO is the EHR (or other clinical workflow system) and THREE is the subscribing FHIR client --
It's not obvious to me that FHIR Subscriptions actually requires TWO at all. Right?
Grahame Grieve (Sep 11 2017 at 00:32):
well, there's 3 logical parties, but one actual party could play two of the roles - or even all 3
Isaac Vetter (Sep 11 2017 at 00:38):
@Grahame Grieve - @Bill Harty walked through a scenario this morning, where his system was both the subscribing client and the cause of the change that he was notified of (I'm pretty sure that he was even testing against your server).
While, sure, you can argue that there are three parties in this case, I'm pretty sure that we all agree that notifications come from the FHIR Server that holds the Subscription -- party ONE.
Grahame Grieve (Sep 11 2017 at 00:47):
I have uses for my server arranging for it to notify itself of a change. that's just reusing the infrastructure for internal usage
Nick Hatt (Sep 11 2017 at 03:19):
Webhooks are generally an unsolved problem as far as authentication/authorization go. By unsolved I mean no IETF standard that covers them. In fact, authentication and authorization aren't necessarily that important as verifying that sender is who they say they are. That's the model behind github webhooks - they provide a HMAC signature of the body of the payload, hashed using a secret that the subscriber provides. Of course Oauth works fine too, but moreso 2-legged bearer token style.
John Moehrke (Sep 11 2017 at 15:41):
I fully expect there are solutions in the general IT market. We should not have to invent something special in FHIR. What I think we could do is help identify patterns, so that parties can indicate their alignment on the same pattern. The security wg might get some time to talk about this on Wednesday Q3.
Nick Hatt (Sep 11 2017 at 17:17):
The examples for criteria don't include a URL. We would hypothetically be a subscription aggregator, one endpoint to manage subscriptions to various FHIR servers, and some kind of identification of which resource owner should get the subscription would be essential.
Grahame Grieve (Sep 11 2017 at 17:21):
hmm. sounds like a different element to me
Isaac Vetter (Sep 11 2017 at 17:26):
... subscription aggregator, ... which resource owner should get the subscription would be essential.
Hey @Nick Hatt ! In your aggregator scenario, note that a lot of the time, the authenticiation mechanisms (probably OAuth access_token) will also be specific to the FHIR server/tenant as well. So an aggregator would definitely be managing endpoints and other information already.
Nick Hatt (Sep 11 2017 at 18:05):
@Isaac Vetter We manage tokens as well, so people log into our site and setup OAuth through our platform. It lets people offload the complexity of refresh tokens, monitoring, and troubleshooting. In other words, our customers authenticate to us once, so they need some kind of content-level flag to indicate which FHIR server/tenant/EHR/deployment they care about. But as @Grahame Grieve suggests it can just be an extension, or even a custom HTTP header on subscription create.
Last updated: Apr 12 2022 at 19:14 UTC
