Lösungsarchitektur

Inhalt

Logische Architektur
Basisdienste
Videokonferenzdienste
Einwilligungsdienste

Technische Architektur
Prämissen
Überblick
TSL-Abrufpunkt und OCSP-Responder
Reverse Proxy
Identity Provider
Terminologie Server
FHIR Server
Signalling Server
STUN/TURN Server

Spezifikationsdetails
eGK-basierte Registrierung / Authentisierung
Signalisierung (sichere Aushandlung der Video-/Audiokonferenzparameter)

Logische Architektur

Die folgenden Abschnitte beschreiben die logische Architektur des Gesamtsystems. Die logische Architektur betrachtet ausschließlich funktionale Aspekte und Anforderungen, die durch verschiedene Dienste bzw. durch die von diesen Diensten angebotene Funktionalität adressiert bzw. umgesetzt werden müssen.

Basisdienste

Die im Projekt für die prototypische Umsetzung vorgesehenen Szenarien „Elektronische Einwilligung“ und „Videokonsultation“ weisen bezüglich der benötigten Funktionalität eine Reihe von Gemeinsamkeiten auf. Der folgende Abschnitt beschreibt Dienste, die diese gemeinsame Funktionalität umsetzen. Im Rahmen der weiteren Ausführungen werden diese Dienste auch als Basisdienste bezeichnet, da davon ausgegangen werden kann, dass sie für die Umsetzung beliebiger Szenarien benötigt werden und somit die grundsätzliche Basis eines jeden Systems bilden.

Logische Architektur - Basisdienste

Verzeichnisdienste

In beiden Szenarien finden sich Anwendungsfälle, die das Auffinden von teilnehmenden Akteuren oder Dienstangeboten erforderlich machen. Aus logischer Sicht erfüllt ein Verzeichnisdienst die Aufgabe, entsprechende Objekte suchen und Details zu diesen abrufen zu können. Verschiedene Arten von Verzeichnissen werden im Kontext des Projektes benötigt:

Dienst-/Angebotsverzeichnis: Das Videokonsultationsszenario sieht vor, dass eine Nutzerin nach verschiedenen Videokonsultationsangeboten suchen und zu diesen Angeboten detaillierte Informationen abrufen kann. Das Verzeichnis muss dabei verschiedene Suchparameter unterstützten.
Patientenverzeichnis: In beiden Szenarien spielt ein Patientenverzeichnis eine entscheidende Rolle. Informationen zur Patientin werden sowohl im Zusammenhang der Authentisierung benötigt als auch in den primär fachlich getriebenen Anwendungsfällen (z. B. Zuordnung einer Patientin zu einem gebuchten Termin).
Leistungserbringerverzeichnis: Eine ähnliche Rolle wie das Patientenverzeichnis spielt das Leistungserbringerverzeichnis. Aus fachlicher Sicht muss es beispielsweise im Rahmen der Erstellung einer Einwilligungsvorlage möglich sein, den beratenden und ggf. auch behandelnden Arzt in einem Verzeichnis zu suchen und relevante Informationen in die Einwilligungsvorlage zu übernehmen. Ein entsprechendes Verzeichnis könnte auch im Zusammenhang mit der Authentisierung von Leistungserbringern eine entscheidende Rolle spielen, wenngleich dieser Anwendungsfall explizit außerhalb des Projektscopes liegt.

Sicherheitsdienste

Eine weitere Gruppe von Basisdiensten bilden die Sicherheitsdienste, die die Grundlage für einen sicheren und datenschutzfreundlichen Betrieb der Gesamtlösung bilden. Sicherheitsdienste müssen dabei insbesondere die folgende Funktionalität abbilden:

Zeitsynchronisation: Die genaue Zeit spielt bei einer Vielzahl von Systemfunktionen eine entscheidende Rolle, angefangen bei der Validierung von Sicherheitsobjekten bezüglich ihrer (zeitlichen) Gültigkeit bis hin zum Schreiben von nachvollziehbaren Audit-Logs (Wann ist ein bestimmtes Ereignis aufgetreten?). Daher muss sichergestellt werden, dass alle Komponenten des Systems eine einheitliche Uhrzeit nutzen.
Authentifizierung: Die Authentifizierung von Leistungserbringern und Versicherten spielt eine entscheidende Rolle bei der Sicherheit des Gesamtsystems. Nur Nutzerinnen, die ihre Identität nicht nur behaupten, sondern zweifelsfrei nachweisen können, sollen in die Lage versetzt werden, Zugang zu den entsprechenden Dienstangeboten zu erhalten.
Autorisierung: Aufbauend auf der Authentifizierung muss Funktionalität bereitgestellt werden, die es ermöglicht, den Zugriff von Leistungserbringern und Versicherten auf ausgewählte Dienste und deren Ressourcen feingranular zu steuern.
PKI-Dienste: Eng verbunden mit der Nutzung der elektronischen Gesundheitskarte als Authentisierungsmittel ist die Nutzung von PKI-Diensten zur Prüfung der Gültigkeit der auf der Karte gespeicherten X.509-Zertifikate. Ohne Dienstangebote wie beispielsweise OCSP-Responder kann es nicht gelingen die Validität entsprechender Zertifikate zweifelsfrei zu bestätigen.
Nichtabstreitbarkeit: Nichtabstreitbarkeit spielt in vielen eHealth-Szenarien eine entscheidende Rolle. Auf Basis der Audit-Logs des Systems muss sich möglichst zweifelsfrei nachprüfen lassen, welche Aktionen im System, auf welchen Objekten, durch wen und zu welcher Zeit durchgeführt wurden.
Sicherer Transport: Bereits anhand der Anwendungsfälle ist deutlich geworden, dass das System aus verschiedenen Komponenten bestehen wird, die sowohl im Frontend- als auch im Backend-Bereich angesiedelt sein werden. Es muss sichergestellt werden, dass der Transport von Informationen zwischen diesen Komponenten grundsätzlich gesichert erfolgt.

Ontologiedienst

Um eine einfache Verarbeitbarkeit zu gewährleisten, müssen die im Projekt verwendeten medizinischen und administrativen Informationen möglichst in strukturierter und kodierter Form vorliegen. Die Semantik über diesen Informationen wird mit Hilfe von Ontologien definiert und bereitgestellt. In der einfachsten Form bildet eine Ontologie ein einfaches Codesystem ab, das die Bedeutung von definierte Codes festlegt. Beispiele hierfür sind standardisierte Codes für Termintypen, Dokumenttypen oder auch Inhaltstypen von Dokumentabschnitten. Insbesondere im Zusammenhang mit der „Elektronischen Einwilligung“ spielt der Ontologiedienst für die Abbildung von Einwilligungspaketen und Einwilligungserklärungen eine wichtige Rolle.

Videokonferenzdienste

Neben den Basisdiensten werden zur Umsetzung der beschriebenen Anwendungsfälle im Videokonsultationsszenario weitere fachspezifische Dienste benötigt. Die folgenden Abschnitte geben einen kurzen Überblick über diese logischen Dienste bzw. die durch diese realisierte Funktionalität.

Logische Architektur - Videokonferenz

Terminmanagementdienst

Anders als im privaten Umfeld sind in den heute vorherrschenden Versorgungsstrukturen (klassisches Haus-/Facharztmodell) Szenarien, in denen ein Patient einen Leistungserbringer ad hoc kontaktiert, kaum denkbar. Daher wird eine wesentliche Voraussetzung für die Umsetzung von Videokonsultationsleistungen die Bereitstellung einer Terminmanagementfunktionalität sein. Leistungserbringer müssen einerseits in die Lage versetzt werden, Terminslots zu definieren, in denen sie grundsätzlich Videokonsultationsleistungen anbieten, Patienten müssen andererseits freie Termine buchen können, die mit der persönlichen Zeitplanung kompatibel sind. Neben der Planung und Buchung müssen grundsätzlich auch alle anderen Schritte im Lebenszyklus eines Termins abgebildet werden können. Dazu gehört u.a. das Stornieren aber auch das Dokumentieren von Terminen.

Signalisierungsdienst

Zur Aushandlung von Verbindungsparametern zwischen den Teilnehmern einer Videokonsultation wird ein Signalisierungsdienst benötigt, der von den jeweiligen Akteuren direkt erreicht werden kann und die Verteilung der entsprechenden Informationen realisiert. Zu relevanten Verbindungsparametern gehören beispielsweise:

die Endpunktadressen über die sich die Kommunikationspartner später erreichen können,
die zu verwendenden Codecs für die Kodierung der Audio- und Videosignale,
Informationen zum aktuellen Verbindungsstatus oder auch
die zum Schutz der Verbindung zu nutzenden Sicherheitsmerkmale bzw. von diesen Merkmalen abgeleitete Informationen.

Ohne die Aushandlung entsprechender Parameter ist der Aufbau einer Verbindung zwischen den Teilnehmern grundsätzlich nicht möglich.

Ende-Zu-Ende Kommunikationsdienst

Unter Umständen ist es nicht möglich, dass zwei Kommunikationspartner eine direkte Verbindung zwischen den jeweiligen Endgeräten aufbauen können. Dies ist z.B. dann der Fall, wenn die Endgeräte der Partner durch eine speziell konfigurierte Firewall geschützt werden. Für diesen Fall ist es erforderlich die Kommunikation durch einen speziellen Dienst übermitteln bzw. weiterleiten zu lassen, den beide Partner direkt erreichen können.

Einwilligungsdienste

Für die Abbildung des Szenarios der „elektronischen Einwilligung“ werden ebenfalls Dienste mit einer spezifischen auf die jeweiligen Anwendungsfälle zugeschnittenen Lösung benötigt. Der folgende Abschnitt beschreibt diese logischen Dienste bzw. die hinter diesen Diensten stehende Funktionalität.

Logische Architektur - Einwilligungsdienste

Dokumentenverwaltungsdienst

Die Abbildung einer „elektronischen Einwilligung“ macht die Verwaltung verschiedener Artefakte erforderlich, die zur Umsetzung des Gesamtprozesses erforderlich sind. Dazu gehören u.a.:

Aufklärungsinformationen wie z.B. detaillierte Aufklärungsbögen oder Merkblätter
Einwilligungsvorlagen sowie
vollständige Einwilligungserklärungen

Diese Artefakte, die häufig einen klaren Dokumentencharakter aufweisen, müssen für einen definierten Zeitraum sicher vorgehalten und verwaltet werden.

Workflowdienst

Das Szenario der „Einwilligung in die Behandlung“ setzt sich aus verschiedenen Prozessschritten zusammen, die zum Teil aufeinander aufbauen. Um diese Schritte und die Reihenfolge, in der sie ausgeführt werden müssen in IT-Systemen abbilden zu können, bedarf es unter Umständen eines Workflowdienstes.

Technische Architektur

Die nachfolgenden Abschnitte beschreiben die technische Architektur des Systems. Diese bildet die Dienste und Funktionalität der logischen Architektur auf konkrete technische Dienste und zu verwendende Standards ab.

Prämissen

Der technischen Architektur sowie der prototypischen Realisierung liegen verschiedene Prämissen zugrunde, die im Folgenden kurz dargestellt werden:

Nutzung von Standards - Die zu entwickelnde Lösung soll zur Realisierung der benötigten Funktionalität so weit wie möglich auf etablierte Standards aus dem Sicherheits- und E-Health-Umfeld zurückgreifen. Sofern eine Auswahl zwischen zwei funktional vergleichbaren Standards besteht, soll der Standard gewählt werden, der sich leichter in mobile Anwendungen integrieren lässt.
Nutzung von Open-Source-basierten Softwarelösungen/Bibliotheken - Wo immer möglich soll auf Softwarelösungen und -bibliotheken zurückgegriffen werden, die quelloffen zur Verfügung stehen. Sofern eine Auswahl zwischen zwei funktional vergleichbaren Lösungen/Komponenten besteht, soll die Lösung/Komponente genutzt werden, deren Lizenz eine komerzielle Nachnutzung ermöglicht.

Aus diesen Prämissen ergeben sich Grundsatzentscheidungen, die in die technische Architektur eingeflossen sind und sich somit in den nachfolgenden Darstellungen widerspiegeln:

Verwenden von OpenID Connect - Die Basis für die Umsetzung von Authentifizierungsworkflows bildet OpenID Connect. Alternative Standards wie SAML 2.0 bieten aus funktionaler Sicht zwar einen vergelichbaren Leistungsumfang, lassen sich jedoch aufgrund ihrer XML-Lastigkeit schwerer durch mobile Anwendungen verarbeiten.
Verwenden von FHIR - Der FHIR-Standard vereinfacht aufgrund seiner konsequenten Ausrichtung auf REST-basierte Calls die Nutzung im mobilen Umfeld. Alternativ nutzbare Standards bzw. Profile der IHE-ITI-Familie (z.B. IHE XDS) sind hier wegen ihrer XML-Lastigkeit nur mit unverhältnismäßig hohem Aufwand auf mobilen Endgeräten einsetzbar.
Verwenden von WebRTC - WebRTC hat sich in den zurückliegenden Jahren zum Quasi-Standard im Umfeld der mobilen Echtzeitkommunikation entwickelt und soll insbesondere aufgrund seiner Plattform-übergreifenden Verfügbarkeit von Bibliotheken eingesetzt werden.

Überblick

Die Abbildung der logischen auf die technische Architektur stellt sich wie folgt dar:

Technische Architektur - Überblick

Wie der Abbildung zu entnehmen ist, verteilt sich die Funktionalität auf verschiedene Dienste bzw. Komponenten. Nicht jeder logischer Dienst ist dabei genau einer technischen Komponenten zugewiesen. Die folgenden Abschnitte beschreiben die Abbildung bezogen auf die einzelnen Komponenten im Details.

TSL-Abrufpunkt und OCSP-Responder

Die Verwendung von X.509-Zertifikaten spielt auf verschiedenen Ebenen der Lösungsarchitektur eine besondere Rolle. Entsprechende Zertifikate kommen beispielsweise beim sicheren Datentransport über TLS (vgl. Reverse Proxy) zum Einsatz oder im Rahmen der Authentifizierung der Versicherten durch den Identity Provider (vgl. Identity Provider). Für beide Szenarien ist es unerlässlich die Validität der jeweils genutzten Zertifikate zu prüfen.

Authentifizierung des Versicherten: Sämtliche Certification Authorities (CA), die für die Ausstellung der Authentifizierungszertifikate der elektronischen Gesundheitskarten genutzt werden, sind in der Trusted Service List (TSL) der gematik aufgeführt. Die im Rahmen der Authentifizierung der Versicherten notwendige Prüfung der entsprechenden Zertifikatsketten macht die korrekte Verarbeitung dieser Trusted Service List erforderlich. Die TSL kann über den definierten Abrufpunkt https://download.tsl.ti-dienste.de/TSL.xml bezogen werden. Detaillierte Vorgaben bezüglich der erforderlichen Validierungsschritte für TSL und Zertifikate werden in [gemSpec_PKI] erörtet. Die Validierung schließt u.a. auch die Online-Prüfung der Zertifikate über OCSP (Online Certificate Status Protocol) mit ein. Die Adressen der OCSP-Responder sind Bestandteil des Diensteintrags der TSL und zusätzlich im Zertifikat selbst enthalten.
Sicher Datentransport über TLS: Die Endpunkte für die genutzten Dienste werden über das öffentliche Internet erreichbar sein. Wo und wann immer möglich, soll TLS (Transport Layer Security) zum Schutz der mit diesen Diensten ausgetauschten Daten genutzt werden. Das TLS-Protokoll setzt in einer üblichen Konfiguration zumindest das Vorhandensein eines Serverzertifikats voraus. Dieses muss durch den Client validiert werden. In diesem Zusammenhang greifen vergleichbare Mechanismen wie bei der Validierung des Authentisierungszertifikates (z.B. Einbinden eines OCSP-Responders). Einzig die Verwendung einer Trusted Service List ist nicht erforderlich bzw. wird nicht von Hause aus unterstützt.

TSL-Abrufpunkt und OCSP-Responder sind keine Kernbestandteile der Lösungsarchitektur. Sie existieren bereits in produktiver Form und werden lediglich durch die verschiedenen Komponenten der Lösung (Identity Provider, Client etc.) nachgenutzt. Aus diesem Grund wird in den folgenden Ausführungen nicht weiter auf die detaillierte Ausgestaltung der entsprechenden Dienste eingegangen. Es wird lediglich auf deren Nutzung verwiesen.

Reverse Proxy

Der Reverse Proxy leitet Anfragen von beliebigen Clients an die jeweiligen Dienste im Backend weiter. In diesem Zusammenhang kann er eine Reihe von weiteren Aufgaben übernehmen:

Zentrale Terminierung von TLS-Verbindungen: Die TLS-Verbindung mit dem Client wird bereits am Reverse Proxy terminiert. Dies ermöglicht den Einsatz speziell gehärteter und auf Performance zugeschnittener Lösungen. Eine Härtung des TLS-Stacks der geschützten Dienste ist dann nur noch in geringerem Umfang erforderlich.
Load Balancing: Sofern erforderlich kann der Reverese Proxy auch in der Rolle eines Load Balancers agieren und Anfragen gleichmäßig über verschiedene Dienstinstanzen hinweg verteilen.
Fallback: Sofern erforderlich kann der Reverse Proxy ausgefallene oder gestörte Dienstinstanzen erkennen und den Datenverkehr auf Backup-Systeme umleiten.
URL-Rewriting: Sofern erforderlich kann der Reverse Proxy angefragte URLs umschreiben und somit z.B. an die Anforderung der maskierten Backenddienste anpassen.
Sicherheit: Speziell erweiterte Varianten eines Reverse Proxies können als Web Application Firewall (WAF) fungieren und den eingehenden und ausgehenden Datenverkehr bezüglich bestimmter Angriffe analysieren. Andere Erweiterungen erlauben die enge Verzahnung mit Identity Providern, um Clients/Nutzer zu authentifizieren und ggf. auch zu autorisieren.

Technische Architektur - Reverse Proxy

Schnittstellen

Im Kontext des Projektes terminiert der Reverse Proxy die TLS-Verbindungen für folgende Dienste:

Identity-Provider: Ausschließlich https-Traffic, der für die Realisierung der Authentifizierungsfunktionalität und für die Unterstützung des OpenId Connect Protokolls benötigt wird, ist zulässig. Ein Zugriff auf die Administrationsschnittstellen des Idenitty Providers ist über den Reverse Proxy hingegen nicht möglich. Die Steuerung der Weiterleitung erfolgt erfolgt auf Basis der URL des Aufrufs. (1)
Terminologie Server: Der Reverse-Proxy leitet ausschließlich https-Traffic weiter, der für den lesenden Zugriff auf den Terminologie Server erforderlich sind. Requests/Operationen für schreibende Zugriffe (Erstellen Löschen, Ändern etc.) sind nicht möglich. Die Steuerung der Weiterleitung erfolgt erfolgt auf Basis der URL des Aufrufs. (2)
Signalling Server: Primäre Aufgabe des Reverse Proxy ist die Terminierung der TLS-Verbindungen vom Client. Der TCP-Datenstrom wird ohne weitere Veränderungen an den Signalling Server durchgereicht.(3)
FHIR Server: Der gesamte Datenverkehr wird zum FHIR-Sever durchgereicht. Der Reverse Proxy terminiert lediglich die TLS-Verbindungen vom Client. Die Steuerung der Weiterleitung erfolgt erfolgt auf Basis der URL des Aufrufs. (4)

Sofern der Reverse Proxy OCSP-Stapling unterstützt, kann eine zusätzliche Kommunikation mit den für die Serverzertifikate zuständigen OCSP-Respondern stattfinden. (5)

Anforderungen

Folgende Anforderungen müssen durch die Implementierung des Reverse Proxy umgesetzt werden:

Sämtliche Datenverbindungen vom Client zum Reverse Proxy MÜSSEN über eine einseitig authentisierte TLS-Verbindung abgesichert werden.
Die Vorgaben aus [BSI TR-02102-2] MÜSSEN berücksichtigt werden.

Prototypische Realisierung

Die prototypische Realisierung nutzt nginx als Reverse Proxy. Detaillierte Informationen zur Ausgestaltung/Konfigurationen können der Realisierungsdokumentation entnommen werden.

Identity Provider

Die primäre Aufgabe des Identity Providers liegt im Bereich der Bereitstellung von Sicherheitstoken und Identitätsinformationen für angebundene Fachdienste. Um diese Aufgaben realisieren zu können, muss der Identity Provider verschiedene Funktionen erfüllen:

Abbilden eines Leistungserbringerverzeichnisses: Leistungserbringer (z.B. Ärzte) sind wesentliche Akteure in den für die Umsetzung vorgesehenen Anwendungsfällen. Um auch ihnen den Zugang zu den benötigten Diensten und den Zugriff auf die von diesen Diensten vorgehaltenen Informationen und Funktionen zu ermöglichen, muss der Identity Provider für diese Nutzergruppe die Verwaltung der jeweiligen Identitätsattribute (z.B. Rollen) organisieren. Ohne eine entsprechende Funktionalität sind insbesondere Authentifizierung und Autorisierung kaum zu realisieren.
Abbilden eines Patientenverzeichnisses: Neben den Leistungserbringern müssen auch die Patienten bzw. deren Identitätsattribute und Credentials durch den Identity Provider verwaltet werden. Auch für diese Akteursgruppe gilt, dass die benötigte Authentifizierungs- und Autorisierungsfunktionalität sonst kaum realisiert werden kann.
Authentifizierung von Nutzern: Zentrale Aufgabe des Identity Providers ist die Authentifizierung von Nutzern. Im beschriebenen Anwendungsszenario bedeutet Authentfizierung speziell die verlässliche Überprüfung und Bestätigung der behaupteten Identität eines Nutzers. Die Überprüfung erfolgt dabei anhand von Credentials (Anwendung von Schlüsseln, Secrets etc.), die dem Nutzer zugeordnet sind. Die Bestätigung wird über die Ausstellung spezieller Authentifizierungsnachweise abgebildet.
Autorisierung von Nutzern: Neben der Authentifizierung kommt dem Identity Provider ebenfalls die Aufgabe zu, Nutzer für den Zugriff auf spezielle Ressourcen zu autorisieren. Auch in diesem Zusammenhang kommen spezielle Nachweise zum Einsatz, die geeignet sind, den Zugriff anhand der bereitgestellten Informationen zu steuern.

Hinweis: Für ein leichteres Verständnis der folgenden Abschnitte bietet sich eine - zumindest grundlegende - Auseinandersetzung mit OpenID Connect an. Ein guter Ausgangspunkt ist die offizielle Webseite der OpenID Foundation: https://openid.net/connect/

Technische Architektur - Identity Provider

Schnittstellen

Der Identity Provider besitzt Schnittstellen zu den folgenden Diensten:

Client: Beim Client handelt es sich bezogen auf die Anwendungsfälle um die mobilen Endgeräte der Nutzer. Diese kontaktieren (vermittelt durch den Reverse Proxy) den Identity Provider, um den entsprechenden Nutzer zu authentisieren und Authentifizierungs- bzw Autorisierungsnachweise abzurufen. (1)
OCSP Responder: Der OCSP Responder kommt insbesondere im Rahmen der Überprüfung von Versichertenzertifikaten (primär eGK.AUT) zum Einsatz. Über die durch den Responder bereitgestellte Funktionalität kann online geprüft werden, ob ein bestimmtes Zertifikat noch gültig ist oder bereits gesperrt wurde. (2)
TSL Abrufpunkt: Der TSL Abrufpunkt spielt ebenfalls bezogen auf die Überprüfung der X.509-Zertifikate eine entscheidende Rolle. In der TSL finden sich alle relevanten Informationen, die für die Überprüfung der Versichertenzertifikate benötigt werden. Dazu gehören u.a. auch die Endpunktadressen der benötigten OCSP Responder. (3)
Signalling Server: Im Rahmen der Authentifizierung der Clients muss der Signalling Server in die Lage versetzt werden, die für die Authentifizierung genutzten Credentials (OIDC-Token) zu validieren und zusätzliche Nutzerinformationen abzurufen. Dazu benötigt er Zugriff auf ausgewählte Endpunkte des Identity Provider (keysource, userinfo). (4)
FHIR-Server: Im Rahmen der Authentifizierung der Clients muss der FHIR Server in die Lage versetzt werden, die für die Authentifizierung genutzten Credentials (OIDC-Token) zu validieren und zusätzliche Nutzerinformationen abzurufen. Dazu benötigt er Zugriff auf ausgewählte Endpunkte des Identity Provider (keysource, userinfo). (5)

OpenID Connect als Authentifizierungsprotokoll

OpenID Connect (OIDC) basiert auf dem Autorisierungsprotokoll OAuth 2.0 und dient als zusätzliche Schicht zur Abbildung von Authentifizierungsfunktionalität. Den das Protokoll nutzenden Clients wird es ermöglicht, die Identität von Nutzern verlässlich zu überprüfen und relevante Identitätsattribute abzufragen. Genau diese Funktionalität ist für die Absicherung der realisierten Dienste (Signalling, FHIR) zwingend erforderlich. OIDC und OAuth nutzen sogenannte Token (identity, access + refresh token), um Authentifizierungs- und Autorisierungsinformationen zu transportieren. OIDC bildet die Basis für die Umsetzung des Projektes. Konkret wird der OIDC Authorization Code Flow mit PKCE (Proof Key for Code Exchange) verwendet.

Hinweis: Eine Alternative zu OpenID Connect bildet SAML 2.0. Aufgrund der leichteren Integrierbarkeit von OpenID Connect und der besseren Unterstützung durch mobile Plattformen wurde sich bewusst gegen SAML 2.0 entschieden.

Das gewählte Protokoll (OpenID Connect) trifft grundsätzlich keine Vorgaben bezüglich der zu verwendenden Authentfizierungsmechanismen. Somit sind grundsätzlich beliebige Mechanismen/Verfahren vorstellbar, die durch den Identity Provider zur Überprüfung der Versichertenidentität genutzt werden können. Dies eröffnet u.a. die Möglichkeit, die elektronische Gesundheitskarte bzw. das auf ihr enthaltene Schlüsselmaterial zum Zwecke der Authentifizierung der Versicherten zu nutzen.

eGK-/Zertifikat-basierte Authentisierung

Folgendes, hier vereinfacht dargestelltes Modell wird durch das Projekt vorgeschlagen:

EGK-basierte Authentisierung

Eine detaillierte Darstellung der Abläufe, die eine Einbindung in den kompletten OIDC-Flow darstellt, findet sich im Abschnitt “Initiale Nutzerregistrierung inkl. Smartcard-basierter Authentisierung”.

Hinweis: Für die Realisierung einer zertifikatsbasierten Authentifizierung wird häufig auch auf Verfahren gesetzt, die zum Nachweis des Besitzes des zugehörigen privaten Schlüsselmaterials den Aufbau einer beidseitig authentisierten TLS-Verbindung erforderlich machen. Aus Gründen der Komplexitätsreduktion bei der Entwicklung der client- und server-seitigen Authentifizierungskomponenten wurde diese Ansatz jedoch nicht aufgegriffen.

Keystore-basierte Authentisierung

Wie bereits im Abschnitt Unterstützung ergänzender Authentisierungsverfahren dargestellt, ist es denkbar, Alternativen zur eGK-basierten Authentisierung vorzusehen. Folgendes Modell wird durch das Projekt als Proof-of-Concept vorgeschlagen:

1 - Im mobilen Endgerät wird asymmetrisches Schlüsselmaterial generiert
2 - Der privaten Teil des Schlüsselmaterials wird sicher im Endgerät verwahrt, der öffentlichen Teil wird dem Identity Provider bekannt gemacht (z.B. im Zuge der Erstregistrierung).
3 - Fortan könnte neben der eGK auch das generierte Schlüsselmaterial (nach dessen expliziter Freischaltung) zur Authentifizierung der Versicherten genutzt werden.

In weniger sicherheitskritischen Szenarien kann diese Modell u.U. dazu beitragen, die Usability des Gesamtsystems zu verbessern

Eine detaillierte Darstellung der Abläufe, die eine Einbindung in den kompletten OIDC-Flow darstellt, findet sich im Abschnitt Initiale Nutzerregistrierung inkl. Smartcard-basierter Authentisierung sowie im Abschnitt Keystore-basierter Authentisierung.

Hinweis: Der im Projekt verfolgte Alternativansatz birgt eine Reihe von Risiken, welche ggf. in einem Folgeprojekt näher untersucht und - wenn möglich - ausgeräumt werden sollten. Interessante Lösungsansätze bilden hier ggf. das Key-Attestation-Verfahren in Kombination mit speziellen Kryptoprozessoren (HSM).

Session-basierte Authentisierung

Fast alle Identity Provider bieten die Möglichkeit eines Single-Sign-On. Dabei authentisiert sich der Nutzer einmalig am Identity Provider und baut mit diesem eine Session auf (häufig abgebildet über ein Session-Cookie, welches im http-Header transportiert wird). Für einen definierten Zeitraum kann der Nutzer nun diese Session nutzen, um sich neue Authentifizierungsnachweise für verschiedene Anwendungen ausstellen zu lassen. Aus Usability-Sicht bietet diese Vorgehen durchaus Vorteile, welche jedoch immer gegeüber den Sicherheitserfordernissen der zu schützenden Anwendung abzuwiegen sind.

Eine detaillierte Darstellung der Abläufe, die eine Einbindung in den kompletten OIDC-Flow darstellt, findet sich im Abschnitt Session-Cookie-basierte Authentisierung.

Transparenz bezüglich des verwendeten Authentisierungsverfahrens

Wie bereits kurz dargestellt, kann davon ausgegangen werden, dass verschiendene eHealth-Anwendungen sehr verschiedene Anforderungen bezüglich des erforderlichen Sicherheits-/Vertrauensniveaus haben werden. Während es für einige Anwendungen ausreichend sein kann, auf den Session-basierten Authentisierungsmechanismus zurückzugreifen, können einzelne andere Anwendungen u.U. die eGK-basierte Authentisierung einzelner Transaktionen erfordern. Um die komplette Bandbreite der Szenarien abdecken zu können, wird ein Mechanismus benötigt, der es für Token konsumierende Anwendungen transparent macht, welche Authentisierungmethode der Tokenausstellung zugrunde lag. Hierfür bieten sich die beiden folgenden JSON Web Token Claims an:

amr (Authentication Method Reference): Bei der amr handelt es sich um ein JSON-String-Array, welches identifier beinhaltet, die auf die oder das verwendeten Authentifizierungsverfahren verweisen. Entsprechend RFC8176 sind die Werte sc (Smart card) und swk (Proof-of-Possession of a software-secured key) für die vorgesehenen Verfahren von besonderem Interesse.
acr (Authentication Context Class Reference): Die acr definiert konkrete Geschäftsregeln, die durch das verwendete Authentisierungsverfahren adressiert werden müssen. Für das AsK-Projekt wird dieses Feld in leicht abgewandelter Form genutzt: Nimmt acr den Wert “0” an, wurde der oben beschriebene SSO-Mechanismus (Session-basierte Authentisierung) verwendet. Nimmt das Attribut jedoch den Wert “1” an, wurde das Token auf Basis einer frischen Authentisierung ausgestellt. Durch diesen Ansatz bleibt auch bei einer Session-basierten Authentisierung ersichtlich, welches Authentisierungsverfahren die jeweilige Session begründet hat.

Im folgenden Beispiel ist ein Token zu sehen, welches auf Basis einer Session-basierten Authentifizierung ausgestellt wurde. Der Session zugrunde liegt eine Smartcard-basierte Authentisierung, die zum Zeipunkt auth_time=1550064384 (2019-02-13T13:26:24+00:00) erfolgt ist:

{
  "jti": "ad437ded-619e-460f-a95c-53e7d6465f2b",
  "exp": 1550066215,
  "nbf": 0,
  "iat": 1550064415,
  "iss": "https://ehealth-ask.fokus.fraunhofer.de/auth/realms/AsK",
  "aud": "asktest",
  "sub": "fd2430ea-060b-4abe-b7a2-2fa07fd8ec57",
  "typ": "Bearer",
  "azp": "asktest",
  "nonce": "nonce",
  "auth_time": 1550064384,
  "session_state": "43964903-c2f5-4ae8-ad55-315acdcddc26",
  "acr": "0",
  "amr": [
    "sc"
  ],
  "allowed-origins": [],
  ...
  "name": "Peer Francesco Sebastian Graf Geiböll",
  "preferred_username": "m-1458097631",
  "given_name": "Peer Francesco Sebastian Graf",
  "family_name": "Geiböll",
  "email": "x110385628@egk.de"
}

Prototypische Realisierung

Die prototypische Realisierung nutzt eine speziell für das Projekt angepasste Version von keycloak zum Realiseren der benötigten Funktionalität. Detaillierte Informationen zur Ausgestaltung/Konfigurationen können der Realisierungsdokumentation entnommen werden.

Terminologie Server

Die Aufgabe des Terminologie Servers liegt primär im Umfeld der zentralen Bereitstellung von Ontologien. Einfache Beispiele hierfür sind standardisierte Codes für Termintypen, Dokumenttypen oder auch Inhaltstypen von Dokumentabschnitten.

Technische Architektur - Terminologie Server

Schnittstellen

Der Terminologie Server besitzt Schnittstellen zu den folgenden Komponenten:

Client: Die App des Nutzers (Client) nutzt den Terminologieserver u.a. zum Abruf von Code Systemen, Value Sets und Concept Maps, die im Rahmen der Fachlichkeit (z.B. für Rendering von Dialogen und Auswahllisten) benötigt werden. (1)
FHIR Server: Der FHIR Server greift auf den Terminologieserver zu, um beispielsweise Code Systeme und Value Sets abzurufen. Diese werden z.B. benötigt, um (einzustellenden) FHIR-Resourcen gegen ein bestimmtes Profil zu validieren. (2)

FHIR Terminology Service

Grundlage der Implementierung des Terminologie Servers sollte eine Lösung sein, die an den Außenschnittstellen die Vorgaben des FHIR Terminology Service umsetzt.

Prototypische Realisierung

Von einer prototypischen Implementierung des Terminologieservers wurde im Rahmen des Projektes Abstand genommen. Die benötigten Codesystem bzw. Codes werden als fester Bestandteil der App ausgeliefert. Ein dynamische Nachladen ist somit nicht möglich. Sofern die Einwilligungs-App zukünftig weiterentwickelt werden wird (z.B. Ergänzung von Anamnesebögen), muss die benötigte Funktionalität entsprechend nachgezogen werden.

Signalling Server

Der Signalling Server wird von den Kommunikationspartnern der Audio-/Videokonferenz genutzt, um über einen gemeinsamen Endpunkt relevante Kommunikationsparameter für die WebRTC-Verbindung (vgl. Prämissen) auszutauschen. Um diese Funktion sicher und verlässlich ausführen zu können, muss der Service verschiedene Aufgaben erfüllen:

Abbildung der Signalisierungsfunktionalität: Der Signalling Server muss die performante Vermittlung von Nachrichten zwischen zwei Clients realisieren. WebRTC trifft keinerlei Aussagen über den Weg oder die Technologie, mit welcher der Austausch der Kommunikationsparameter erfolgen muss. Dies macht es erforderlich eine passende Lösung für das AsK-Projekt auszuwählen oder zu entwickeln. Für die Umsetzung der entsprechenden Funktionalität ist das klassische Publish-Subscribe-Modell hervorragend geeignet. In diesem Modell abboniert ein Teilnehmer (A) einen Informationskanal bei einem Broker. Wann immer ein anderer Teilnehmer (B) eine Nachricht in diesem Kanal bei diesem Broker veröffentlicht, wird Teilnehmer (A) darüber informiert und erhält die entsprechende Nachricht.
Authentifizierung von Kommunikationsteilnehmern: Um sicherzustellen, dass nur berechtigte Anwender den Signalisierungsdienst nutzen können, ist es erforderlich, diese verlässlich zu authentifizieren. Nur erfolgreich authentifizierte Nutzer sollen in der Lage sein, Nachrichten über den Signallisierungsdienst auszutauschen.
Autorisierung von Kommunikationsteilnehmern: Viele verschiedene Nutzer sollen den Signallisierungsdienst parallel nutzen können. Somit ist es erforderlich, dass eine Funktionalität umgesetzt wird, die sicherstellt, dass Nutzer nur dann Nachrichten mit anderen Nutzern austauschen können, wenn sie mit diesen den Aufbau und die Durchführung einer Videokonferenz verabredet haben.

Technische Architektur - Signalling Server

Schnittstellen

Der Signalling Server besitzt Schnittstellen zu den folgenden Komponenten:

Client: Verbindungen zum Signalling Server werden ausschließlich von den Clients (vermittelt über den Reverse Proxy) aufgebaut. Diese nutzen den Signalling Server zum Austausch/Aushandeln von Kommunikationsparametern. (1)
Identity Provider: Im Rahmen der Authentifizierung der Clients muss der Signalling Server in die Lage versetzt werden, die für die Authentifizierung genutzten Credentials (OIDC-Token) zu validieren und zusätzliche Nutzerinformationen abzurufen. Dazu benötigt er Zugriff auf ausgewählte Endpunkte des Identity Provider (keysource, userinfo)(2)

MQTT als Übertragungsprotokoll

Als Ergebnis der Analyse möglicher Lösungsansätze wurde entschieden, MQTT als Protokoll für den Austausch von Kommunikationsparametern zu nutzen. Diese Entscheidung begründet sich im Einzelnen wie folgt:

Reifegrad und Standardisierung: Das Protokoll existiert bereits seit vielen Jahren und kommt in vielen verschiedenen Anwendungsbereichen zum Einsatz. Version 3.1.1 wurde 2014 als OASIS Standard verabschiedet.
Leichtgewichtigkeit/Performance: Das MQTT-Protokoll wurde mit dem Anspruch geschaffen, sehr geringe Anforderungen an die vorhandene Bandbreite der Datenverbindung zu stellen. Dementsprechend weisen Nachrichten nur einen sehr kleinen Protokolloverhead auf und können extrem performant verarbeitet werden.
Quality of Service: MQTT unterstützt “Quality of Service” Mechanismen. Diese ermöglichen die Umsetzung einer Lösung mit hohen Ansprüchen bezüglich der Zusicherung, dass Kommunikationsparameter zuverlässig ausgetauscht wurden.
Authentication/Authorization: Das Protokoll unterstützt im CONNECT Paket das Mitsenden von Username und Password. Dieser Mechanismus kann im Zusammenspiel mit den anderen Paketinhalten für die Umsetzung eines Authentication und Authorization Mechanismus genutzt werden.
Websocket Unterstützung: MQTT erlaubt es, Websockets als Netzwerktransportmechanismus zu nutzen. Dies ist ggf. in Bezug auf die Verwendung von Firewallsystemen und Gateways von Vorteil, da Websocket-Verbindungen deutlich seltener blockiert werden als andere “Nicht-Web”-Protokolle.
Brokerauswahl: Es existiert eine Vielzahl von Brokerlösungen, die das MQTT-Protokoll implementieren. Dabei handelt es sich sowohl um komerziell vertriebene als auch Open Source Software.
Clientauswahl: Neben einer großen Auswahl an Brokern finden sich ebenfall sehr viele Clientbibliotheken, die das Protokoll implementieren, darunter auch für dei Android-Plattform

Abbildung der Signalisierungsfunktionalität mit MQTT

Die Grundidee in der Nutzung von MQTT als Signalisierungskanal für den Austausch von (WebRTC)-Kommunikationsparametern besteht darin, dass sich die beiden an der Videokonferenz teilnehmenden Akteure auf ein oder mehrere MQTT-Topics einigen, die für den Nachrichtenaustausch genutzt werden. Diese Topics müssen dabei eindeutig sein, d.h. für zwei verschiedene Videokonferenzen dürfen niemals dieselben Topics verwendet werden.

Der für die Umsetzung von Ask gewählte Ansatz sieht die Verwendung von mehreren strukturierten Topics vor. Die Struktur folgt dabei dem folgenden Muster:

vc/{APPOINTMENT_ID}/{CLIENT_TYPE}/{CONTENT_TYPE}

/ - Der forward slash dient der Separierung der verschiedenen Ebenen (“levels”) des Topic-Baums
vc - Identifiziert den Anwendungstyp (hier “Videokonferenz”)
{APPOINTMENT_ID} - 32 Zeichen langer zufälliger String bestehend aus folgenden Zeichen: “ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789”. Die AppointmentID wird für die Kommunikationspartnern im Rahmen der Terminvereinbarung vom Termin-verwaltenen System (FHIR Server) erstellt.
{CLIENT_TYPE} - Es werden die beiden Client-Typen “patient” (Patient) und “hcp” (Leistungserbringer) unterschieden. Die Anwendung des Patienten veröffentlicht ihre Nachrichten im Zweig “patient”, die des Leistungserbringers im Zweig “hcp”
{CONTENT_TYPE} - Es wird zwischen den Inhaltstypen “status”, “offer”, “answer” und “candidate” unterschieden. Über “status” werden Informationen zum Status der Verbindung des jeweiligen Clients ausgetauscht und Nachrichten übertragen, die später den verschlüsselten Austausch von WebRTC-Kommunikationsparametern ermöglichen. Über “offer”, “answer” und “candidate” werden WebRTC-Parameter ausgetauscht.

Beispiele für Topics:

"vc/4PV3XxsvVd0O32CK8wbueuaiZiZU3MCT/hcp/status"
"vc/4PV3XxsvVd0O32CK8wbueuaiZiZU3MCT/hcp/answer"
"vc/4PV3XxsvVd0O32CK8wbueuaiZiZU3MCT/hcp/candidate"
"vc/4PV3XxsvVd0O32CK8wbueuaiZiZU3MCT/patient/status"
"vc/4PV3XxsvVd0O32CK8wbueuaiZiZU3MCT/patient/offer"
"vc/4PV3XxsvVd0O32CK8wbueuaiZiZU3MCT/patient/candidate"

Detaillierte Informationen zum MQTT basierten Verbindungsaufbau finden sich im Abschnitt Signalisierung (sichere Aushandlung der Video-/Audiokonferenzparameter).

Abbilden der Authentifizierungsfunktionalität mit MQTT

Das MQTT-Protokoll unterstützt im CONNECT Paket das Mitsenden von Username und Password Attributen, die durch den Broker für die Authentifizierung des Clients genutzt werden können. Die AsK-Architektur sieht jedoch keine Unterstützung von klassischen Passwort-basierten Authentifizierungsmechanismen vor. Um dieses Problem zu lösen, muss der MQTT-Client anstelle des Nutzernamens einen vom Identity Provider ausgestellten OIDC Identity Token mitsenden. Es obliegt dem MQTT-basierten Signalling Server diesen Token zu validieren. Bei Bedarf kann der Signalling Server dafür auch eine Verbindung zu den benötigten Endpunkten des Identity Providers aufbauen (vgl. Schnittstellen).

Abbilden der Autorisierungsfunktionalität mit MQTT

Der Signalling Server muss sicherstellen, dass nur authentifizierte Kommunikationspartner über die ihnen über die {APPOINTMENT_ID} zugeordneten Topics Kommunikationsparameter austauschen können. Zur Umsetzung dieser Anforderung bieten sich verschiedene Lösungsoptionen an:

Die Autorisierungskomponente des MQTT Servers verbindet sich mit der Terminverwaltung und prüft anhand von aus dem Id Token im Rahmen der Authentifizierung extrahierten Parametern (z.B. KVNR), ob für den jeweiligen Akteur ein Termin mit der entsprechenden {APPOINTMENT_ID} vorliegt. Ist dies der Fall, autorisiert die Komponente die Subscription für ein bestimmtes Topic.
Alternativ prüft die Autorisierungskomponente lediglich die Struktur eines für eine Subscription vorgesehenen Topics. Kann sichergestellt werden, dass die oben beschriebene Topic Baumstruktur eingehalten wird und Topic Wildcards lediglich für die letzten beiden Level (z.B. “vc/4PV3XxsvVd0O32CK8wbueuaiZiZU3MCT/+/+”) genutzt werden, kann die Komponente die Subscription des Topics autorisieren. Voraussetzung für die Verwendung dieses alternativen Ansatzes ist jedoch, dass die {APPOINTMENT_ID} ausreichend zufällig gewählt ist, da sonst Topics von Dritten erraten und subsribiert werden könnten.

Prototypische Realisierung

Die prototypische Realisierung nutzt eine angepasste Version von mosquitto als MQTT-basierten Signallisierungsdienst. Detaillierte Informationen zur Ausgestaltung/Konfigurationen können der Realisierungsdokumentation entnommen werden.

FHIR Server

Der FHIR Server nimmt eine zentrale Rolle in der technischen Architektur ein. Mithilfe des Dienstes wird ein Verzeichnisdienst für Patienten, Leistungserbringer und Dienste/Angebote geschaffen. Darüber hinaus steht zusätzlich Funktionalität zur Verwaltung von Terminen und Dokumenten bereit. Der Server setzt dafür große Teile der FHIR Spezifikationen um. Zur Abbildung der identifizierten Anwendungsfälle war es erforderlich, eine Profilierung der von FHIR definierten Basis-Ressourcen vorzunehmen. Alle notwendigen Anpassungen sind in Form eines Implementierungsleitfadens dokumentiert. In diesem wird detailliert beschrieben, wie und in welcher Form die benötigten Ressourcen verwendet werden sollen.

Technische Architektur - FHIR Server

Schnittstellen

Der FHIR Server besitzt Schnittstellen zu den folgenden Komponenten:

Client: Die Clients (Apps der Ärzte und Versicherten) greifen auf den FHIR Server zu, um einen Großteil der beschriebenen Anwendungsfälle im Bereich der Videokonsultation und elektronischen EInwilligung (z.B. Videokonsultationsangebote suchen oder Termine buchen) realisieren zu können. (1)
Identity Provider: Im Rahmen der Authentifizierung der Clients muss der FHIR Server in die Lage versetzt werden, die für die Authentifizierung genutzten Credentials (OIDC-Token) zu validieren und zusätzliche Nutzerinformationen abzurufen. Dazu benötigt er Zugriff auf ausgewählte Endpunkte des Identity Provider (keysource, userinfo). (2)

Abbildung des Patientenverzeichnisses

Da der FHIR Server für die Verwaltung der Informationen von verschiedenen Versicherten/Patienten genutzt wird und nahezu alle verwendeten FHIR Ressourcen einen Bezug zu den entsprechenden Versicherten/Patienten herstellen, ist es unerlässlich ein Verzeichnis der entsprechenden Akteure zu pflegen. Die Anlage der einzelnen Patient Resources erfolgt hierbei durch die Patienten selbst, z.B. im Zuge der Registrierung eines Videokonferenztermins. Um sicherzustellen, dass die bei der Anlage übermittelten Angaben korrekt und authentisch sind, erfolgt ein Abgleich mit den im beigefügten OpenId Connect Access/Identity Token enthaltenen Identitätsattributen.