Stream: FHIRcast
Topic: Authentication
George Kustas (Jan 18 2019 at 22:10):
@Martin Bellehumeur Have you started with OAuth yet? I'm just looking into it on my side. Microsoft supplies OWIN.OAuth, so I won't have to implement any low level stuff. I'm still not clear on how I want to implement certain things though.
We need to create a topic that is based on an identity (radiologist). The only way I see this happening is to create a configuration file/database in the hub (which will also be my authentication server). It will enable the authentication process to identify the application user based on their credentials, and return them a topic (essentially the session id).
From a customer implementation perspective, this could get kind of ugly if individual passwords are required for authentication. @Isaac Vetter suggested that we could use an application-wide secret, which would make it easier. However, we still need to configure users and their grouping. For example, if I am "gkustas61" on a PACS but "georgek" on Powerscribe, someone needs to configure that. When authentication occurs, the association is made so that they both receive the same topic.
Any thoughts?
Martin Bellehumeur (Visage Imaging) (Jan 19 2019 at 13:34):
Hi, I had a busy week with major work-life change. Sorry, not much progress but this coming week will be much better.
I hope we can diverge from the topic definition as defined by websub. I see it the same way, the topic for us is a user session (for websub, it's a service such as a blog and they contact that service to find out if where is the hub). So we should propose a mechanism to resolve "users of apps" to a 'user fhircast session- or cast-session' and this would the topic instead of a URL. At a minimum, we need to receive the name of the app (which would identify the common secret which we would not send out) and the user identifier in that app. The hub would need to keep a table of user ids for each app.
George Kustas (Jan 20 2019 at 16:09):
@Martin Bellehumeur Thanks for the reply. I hope everything is OK.
Yes - we agreed to use the topic to identify the session, in fact, removed cast-session from use.
I'm going to take some time to think about this mechanism in a way that addresses:
1) security - authentication should produce the topic
2) reasonable usability from a configuration standpoint - how often will a client app customer need to re-configure based on new/removed users? Can it be automated (triggered) by an application server? Would client app vendors implement that and support it?
3)Guaranteed synchronization between client and hub (integrity).
I'll share some ideas as I go along. We only have until May to come up with a specification and a working prototype that follows that spec. This mechanism we're talking about could perhaps be loosely defined in the spec so that the it can be implemented in different ways. But we should also expect that new client app vendors entering into FHIRCast are going to look at real work examples first. I know I would.
George Kustas (Jan 20 2019 at 23:29):
@Martin Bellehumeur , @Isaac Vetter @Leo Bergnéhr @Will Maethner
Suggested mechanism for simple client authentication and topic creation. Please take a look and see if you have any comments or suggestions.
Data model:
pasted image
Existing values (as an example):
pasted image
1. The "authentication server" (which in my prototype will be my FHIR hub) will provide a REST method for authentication. Example: https:/hub-fhircast.nuance.com/authenticate?username=joe&secret=61B584A8-C5AD-4A87-A40F-19E448EEBBAD
2. The method will return a topic (client id/session id) of 1A3DF21C-1451-4DC5-8B59-3F824D3A7ED7 based on the existing values shown above
3. If I launch the test app, I can authenticate using: https:/hub-fhircast.nuance.com/authenticate?username=joe2&secret=EF25A906-1C48-4E87-AC1F-0E48366AAEEB.
4. I would then receive the same topic as I did in step 2.
Both apps would then subscribe using this topic and share context from there on.
John Moehrke (Jan 21 2019 at 15:41):
Please put in a Security Consideration to remind the implementer to choose the best-available-randomness-on-their-platform for creation of these nonce. Essentially to assure they don't just use a timestamp or counter when a random function is available. Poor nonce will significantly weaken this session authentication mechanism. (this is noted in websub https://www.w3.org/TR/websub/#security-considerations, just need emphasis)
Martin Bellehumeur (Visage Imaging) (Jan 22 2019 at 12:56):
Yes but maybe it would be easier to get buy-in if we align attribute naming to OpenID.
George Kustas (Apr 25 2019 at 13:20):
I'm hoping to revive this thread... We've been using my proposed simple authentication/authorization scheme above for prototyping. We want to start designing a more permanent solution. Everyone seems to agree on OAuth in one way or another. SMART Launch - I hope - will be an option for us. I've read http://www.hl7.org/fhir/smart-app-launch, and I think we could fit into the "standalone launch" scenario, if...
1. it will work even even though our app is not browser based (which I think is OK), and
2. it doesn't require an endpoint/redirect uri on our app (client). This is the same restriction that brought us to websockets to begin with.
Again - we're thinking about context sharing as possible data sharing for "things" related to imaging studies. I feel that once we (PACS, RIS, EHR and reporting) have a valid topic (user session) established, we're ready to go.
My question is, can our app, which is an executable launched by the end user, authenticate and receive a topic using the SMART launch specification. If so, has anyone looked into doing this? @Leo Bergnéhr perhaps? @Martin Bellehumeur ?
Isaac Vetter (Apr 25 2019 at 14:53):
Hey George, the SMART standalone launch sequence requires a redirect url. There's a couple approaches for this url for mobile/desktop apps.
Isaac Vetter (Apr 25 2019 at 14:53):
1) Register a custom protocol handler on the end-user device/Windows machine, e.g. myapp://; then have the OAuth server redirect to this url.
Isaac Vetter (Apr 25 2019 at 14:53):
2) The various OS's have somewhat recognized this problem and created: Windows "app URI handlers", Android app links and iOS Universal Links. These variously named technologies all work in the same way and allow a desktop/mobile app to be associated with a regular https url, such that when the registered url is navigated to, the app opens instead of a browser.
George Kustas (Apr 26 2019 at 14:59):
Interesting... But we would still need an SSL cert, right? Or maybe not, since we can require that the auth server be inside the customer's intranet. This is where our current HL7 Bridge server is, and we can actually put it on the same box.
Thanks Isaac. I'll look into this.
Isaac Vetter (Apr 26 2019 at 16:57):
Hey George, if you used the Windows "app URI handlers" functionality (which looks like it's limited to IE Edge), then I don't think that you'd need a local SSL cert. The intent of these app URI handlers functionality is that an app's public/internet website uri is used as the url for the locally installed app.
George Kustas (Apr 26 2019 at 17:45):
Thanks again. I think we will be able to create a simple endpoint in our Powerscribe executable that can handle the redirect. Of course that's assuming that the Auth server will reside in a safe internal network, not in the cloud. If we need to use an auth server in the cloud, we could create a "proxy" endpoint in our HL7 server to handle the redirect, which we would secure with a SSL cert. It would require one more level of communication from the client to the auth server, but it's workable.
Isaac Vetter (Apr 26 2019 at 19:16):
Hey George, even with the auth server in the cloud, the auth server is telling a browser to redirect to a url. The browser is resolving the url; so redirect urls need to be accessible to the browser, not the oauth server. Does that make sense?
Isaac Vetter (Apr 26 2019 at 19:19):
Further, I've seen some SMART apps implement the EHR launch flow, without redirecting a browser as part of the interaction with the OAuth server's /authorize endpoint, but rather, assuming there's a launch token, call the /authorize endpoint as a RESTful web service themselves. This has the potential to both improve performance and to simplify non-browser based SMART apps. I don't understand the security or authorization implications of this approach.
Grahame Grieve (Apr 26 2019 at 20:13):
I hadn't come across the windows app URI handlers, but they smell to me. User doesn't control whether to get the local app or not, and app doesn't control it either? feels like the worst of both worlds...
Isaac Vetter (Apr 26 2019 at 20:59):
Grahame, these app URI handlers are really just a more secure version of registering custom protocol schemes as redirect urls in an OAuth2 server. For example, if a developer specifies a redirect url of myapp://, this "protocol" must be registered in the OS as part of the app installation. This also presents an attack vector by a 3rd app registering this protocol. These app uri schemes provide an OS-assured method for a redirect url to be known to be owned by the app. When the OS hasn't verified that the https url should open the app, it naturally opens the web page.
Isaac Vetter (Apr 26 2019 at 20:59):
(Sorry, not explaining this well).
Grahame Grieve (Apr 26 2019 at 21:17):
I'm sceptical that it solves the problem. I'll investigate
Josh Mandel (Apr 27 2019 at 13:34):
This approach is certainly the cleanest way to reuse existing SMART specs. Will be good to see what folks learn by trying. If it doesn't hold up in practice, I'd love to help with formalizing the constraints here, so we can explore other OAuth flows.
George Kustas (May 01 2019 at 16:11):
Sorry I'm late with a response... I don't know if this matters or not, but our app isn't looking to be "launched". We are a desktop (Windows WPF executable) that is launched automatically at user login. When a user logs in (with valid credentials store locally, active directory, etc...), we want to authenticate with the FHIRCast OAuth server simply for the purposes of obtaining a topic (user session) that matches with the same user's "other applications" like PACS, RIS, EHR. Whatever it takes, SMART FHIR or something else, we want to confirm to whatever the standard becomes. We want other vendors to be willing and able to work with our hub (should they desire).
George Kustas (May 01 2019 at 16:22):
conform, not "confirm". So Isaac, are you saying that we can obtain the token needed without being redirected to, obtain a token (as part of the HTTP response), and then use that token to query the auth server for a topic? I didn't get that from the article, but I'll investigate further. That is certainly an option. Again - our only problem is having to expose our app clients to the cloud, because that would require an SSL cert for all of them (major implementation issue).
Leo Bergnéhr (May 08 2019 at 14:19):
I guess there's also the not-very-elegant way of hosting a webserver on the client app.
Last updated: Apr 12 2022 at 19:14 UTC
