Skip to main content

Fire Arrow Server 1.8.0

· 4 min read
Till Gerken
Till Gerken
CTO

Fire Arrow Server 1.8.0 has been released.

  • (security) Close search-parameter side-channel for property-filtered fields
  • (feature) Resolve FHIR R4 conditional and logical Patient references in authorization
  • (bugfix) Fix inherited roles being dropped when a child organization has a direct role
  • (bugfix) Fix HFQL rejecting every request with 403 Forbidden when no explicit search/read rules are configured
  • (maintenance) Dependency upgrades across server, UI, and tooling

Blocked Search Parameters and Includes​

Property filters redact fields from outgoing FHIR resources — for example, stripping Patient.name so that a practitioner with legitimate interest can list patients without seeing personally identifying information. Until now, the underlying data remained fully indexed, which opened a side-channel: a client could issue a targeted search (Patient?name=Smith) and infer the redacted value from the search result, or use _include/_revinclude to traverse references that had been filtered out of the primary response.

Starting with 1.8.0, validation rules accept two new optional fields that close this channel:

  • blocked-search-params — a list of FHIR search parameter names that are rejected with 403 Forbidden when used in a search, a _sort, or a _filter expression.
  • blocked-includes — a list of _include / _revinclude directives in ResourceType:searchparam form that are rejected when used.

Identifier-Based Patient References in Authorization​

When the authorization layer needs to decide whether an incoming resource belongs to a patient the caller is allowed to access, it previously resolved only literal Patient/{id} references on the subject reference. Import bundles that identified patients by their business identifier — using the conditional or logical reference forms permitted by FHIR R4 — were therefore rejected with 403 Forbidden, even when the caller had legitimate interest in those patients.

Version 1.8.0 accepts all three forms defined by FHIR R4 in the order the spec prescribes:

  1. Literal — Reference.reference = "Patient/123" (§2.3.0.2)
  2. Conditional — Reference.reference = "Patient?identifier=sys|val" (§3.1.0.11.2)
  3. Logical — Reference.identifier (§2.3.0.3)

Ambiguous identifiers (more than one Patient sharing the same business identifier) deliberately do not resolve, so a duplicate identifier can never silently authorize. The set of rules and identities that grant access is unchanged — only the resolution of which Patient a reference points to has been extended.

Bug Fixes​

Role inheritance dropping parent roles on child organizations​

When role inheritance was enabled, parent roles were silently dropped whenever a child organization already had a direct role of its own. An elevated role declared at the root (e.g. ICT) disappeared as soon as a different role (e.g. Nurse) existed anywhere below it, and the inherited role was unavailable on every descendant beyond that point.

The fix correctly accumulates parent and direct roles together at each descendant within the configured depth, so the union of all inherited and directly-assigned roles is now visible to the authorization layer.

HFQL rejected with 403 Forbidden whenever no explicit search/read rule matched​

HFQL authorization required at least one explicit search or read rule to be configured for the calling client role. In deployments where access is controlled purely via default-validator (no explicit rules), or for unauthenticated requests, every $hfql-execute query was rejected with 403 Forbidden regardless of what the default validator would have decided.

In 1.8.0 the configured default validator is honoured for HFQL just as it is for ordinary searches. When no explicit rule matches the queried resource type:

  • Allowed — the query returns the data its FROM clause selects.
  • Forbidden — the query succeeds with zero rows rather than being rejected.
  • Other validators (e.g. LegitimateInterest) — the matching explicit rules determine which rows the client sees, with the same compartment narrowing applied as for normal searches.

Unauthenticated requests and requests from clients without explicit rules now return HTTP 200 with an empty result under a restrictive default validator, return data under a permissive default validator, and return the narrowed subset the client is authorized for when explicit rules are in place.

Dependency Upgrades​

1.8.0 includes a broad maintenance pass across the server, administration UI, and tooling.