FHIRcast logo

FHIRcast
3.0.0-ballot - ci-build International flag

FHIRcast, published by HL7 International / Infrastructure And Messaging. This guide is not an authorized publication; it is the continuous build for version 3.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhircast-docs/ and changes regularly. See the Directory of published versions

Security Considerations

This page contains guidance to implementers and is not part of the normative-track.

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 Protected Health Information (PHI).

Actors

  • Subscribing application
  • Hub
  • Authorization Server
  • Resource server

FHIRcast ties SMART as the authorization layer together with a WebSub mechanism for subscription and event notification.

Sources of Risk

  1. The FHIRcast Hub pushes PHI to a dynamic URL specified by the authenticated application.
  2. An application's credentials or a Hub's lack of authentication could be used by a malicious system to control the user's session.
  3. FHIRcast recommends the use of SMART on FHIR, but does not require it. Implementation-specific launch, authentication, and authorization protocols may be possible. These alternate protocols should be scrutinized by implementers for additional security risks.

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 syntax for standard OAuth 2.0 scopes, as well as two new SMART launch parameters of hub.url and hub.topic.

Access to non-authorized content

Access to non-authorized content is a critical issue in healthcare data exchange, as it can lead to privacy breaches and unauthorized use of sensitive information. In the FHIRcast event-based communication model, various types of content can be shared among applications that are connected to a session, such as updates to the current context, selected resources, and exchanged resources.

To ensure that only authorized applications can access and share content, the FHIRcast specification includes a mechanism for checking authorization when a Subscriber subscribes to a session. This mechanism ensures that each application can only receive events that it is granted authorization to access. The responsibility of providing a valid set of authorizations lies with the authorization server.

WebSocket Security Considerations

It is recommended that Subscribers use and Hubs should only accept connections made over the secure wss:// WebSocket protocol and not the unsecured ws:// WebSocket protocol.

The WebSocket 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 Web browser, in which case the Web browser enforces origin reporting to the Hub, or native applications in which the origin reported to the Hub can not be trusted. Therefore, a Hub exposing a WebSocket connection may not rely upon the origin sent by the Subscriber.

While native application Subscribers can send any standard HTTP headers, notably including Authorization: Bearer, Web browser-based subscribers are limited to only HTTP Basic Auth or cookies. Therefore, the typical use of the OAuth 2.0 access_token for bearer authentication does not consistently work with WebSockets. FHIRcast describes a "ticket"-based authentication system, in which the hub.topic 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 hub.topic values.

Unauthorized access to Websockets is also addressed by providing a Subscriber unique unguessable WebSocket endpoint with a limited lifetime.