Zum Inhalt

Produktbeschreibung

Die FHIR Service Facade ist ein dezentrales Access-Control-Gateway bzw. API-Gateway des AGW, das mittels Interceptor Pattern Anfragen abfängt, prüft und weiterleitet. Das Service unterstützt alle aktuellen FHIR Anfragen (R4 & R5) und bedient sich rollenbezogenen FHIR CapabilityStatement Ressourcen, um Berechtigungen durchzusetzen bzw. den vollen FHIR Funktionsumfang einzuschränken.

Technologischer Ansatz

Alle pIT-Services sind JAVA Applikationen, die auf einen Microservice Ansatz setzen und als Kubernetes-ready Container gestaltet sind. Eigenschaften des Services sind:

  • Docker Container, deren Artefakte über GitHub dem Betreiber bereitgestellt werden.
  • Der Betreiber baut die Container in seiner lokalen Umgebung. Spezifika des Betreibers können, wenn notwendig, in dessen lokaler Umgebung angepasst werden.
  • Ressourcen werden schonend gestaltet.
  • Reduzierte Abhängigkeiten zu Software Libraries - es wird kein Applikation Server verwendet.
  • Als HTTP Empfänger dient ein Netty Server.
  • Startet schnell (es kann ein K8s autoscaler verwendet werden).
  • Liefert strukturierte Logmetadaten (logback) via server log oder console, um ein zentrales Monitoring zu ermöglichen.
  • Es wird ein Prometheus /metric Endpunkt bereitgestellt (eigener Port/Server).
  • Konfiguration für den Betreiber mittels yaml Files (Konfiguration und Secrets in getrennten yaml Files).
  • Der Container kann mehfach mit unterschiedlicher Konfiguration gestartet werden.
  • Vor dem Weiterleiten von Nachrichten wird ein OAuth Token-Exchange mit dem EOAS durchgeführt.
  • Ein FHIR Interceptor auf Basis von rollenbezogenen FHIR CapabilityStatement Ressourcen prüft die Anfrage.
---
title: Technologischer Ansatz
config:
  theme: neutral 
---
%%{init: 
  {
    'themeVariables': {
      'lineColor': 'lightgray'
    }
  } 
}%%
architecture-beta
    group pod(cloud)[FHIR Facade JAVA microservice]
    service netty(internet)[netty http receiver] in pod
    service fhir(server)[FHIR interceptor] in pod
    service cfg(disk)[yaml cfg] in pod
    service log(disk)[logback logging] in pod
    service eoas(internet)[token exchange with EOAS] in pod
    service forward(internet)[forward message] in pod

cfg:R -- L:netty
netty:B -- T:fhir
fhir:L -- R:log
fhir:R -- L:eoas
fhir:B -- T:forward

Standards

Standard Inhalt
RFC6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage
FHIR Fast Healthcare Interoperability Resources

Arbeitsweise

Die FHIR Service Facade wird als dezentrale BeS Komponente im AGW bereitgestellt.

Externe Verbindungen werden über das jeweils "lokale" AGW an den Apache des AGW gesendet. Innerhalb des K8s (Kubernetes) Clusters des AGW wird die FHIR Service Facade über den integrierten Netty HTTP Server angesprochen.

Die FHIR Service Facade

  • empfängt FHIR Transaktionen mit einem EOAS Access-Token,
  • kommuniziert mit dem zentralen EOAS für:
  • JWKS Abruf für die Tokenprüfung,
  • OAuth Token-Exchange von Access-Token auf Community-Token,
  • setzt Berechtigungen auf Basis von rollenbezogenen FHIR CapabilityStatement Ressourcen durch (Interceptor),
  • leitet Nachrichten an die eigentliche FHIR Zieldestination weiter,
  • protokolliert im L-ARR.
  • Loginformation wird mittels strukturierter JSON Logs an den Splunk weitergeleitet.
---
title: Arbeitsweise
config:
  theme: neutral 
---
%%{init: 
  {
    'themeVariables': {
      'lineColor': 'lightgray'
    }
  } 
}%%
block-beta
columns 1
  apache(("AGW\n Apache "))
  arrow<["&nbsp;&nbsp;"]>(down)

  block:eoas_netty
    netty["<b>FHIR-SF</b> Netty HTTP receiver"]
  end



  block:FSF
    logic["<b>FHIR-SF</b> API-GW und Interceptor"]
  end

  netty --> logic

  space
  space
  block:bes
    eoas["EOAS"]
    acs["Interceptor"]
    fw["Forward Msg."]      
    larr["L-ARR"]
    splunk["SplunkLogs"]  
  end

  logic --> eoas
  logic --> acs
  logic --> larr
  logic --> splunk
  logic --> fw


  style netty fill:#AED6F1,stroke:#blue,stroke-width:2px
  style logic fill:#AED6F1,stroke:#blue,stroke-width:2px
  style eoas fill:#F9F9CA,stroke:#blue,stroke-width:2px  
  style acs fill:#AED6F1,stroke:#blue,stroke-width:2px    
  style fw fill:#AED6F1,stroke:#blue,stroke-width:2px

Interaktionen

Benutzer führt FHIR Transaktionen durch

Damit ein Benutzer FHIR Transaktionen gegen die FHIR Service Facade durchführen kann, muss er davor ein Access-Token für die jeweilige eHealth Anwendung vom EOAS beantragen - siehe auch: AC-Access-Token beantragen.

Mit einem EOAS Access-Token kann der Benutzer nun Anfragen gegen die FHIR Service Facade durchführen.

Die jeweils unterstützten und zu verwendenden FHIR Interaktionen sind abhängig von der jeweiligen eHealth Applikation bzw. von den hinterlegten CapabilityStatement Ressourcen.

Die FHIR Service Facade kontaktiert den EOAS/JWKS Endpunkt, um kryptographische Information zum Validieren des Access-Tokens zu erhalten (TrustStore/TrustJWK). Der Abgleich der JWKS wird zwischengespeichert und zeitgesteuert (3600 Sekunden) erneuert.

Dem Access-Token wird die eHealth Applikation und die Rolle des Anfragenden entnommen (JWT/Scope mit Präfix), für die die FHIR Facade nachfolgend eine CapabilityStatement Ressource ladet. Siehe auch: eHealth-App und rollenbezogene FHIR CapabilityStatement Ressource

Die Service Facade verwendet nun das geladene CapabilityStatement, um die Berechtigungen für die jeweilige eHealth-App und den Benutzer/Rolle durchzusetzen. Siehe auch: Durchsetzen von Berechtigungen

Anschließend führt die Service Facade einen Token-Exchange mit dem EOAS durch und tauscht den Access-Token gegen ein Community-Token aus. Das Community-Token wird später an die jeweilige eHealth Fachanwendung weitergeleitet. Siehe auch:

  • AC-Community-Token
  • AC-Community-Token beantragen

Das Community-Token wird von der Service Facade ebenfalls im Memory für den Zeitraum dessen Gültigkeit zwischengespeichert.

Abschließend protokolliert die Service Facade im L-ARR einen ATNA AuditEvent und stellt in der Console strukturierte Loginformation in Form eines JSON zur Verfügung. 

---
title: Benutzer führt FHIR Transaktionen durch
config:
  theme: neutral 
---
sequenceDiagram
autonumber

actor benutzer as Benutzer

box rgb(252, 243, 207) AGW
participant apache as Apache AGW
end

box rgb(174, 214, 241) Facade
participant facade as FHIR Facade
end

box rgb(252, 243, 207) central BeS
participant eoas as EOAS
end

box white Destination
participant dst as Fachlogik
participant larr as L-ARR
end

benutzer->>+facade: FHIR Interaction<br>(Access-Token)
facade<<-->>+eoas: get-JWKS
facade-->+facade: validate JWT
facade-->+facade: check app
facade-->+facade: enforce CapStmt
facade<<-->>+eoas: exchange-Token<br>(AC-Access-Token)
facade->>+dst: forward message(Community-Token)
facade->>+larr: write L-ARR Audit

facade-->>+benutzer: return FHIR Response
  • 1: Der Benutzer sendet eine FHIR Anfrage mit Access-Token.
  • 2: Wenn der JWKS nicht verfügbar bzw. der cache abgelaufen ist, wird der JWKS Endpunkt abgefragt.
  • 3: Das JWT wird validiert: Signatur, exp Claim, Facade als Audience (aud).
  • 4: Es wird geprüft, ob die eHealth Applikation der der FHIR Facade entspricht.
  • 5: Das ermittelte CapabilityStatement für die jeweilige Rolle wird durchgesetzt.
  • 6: Das Access-Token wird gegen ein Community-Token getauscht. Das Community-Token wird für die Zeit dessen Gültigkeit im Memory zwischengespeichert (default 5 Minuten).
  • 7: Die empfangene FHIR Nachricht wird an den eigentlichen Empfänger weitergeleitet.
  • 8: Es wird ein L-ARR Audit geschrieben.
  • 9: Die Antwort der weitergeleiteten Nachricht wird an den Benutzer zurückgegeben.

eHealth-App und rollenbezogene FHIR CapabilityStatement Ressource

Die Service Facade entnimmt dem Access-Token die eHealth Applikation und die Rolle. Diese Information ist mit den folgenden Präfixe im Scope Claim vorhanden:

  • cs:702 (Rolle)
  • der Präfix cs: steht für CapabilityStatement
  • nach dem :folgt die Rolle, die gleichzeitig die id der CapabilityStatement Ressource ist
  • app:10x (eHealth App)
  • der Präfix app: gibt die eHealth Applikation an. CodeSystem ELGA_e-Health_Anwendungen
  • nach dem :folgt die eHealth Applikation

Es wird geprüft, ob die aus dem Access-Token ermittelte eHealth Applikation der Konfiguration der Service Facade entspricht.

Die id (Rolle) des ermittelten rollenbezogenen FHIR CapabilityStatement dient als File name um das CapabilityStatement vom Filesystem zu laden.

Mittels der geladenen CapabilityStatement Ressource können gezielt Funktionen/Berechtigungen erlaubt/vergeben oder verboten werden. Siehe nächstes Kapitel: Durchsetzen von Berechtigungen

Durchsetzen von Berechtigungen

Die für das Access-Token (Benutzer) geladene CapabilityStatement Ressource wird verwendet, um Berechtigungen auf API Ebene zu prüfen.

Eine Prüfung von zurückgelieferten Inhalten (Antwort) ist nicht vorgesehen.

Die Berechtigungen, die in den nachfolgenden Kapitel beschrieben werden, können mit diesem Ansatz durchgesetzt werden.

Systemweite FHIR Operations, Interactions und Suchparameter

Es können nicht Ressource Type bezogene FHIR Operations, Interactions und Suchparameter erlaubt oder verboten werden. Es handelt sich hierbei um Einträge des CapabilityStatement, die nicht für einen bestimmten Ressource Typ verwaltet werden. Beispiele sind:

  • Systemweite Interaktionen in CapStmt/rest/interaction:
  • capabilities
  • transaction
  • batch
  • search-system
  • history-system
  • …
  • Systemweite Suchparameter in CapStmt/rest/searchParam :
  • _content
  • _id
  • _tag
  • …
  • Systemweite Operationen in CapStmt/rest/operation :
  • meta
  • convert
  • versions
  • …

Erlaubte FHIR Ressource Typen

Mit den Einträgen in CapStmt/rest/resource kann gesteuert werden, welche FHIR Ressource Typen für die jeweilige Rolle grundsätzlich verfügbar sind.

Bei schreibenden und lesenden Zugriffen, die direkt einen Ressource Typ verwenden, wird von der FHIR Service Facade ein Fehler zurückgeliefert. Als Beispiel:

  • Wenn die FHIR ValueSet Ressource nicht erlaubt ist und eine schreibende oder lesende Transaktionen /ValueSet verwendet wird, wird ein Fehler zurückgegeben.

Ressource Type spezifische Berechtigungen

Es können Ressource Typ spezifische FHIR Operations, Interactions und Suchparameter erlaubt oder verboten werden.

Beispiele sind:

  • Ressource Typ spezifische Interaktionen in CapStmt/rest/resource[*]/interaction:
  • read
  • vread
  • update
  • delete
  • …
  • Ressource Typ spezifische Suchparameter in CapStmt/rest/resource[*]/searchParam:
  • date
  • subject
  • part-of …
  • Ressource Typ spezifische Operationen in CapStmt/rest/resource[*]/operation:
  • match
  • validate
  • meta
  • …

Weiterleiten der Anfrage an die Fachanwendung

Nach erfolgreicher Prüfung leitet die FHIR Service Facade die empfangene Nachricht inklusive Community-Token an die eHealth Fachanwendung bzw. einem Gateway/MappingService/etc. weiter.

Die Service Facade bietet dafür API Gateway Funktionalität, um den jeweiligen Endpunkt und TLS Spezifika konfigurieren zu können.