FHIR Chat · docs / Issue #50 Need Security & Privacy Considerations s... · fhircast-github

Stream: fhircast-github

Topic: docs / Issue #50 Need Security & Privacy Considerations s...

Github Notifications (FHIRcast) (Dec 11 2018 at 20:43):

JohnMoehrke opened Issue #50

During presentation of fhircast to the FHIR Sec it became clear that there should be a Security & Privacy Considerations section in FHIRcast. It would indicate the security decisions made, both positive to security and negative to security.

When leveraging the security of websub, identify those sections. When elevating the security consideration from websub to a higher standard, that should be mentioned. For example, websub uses SHOULD relative to https use, where FHIRcast elevates that to a SHALL.

I think that FHIRcast should also recommend use of BCP195 which are IETF recommendations on proper use of TLS. This likely is just a SHOULD, but I would not discourage a SHALL.

This section should also address security/privacy auditing. I will put in a dedicated issue for this.

Github Notifications (FHIRcast) (Dec 12 2018 at 22:49):

isaacvetter commented on Issue #50

Create a Security Considerations page
* link to WebSub's Security Considerations, and as @JohnMoehrke suggests explain differences.
* link to SMART
* Describe potential auditing scenarios to address #51

Github Notifications (FHIRcast) (Jan 09 2019 at 23:12):

isaacvetter commented on Issue #50

Hey @JohnMoehrke ,

Here's my first, rough pass at a FHIRcast Security Considerations page. Any feedback (besides my flow charts not appearing inline) before a create a PR and ask others for review as well?

Isaac

---

# Security Considerations

FHIRcast enables the synchronization of healthcare applications user interfaces in real-time through the exchange of a workflow event to a small number of disparate applications. The notification message which describes the workflow event is a simple json wrapper around one or more FHIR resources. These FHIR resources can contain PHI.

## Actors

• Subscribing app
• Hub
• Authorization Server
• Resource server

FHIRcast ties SMART as the authnz layer together with WebSub for subscription and event notification.

## SMART on FHIR
SMART on FHIR profiles OAuth 2.0's authorization code grant type and extends it by introducing an "EHR Launch Sequence". The Argonaut Project performed a formal security review of SMART on FHIR, resulting in a Risk Assessment report.

FHIRcast builds on SMART by introducing a new, standard OAuth 2.0 scope of fhircast, as well as two new SMART launch parameters of cast-hub and cast-session.

• HL7 SMART on FHIR specification
• Argonaut Risk Assessment report.
• OAuth 2.0 Threat Model and Security Considerations

## HTTP Web Hooks using WebSub

WebSub is a W3C RFC designed for the distribution of web content through a standardized web hooks architecture. FHIRcast uses WebSub to allow clients to subscribe and unsubscribe to the Hub and, for the Hub to notify subscribers of events.

Unlike WebSub, FHIRcast requires that both the Hub and the subscribing apps endpoints are exposed over https.

The below flow diagram illustrates each of the interactions.


### How does the subscriber authenticate to the Hub?
The subscribing app can make four distinct API calls to the Hub. For each of these calls, the subscribing app authenticates to the Hub with the Hub's authorization server issued SMART access_token. Per SMART on FHIR, this access_token is presented to the Hub in the HTTP Authorization header.

1. App subscribes to Hub
2. App requests change to shared context
3. App requests current context
4. App unsubscribes from session

POST https://hub.example.com
Host: hub.example.com
Authorization: Bearer i8hweunweunweofiwweoijewiwe

### How does the Hub validate the subscriber?
The Hub can make three distinct API calls to the subscribing app's hub.callback url.

1. Hub verifies callback url with app
2. Hub notifies app of event
3. Hub denies subscription

This flow diagram describes the actors and actions.

The subscribing app initiates the FHIRcast subscription, authenticating to the Hub with its bearer token, and providing the hub.secret and hub.callback url. The Hub verifies intent and ownership by performing an HTTP GET to the hub.callback url, with a hub.challenge. The subscribing app must echo the hub.challenge in the body of an HTTP 202 response. Once a workflow event occurs, the Hub notifies the app of the event by POSTing to the subscribing app's hub.callback url. The Hub provides an HMAC signature of the previously provided hub.secret in the X-Hub-Signature HTTP header.

POST https://app.example.com/session/callback/v7tfwuk17a HTTP/1.1
Host: subscriber
X-Hub-Signature: sha256=dce85dc8dfde2426079063ad413268ac72dcf845f9f923193285e693be6ff3ae

### WebSub Security Considerations
The WebSub RFC defines specific security considerations, including the below, which are listed here for emphasis or elevation from optional to mandatory.
* Subscribers must communicate with a Hub over https.
* Hub must reject unsecured http callback urls.
* The subscribing app's hub.callback url should be unique and unguessable.
* Subscribing apps must provide a hub.secret and validate the X-Hub-Signature in the notification message.
* Hubs must reject subscriptions if the callback url does not echo the hub.challenge as part of the intent verification GET.

• W3C WebSub RFC
• W3C WebSub RFC's Security Considerations
• [HMAC RFC 6151[(https://www.w3.org/TR/websub/#bib-RFC6151)

## Experimental Websockets support

In addition to the web hooks communication pattern, the FHIRcast community is experimenting with the use of websockets for event notification. Below are some incomplete considerations for a potential websockets implementation.

Subscribers SHOULD only use and Hub's SHOULD only accept connections made over the secure _wss://_ websocket protocol and not the unsecured _ws://_ websocket protocol.

The WebSockets standard defines an Origin header, sent from the client to the server and intended to contain the url of the client. Subscribers using websockets may be running in a browser, in which case the browser enforces origin reporting to the Hub, or native apps in which the origin reported to the Hub can not be trusted. Therefore, a Hub exposing a websocket connection MUST not rely upon the origin sent by the subscriber.

While native app subscribers can send any standard HTTP headers, notably including _Authorization: Bearer_, browser-based subscribers are limited to only HTTP Basic Auth or cookies. Therefore, the typical use of the OAuth2.0 access_token for bearer authentication does not consistently work with websockets. FHIRcast describes a "ticket"-based authentication system, in which the cast-session url provided to the subscriber as part of the secured SMART app launch serves not only as a unique session identifier, but also as an "authorization ticket". This authorization ticket effectively acts as a bearer token. The Hub should therefore take care to generate opaque and unique cast-session values.

• The WebSocket Protocol RFC 6455
• Heroku's excellent explanation of websocket security

Github Notifications (FHIRcast) (Jan 13 2019 at 14:08):

isaacvetter edited a comment on Issue #50

Hey @JohnMoehrke ,

Here's my first, rough pass at a FHIRcast Security Considerations page. Any feedback (besides my flow charts not appearing inline) before a create a PR and ask others for review as well?

Isaac

---

# Security Considerations

FHIRcast enables the synchronization of healthcare applications user interfaces in real-time through the exchange of a workflow event to a small number of disparate applications. The notification message which describes the workflow event is a simple json wrapper around one or more FHIR resources. These FHIR resources can contain PHI.

## Actors

• Subscribing app
• Hub
• Authorization Server
• Resource server

FHIRcast ties SMART as the authnz layer together with WebSub for subscription and event notification.

## Sources of Risk
1. The FHIRcast Hub pushes PII to a dynamic url specified by the authenticated app.
2. An app's credentials or a Hub's lack of authentication could be used by a malicious system to control the user's session.

## SMART on FHIR
SMART on FHIR profiles OAuth 2.0's authorization code grant type and extends it by introducing an "EHR Launch Sequence". The Argonaut Project performed a formal security review of SMART on FHIR, resulting in a Risk Assessment report.

FHIRcast builds on SMART by introducing a new, standard OAuth 2.0 scope of fhircast, as well as two new SMART launch parameters of cast-hub and cast-session.

• HL7 SMART on FHIR specification
• Argonaut Risk Assessment report.
• OAuth 2.0 Threat Model and Security Considerations

## HTTP Web Hooks using WebSub

WebSub is a W3C RFC designed for the distribution of web content through a standardized web hooks architecture. FHIRcast uses WebSub to allow clients to subscribe and unsubscribe to the Hub and, for the Hub to notify subscribers of events.

Unlike WebSub, FHIRcast requires that both the Hub and the subscribing apps endpoints are exposed over https.

The below flow diagram illustrates each of the interactions.


### How does the subscriber authenticate to the Hub?
The subscribing app can make four distinct API calls to the Hub. For each of these calls, the subscribing app authenticates to the Hub with the Hub's authorization server issued SMART access_token. Per SMART on FHIR, this access_token is presented to the Hub in the HTTP Authorization header.

1. App subscribes to Hub
2. App requests change to shared context
3. App requests current context
4. App unsubscribes from session

POST https://hub.example.com
Host: hub.example.com
Authorization: Bearer i8hweunweunweofiwweoijewiwe

### How does the Hub validate the subscriber?
The Hub can make three distinct API calls to the subscribing app's hub.callback url.

1. Hub verifies callback url with app
2. Hub notifies app of event
3. Hub denies subscription

This flow diagram describes the actors and actions.

The subscribing app initiates the FHIRcast subscription, authenticating to the Hub with its bearer token, and providing the hub.secret and hub.callback url. The Hub verifies intent and ownership by performing an HTTP GET to the hub.callback url, with a hub.challenge. The subscribing app must echo the hub.challenge in the body of an HTTP 202 response. Once a workflow event occurs, the Hub notifies the app of the event by POSTing to the subscribing app's hub.callback url. The Hub provides an HMAC signature of the previously provided hub.secret in the X-Hub-Signature HTTP header.

POST https://app.example.com/session/callback/v7tfwuk17a HTTP/1.1
Host: subscriber
X-Hub-Signature: sha256=dce85dc8dfde2426079063ad413268ac72dcf845f9f923193285e693be6ff3ae

### WebSub Security Considerations
The WebSub RFC defines specific security considerations, including the below, which are listed here for emphasis or elevation from optional to mandatory.
* Subscribers must communicate with a Hub over https.
* Hub must reject unsecured http callback urls.
* The subscribing app's hub.callback url should be unique and unguessable.
* Subscribing apps must provide a hub.secret and validate the X-Hub-Signature in the notification message.
* Hubs must reject subscriptions if the callback url does not echo the hub.challenge as part of the intent verification GET.

• W3C WebSub RFC
• W3C WebSub RFC's Security Considerations
• [HMAC RFC 6151[(https://www.w3.org/TR/websub/#bib-RFC6151)

## Experimental Websockets support

In addition to the web hooks communication pattern, the FHIRcast community is experimenting with the use of websockets for event notification. Below are some incomplete considerations for a potential websockets implementation.

Subscribers SHOULD only use and Hub's SHOULD only accept connections made over the secure _wss://_ websocket protocol and not the unsecured _ws://_ websocket protocol.

The WebSockets standard defines an Origin header, sent from the client to the server and intended to contain the url of the client. Subscribers using websockets may be running in a browser, in which case the browser enforces origin reporting to the Hub, or native apps in which the origin reported to the Hub can not be trusted. Therefore, a Hub exposing a websocket connection MUST not rely upon the origin sent by the subscriber.

While native app subscribers can send any standard HTTP headers, notably including _Authorization: Bearer_, browser-based subscribers are limited to only HTTP Basic Auth or cookies. Therefore, the typical use of the OAuth2.0 access_token for bearer authentication does not consistently work with websockets. FHIRcast describes a "ticket"-based authentication system, in which the cast-session url provided to the subscriber as part of the secured SMART app launch serves not only as a unique session identifier, but also as an "authorization ticket". This authorization ticket effectively acts as a bearer token. The Hub should therefore take care to generate opaque and unique cast-session values.

• The WebSocket Protocol RFC 6455
• Heroku's excellent explanation of websocket security

Github Notifications (FHIRcast) (Jan 22 2019 at 17:12):

isaacvetter closed Issue #50

During presentation of fhircast to the FHIR Sec it became clear that there should be a Security & Privacy Considerations section in FHIRcast. It would indicate the security decisions made, both positive to security and negative to security.

When leveraging the security of websub, identify those sections. When elevating the security consideration from websub to a higher standard, that should be mentioned. For example, websub uses SHOULD relative to https use, where FHIRcast elevates that to a SHALL.

I think that FHIRcast should also recommend use of BCP195 which are IETF recommendations on proper use of TLS. This likely is just a SHOULD, but I would not discourage a SHALL.

This section should also address security/privacy auditing. I will put in a dedicated issue for this.

Last updated: Apr 12 2022 at 19:14 UTC