Stream: FHIRcast
Topic: Is user authentication necessary? Use client key only.
George Kustas (Dec 23 2019 at 15:13):
We have completed "round 1" of FHIRCast implementation testing/proof of concept/demonstrations. It was all done using authentication at the client level only (on our FHIRCast hub - PowerCast).
We're now revisiting the issue, and I'm trying to come up with a user-level authentication (and topic creation) design.
I'm still struggling... Because at the end of the day, user credentials will have to be located in a central (OAuth) repository, or apps will have to be "launchable" by a master driving application that will pass them an access token. I don't see this happening in the near future. As we have discussed in other threads, there are several reasons why some client applications can not be launched via SMART on FHIR. If they are standalone launched, they still need to authenticate the user at a common authentication server so that they receive the same scopes and topic. Can we really expect every collaborating FHIRCast vendor (and their customers!) to register their users in a common repository just to be able to use the FHIRCast Hub?
I propose that the FHIRCast Hub can be adequately secured using client credentials only (see how it's done in Auth0: https://auth0.com/docs/flows/concepts/client-credentials).
If we make the assumption that each participating application is ALREADY performing client authentication prior to subscribing to the hub, then what do we need user level authentication for? One might say that user roles or scopes are necessary. I don't think so. The FHIRCast HUB is a simple message switch. It doesn't maintain context, and it probably shouldn't be controlling user roles and scopes either. Who decides whether a user should have read or read/write permission for an imagingstudy-open event? Or what that even means? This is ultimately the responsibility of the application itself, and shouldn't be enforced by the hub.
As far as topic creation, I think a simple, shared naming standard would work just fine. I'll make one suggestion (for now) as to how that could be done. There are other, probably better, ideas out there. Consider this:
-
The topic doesn't need to be unguessable or secret. The Hub is only going to accept or distribute notifications to subscribers that subscribed with valid authentication tokens. Obtaining a topic doesn't obtain anyone access to FHIRCast data.
-
Most applications store enough information about their users to create a unique id within the FHIRCast environment. User names, email addresses, first/middle/last names, or some other internal identification number. The client application should be designed with enough flexibility to be configured to have options and any given customer location. That way, a common denominator can be found among all collaborating applications. So, if the common denominator is business email address, then that is the topic - no encryption or other manipulation is necessary.
Please feel free to shoot me down here and now if I'm missing something important. I can take it!
I'd appreciate your thoughts @Isaac Vetter @Will Maethner @Bas van den Heuvel @Martin Bellehumeur @David Rubin @Niklas Svenzén @Bill Wallace
Martin Bellehumeur (Visage Imaging) (Dec 28 2019 at 10:00):
Hi,
I am not aware of a customer planning to move to an OAuth platform for their user management therefore requiring this would be a no-go for implementation.
I think we should align with the Invoke Image Display (IID) standard in regards to authentication/authorization and let each application take care of it (as they do now). Perhaps we can reuse the text from IID.
It would be great to keep a section that discusses SMART and CDS launches but it cannot be a requirement that the site must replace their current auth platform.
Topic creation is going to be interesting when we consider workflows with more than one device and more than one user.
All the best for 2020,
Martin
George Kustas (Jan 03 2020 at 13:44):
@Martin Bellehumeur - thanks. But regarding client authentication: Don't you think it is reasonable to use OAuth2 and/or some sort of web token authentication? Since there is only one entry per vendor, I don't think it will be prohibitive to implement.
Can you elaborate on IID? I see the IHE document for it but I am having trouble finding anything specific to authentication.
Martin Bellehumeur (Visage Imaging) (Jan 05 2020 at 12:15):
@George Kustas : IID handles it under "Security Considerations" section here:
https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_IID.pdf
I'm ok with application authorization and this is handled by the shared secret I think.
Last updated: Apr 12 2022 at 19:14 UTC
