Stream: cds hooks
Topic: Proposed Security Model
Chuck Feltner (Jun 23 2017 at 13:08):
I looked over the Proposed Security Model. Here are a few questions:
1. The proposal has the EHR server obtaining an access token on behalf of the CDS Service. Do we intend to specify which OAuth2 flow will be used for this? The SMART On FHIR Authorization Guide specifies the use of the OAuth2 Authorization Code Grant flow. But that flow seems to require a user interface for entering credentials and optionally for presenting a prompt for the user to grant access. So it would not seem to fit for this server to server exchange. For server to server, it appears the Client Credentials Grant or Resource Owner Password Credentials flows are recommended.
2. The Access Token is sent to the CDS Service when the CDS Service is called at triggering of a CDS Hook. Does the CDS Service then cache the Access Token so that when a SMART application is launched from a CDS Service card it will have the access token to use for the subsequent queries to the EHR server?
Isaac Vetter (Jun 23 2017 at 17:55):
Hey @Chuck Feltner ,
1) I think that the intent is the "client credentials grant".
2) No. The cds service and smart app shound't need to be the same system / able to exchange an access token. The SMART app is launched from the EHR with a standard SMART launch token and gets it's own access token from the EHR's OAuth2 server.
Any concerns with the above approach?
Chuck Feltner (Jun 23 2017 at 19:52):
Thanks @Isaac Vetter. That makes sense.
Is there any concern that the user session which triggers the CDS Hook may not be authorized for all of the scopes that the CDS Service is requesting?
User: clinician1, allowed scopes=patient/Patient.read
CDS Service: CDSService1, allowed scopes=patient/Patient.read,Observation.read,MedicationStatement.read
Robert Sax (Jun 29 2017 at 12:00):
In looking over the proposed security model I have a few questions that are somewhat inter-related:
1. I may be missing something in the documentation on SMART and in the proposed security model, but I do not understand how the app pointed at by link.url authenticates to the CDS service. There is no requirement that they are the same, yet the app will generally need to access the CDS service (probably more often than the FHIR service) and will need to reference the session created by the request that provided the link.url. This applies equally to the non-SMART app. I am assuming that authentication would need to be part of the URL?
2. How will the analytics endpoints be authenticated by the service? How will the service know which hookInstance an analytics request is about?
3. Depending on the answers from 1 and 2, both link.url and the analytic endpoints have a fixed string which may contain authentication credentials. To maintain security, these must have a timeout and may be one-time in nature. How do we inform the EMR of this? I mean there is nothing that says that a displayed card needs to be acted on within an hour, a day, a week, month, etc.
4. Proposed JWT aud. What does this refer to? The specific endpoint, a prefix to it, or a token request endpoint? ie: 'https://example.com/cds-services', 'https://example.com/cds-services/medication-echo', 'https://example.com/cds-services/medication-echo/analytics/C919155B-2138-4177-A316-524CB48B4EC9', 'https://example.com/token'
Robert Sax (Jul 10 2017 at 16:01):
@Josh Mandel, @Kevin Shekleton, @Isaac Vetter thoughts on the above questions?
Kevin Shekleton (Jul 14 2017 at 03:44):
Sorry I'm so late to this conversation guys. I've been off of Zulip for too long!
@Chuck Feltner & @Isaac Vetter, regarding question 1. There is no intent behind the OAuth2 flow so I wouldn't say that we're targeting the OAuth 2 client credentials grant. The EHR owns the authorization server so it can obtain access tokens however it sees fit, including eschewing any OAuth 2 workflows. As long as the access token is accepted by the FHIR server, the manner in which it is obtained is an implementation detail of the EHR.
Kevin Shekleton (Jul 14 2017 at 03:45):
@Robert Sax - I replied to your questions on #55. Sorry for not being online here earlier to reply and thanks for your patience. :-)
Chuck Feltner (Jul 17 2017 at 13:08):
@Kevin Shekleton , regarding question 1. While it does seem that all EHRs are providing both a FHIR Server and custom OAuth2 Authorization Server, showing the interaction between the servers using the standard protocols does help to define the interaction. As you said if the EHR provides both the FHIR Server and Authorization server they could achieve this by an internal mechanism but this would be an optimization. Also by not specifying the OAuth2 flow are we limiting the CDS Services from not being able to call the Authorization service directly? Currently, the CDS Service does not have to use the prefetch option and can fetch all of the data once it is called. Wouldn't that require them first to authorize?
Kevin Shekleton (Jul 17 2017 at 17:13):
@Chuck Feltner - I do not think our proposed security model precludes the EHR from obtaining an access token on behalf of the CDS Service via a standard OAuth 2 workflow.
Kevin Shekleton (Jul 17 2017 at 17:16):
If the CDS Service wants to interact with the Authorization (OAuth 2) server directly, it would only be able to obtain a B2B access token and not a token on behalf of the current user. This is because the CDS Service does not have any UI -- it is a service
Last updated: Apr 12 2022 at 19:14 UTC
