Determine an approach to security

[kpshek]

From @jmandel on March 17, 2016 20:14

Two main use cases for authentication / authorization

1. CDS Service needs to authenticate the EHR for a service invocation
2. EHR needs to authenticate the service --> simple bearer tokens

For (1), we could use a signed JWT in a header. Or an OAuth flow.

For (2) we have a current solution (passing OAuth tokens in the input parameters to $cds-hook). Is this good enough?

Copied from original issue: cds-hooks/cds-hooks#12

[isaacvetter]

Hey Kevin, All,

For (1), I think we should just defer to the existing, albeit largely unimplemented SMART backend service flow. Which is currently a signed jwt, as you/Josh suggest.

For (2), I think the current approach is good, some comments:

• Why don't the attribute names match what SMART calls them: expires_in, not expire, access_token, not token.
• Again for consistency's sake, SMART requires a hardcoded token_type with a value of "bearer". Shouldn't cds-hooks too?

Isaac

[kpshek]

In previous conversations, we have said that the CDS service should have the same access privileges as the current practitioner. Thus, the FHIR data the CDS service is able to retrieve should be only the data the current practitioner has privileges to retrieve. I confirmed this with two physicians that I work with at Cerner.

Given this, this precludes us from using the SMART Backend Services model or what is commonly referred to as B2B tokens. This is because this security model does not contain the notion of a user and thus the token is not scoped to the privileges/authorization of the current practitioner. Additionally, B2B tokens are scoped to the entire patient population but a more appropriate and secure model for a CDS Hooks invocation would be scoped to the current patient in context.

This leads us to using OAuth 2 access tokens with an embedded practitioner (and the current patient in context). Effectively, the same tokens obtained by a SMART app during an embedded launch.

I agree with @isaacvetter that we should use consistent field names between SMART and CDS Hooks; access_token, expires_in, and token_type (always Bearer). I think we should return scope too.

To ensure proper auditing, I think each CDS service should have it's own client id. This allows the EHR to track each FHIR access with the calling CDS service. As such, this means that each CDS service will have a distinct access token.

For performance reasons, we have also previously discussed the EHR managing the creation, lifecycle, and management of these access tokens and provide them to the CDS services upon each hook invocation. I'm fine exploring this strategy to see how it works.

---

I've had informal conversations with some on data or event-based CDS Service invocations (as opposed to the current user-invoked hooks). In this scenario there is no practitioner in context causing the CDS service to be invoked and thus will necessitate a different security model. In this case I believe we do need to leverage the SMART Backend service / B2B model. Additionally, I do not think it is necessary for the EHR to manage the OAuth access tokens in this case. I call this out here just for completeness but we'll handle/discuss this on a separate issue when we broach this topic more formally.

[jmandel]

Going back to the original two goals...

I think the discussion here is focused on (1), which is to say: how the CDS Service should authenticate itself to the EHR? If the EHR just passes the access_token (and expires_in, etc) along to the service at launch time, this works — though it's worth saying that it relies entirely on a service's SSL certificate (https URL) for security, similar to a public client in SMART's EHR launch flow. We could give the client an opportunity to authenticate before it receives a token, e.g. by passing the service a launch id (which gets traded for a token in an authenticated call) rather than a ready-to-go access token at invocation time. Technically, either approach works; this is a security design decision, and we'd want to understand our threat model and choose accordingly.

For (2), which is to say "how the EHR authenticates to the service", I think my assessment back in 3/2016 was wrong, or incorrectly written. This is a use case where the Backend Service flow (with the ERH as the client and the CDS Service as the server!) would work. Or else we could pick something simpler (like a fixed secret)... but it's hard to explain why that simpler solution is "good enough" in this direction but not the other. In general, CDS Services can/will hold sensitive data just as much as EHRs will, and authenticating to them should be just as important as authenticating to EHRs.

[isaacvetter]

how [should] the CDS Service authenticate itself to the EHR?
(1) relies entirely on a service's SSL certificate (https URL) for security, similar to a public client in SMART's EHR launch flow.
or
(2) pass the service a launch id ... rather than a ready-to-go access token at invocation time.
Technically, either approach works; this is a security design decision

I think that the EHR providing a launch token, instead of an access token in the cds request, is prohibitively expensive in terms performance.

Also, if the launch token was somehow determined to be invalid by the OAuth server, the cds-service doesn't have the option of presenting a login screen to the user.

It seems clear to me that the EHR should provide an access token as part of the cds request to the cds-service.

For (2), which is to say "how the EHR authenticates to the service", I think my assessment back in 3/2016 was wrong, or incorrectly written. This is a use case where the Backend Service flow (with the ERH as the client and the CDS Service as the server!) would work.
👍

[kpshek]

Re-opening this issue; I accidentally closed it when I incorrectly referenced it in 9ff155a ☹️

[kpshek]

I (finally!) wrote up a summary of our past security discussion from the January 2017 Connectathon in San Antonio, TX which touches upon the topic discussed here.

[jmandel]

Thanks @kpshek! For the final section, I've added a quick proposal for a signed token scheme.