Systemüberblick

Unter Fachanwendungen im Kontext der TI-Föderation werden medizinische Anwendungen verstanden, die zur Nutzerauthentifizierung die sektoralen Identity Provider der TI-Föderation nutzen. Fachanwendungen (teilweise auch als Fachdienste bezeichnet) sind nach aktueller Definition:

• TI-Anwendungen (E-Rezept, elektronische Patientenakte, KIM, TIM)
• Digitale Gesundheitsanwendungen (DiGA)
• Fachanwendungen der Krankenkassen
• Fachanwendungen für Leistungserbringer und Institutionen
• Weitere Anwendungen für den Datenaustausch in der Telematikinfrastruktur (WANDA)

Ein weiteres Kriterium der Fachanwendungen ist deren Zielgruppe und damit verbunden die im Rahmen einer Nutzerauthentifizierung zielgruppenspezifische Daten- und Sicherheitsanforderungen:

• gesetzlich Versicherte
• privat Versicherte
• Leistungserbringer (Ärzte, Hebammen, Physiotherapeuten, u.ä.)
• Leistungserbringerinstitutionen (Krankenhäuser, Praxen, Apotheken u.ä.)

Eine Fachanwendung in der TI-Föderation besteht im Allgemeinen aus den folgenden Komponenten (siehe auch Fachliche & technische Grundlagen sowie Standards):

• Authorization-Server: Entsprechend dem OAuth2.0-Standard ist die Autorisierung eines Nutzers getrennt vom eigentlichen Zugriff auf Fachdaten und -prozesse. Der Authorization-Server des Fachdienstes implementiert diese Autorisierung. Dazu muss der Nutzer der Fachanwendung erst einmal authentisiert werden. Die Nutzerauthentisierung erfolgt nach dem OpenID Connect (OIDC) Standard. Im Kontext dieses Standards ist der Authorization-Server des Fachdienstes eine Relying Party (RP). Er stößt die Authentisierung des Nutzers beim sektoralen IDP an und erhält als Ergebnis einen Authorization Code, den er gegen ein ID-Token (und Access-Token) beim sektoralen IDP eintauscht. Der Authorization-Server des Fachdienstes verwendet die Informationen aus dem ID-Token für die Feststellung der Zugriffsrechte des authentisierten Nutzers auf die Ressourcen des Fachdienstes. Ist der Datenzugriff berechtigt, stellt der Authorization-Server des Fachdienstes ein eigene Access-Token (und ggf. ein Refresh-Token) für das Anwendungsfrontend aus. Erst dann kann der Nutzer über das Anwendungsfrontend auf die Anwendungsfälle des Fachdienstes zugreifen.
• UI-Backend: Das UI-Backend nimmt Anfragen der UI entgegen und stellt der UI Daten zur Anzeige bereit. Je nach technischer Implementierung wird die gesamte UI mit den Daten im UI-Backend erstellt und dem Anwendungsfrontend präsentiert (serverside rendered progressive web-app) oder das UI-Backend liefert Daten und die UI Aufbereitung erfolgt im Anwendungsfrontend (native APP, single page web-app). Das UI-Backend sollte auf der Serverseite des Fachdienst getrennt von Authorization-Server und den Business-Services des Fachdienstes implementiert werden.
• Resource-Server: Nach OAuth2.0-Standard implementiert der Resource-Server die eigentliche fachliche Logik (Business-Services) des Fachdienstes.

Schnittstellen

Die folgende Tabelle enthält einen kurzen Überblick über die Schnittstellen der Komponenten des Fachdienstes. Detailliertere Informationen zum den Abläufen und den Schnittstellen findet man im App2App-Flow, Web2App-Flow und 2-Geräte-Flow.

Anforderungen an einen Fachdienst für die Teilnahme an der Föderation

Die Anforderungen für die Telematik Infrastruktur sind in Spezifikationen der gematik veröffentlicht. Für einen Fachdienst in der TI-Föderation sind vor allem diese Spezifikationen relevant

• • gemSpec_IDP_FD - Anforderungen an einen Fachdienst der TI-Föderation
    • Alle Kapitel sind wichtig für die Umsetzung einen Fachdienstes für die TI-Föderation.
    • Ausnahme: Kapitel "5 Anbindung eines Fachdienstes an den zentralen IDP-Dienst" - Dieser Spezialfall für die Anmeldung von Leistungserbringern und Leistungserbringerinstitutionen ist derzeit nur für wenige Fachdienste relevant.
  • gemSpec_IDP_Sek - Anforderungen an den sektoralen IDP der TI-Föderation
    • Kapitel "4 Funktionsmerkmale" - enthält Informationen zu den Schnittstellen des sektoralen IDP, sowie zur Identifikation und Authentisierung von Nutzern
    • Kapitel "5 Anforderungen an Authenticator-Module sektoraler IDPs" - enthält Informationen zum Authenticator-Modul
    • Kapitel "7 Anhang B - Abläufe"
  • gemSpec_IDP_FedMaster - Anforderungen an den Federation Master der TI-Föderation
    • Kapitel "3  Funktionsmerkmale" enthält wichtige Informationen zu den Anwendungsfällen und Schnittstellen des Federation Master  "IDP-Liste bereitstellen", "Entity Statement bereitstellen" und "Schlüssel verwalten".
    • Kapitel "4.2 - Organisatorische Prozesse am Federation Master" enthält wichtige Informationen zur Teilnehmerregistrierung.
  • gemSpec_IDP_Frontend - Spezifikation Identity Provider - Frontend
    
    • Kapitel "9 Nutzung sektoraler Identity Provider" - enthält wichtige Informationen zur Kommunikation eines Anwendungsfrontend mit dem Authenticator-Modul eines sektoralen IDP. 
  • gemSpec_Krypt - kryptografische Anforderungen
  • gemSpec_Perf - Anforderungen an Performance und betriebliche Anforderungen

Im Folgenden werden einige wichtige Informationen aus den Spezifikationen erläutert.

Entity Statement

Jeder Teilnehmer der TI-Föderation muss Auskunft über sich in Form eines standardkonformen Entity Statement abgeben. Ein Entity Statement ist immer ein signiertes JWT (Beispiel des JWT des Entity Statement eines sektoralen IDP - siehe  Umgebungen, Referenzimplementierungen, Codebeispiele sektoraler IDP). Die Anforderungen an das Entity Statement eines Fachdienstes können in den gematik Spezifikationen gemSpec_IDP_FD und den Anlagen von gemSpec_IDP_Sek nachgeschlagen werden. 

Die Tabelle zeigt ein Beispiel für das Entity Statement eines Fachdienstes (Auszug aus gemSpec_IDP_Sek Kapitel 7):

Unter der signed_jwks_uri (oder alternativ als zusätzliches jwks unterhalb von metadata/openid_relying_party) finden sich dann die weiteren Schlüssel des Fachdienstes

Schlüssel für die TLS Client Authentisierung sind erkennbar am gesetztem x5c Wert und use=sig.

Schlüssel für die Verschlüsselung der übertragenen ID_Token durch den IDP sind erkennbar an use=enc.

Sichere Kommunikation

Die Kommunikation zwischen den Teilnehmern der Föderation ist über kryptografische Verfahren gesichert. 

• Die Kommunikation zwischen Fachdienst und Identity Provider erfolgt über mTLS
• Entity Statements sind signiert
• Die vom Federation Master abfragbare Liste der registrierten Identity Provider ist signiert
• Das unter der im claim "signed_jwks_uri" genannten URL ladbare Schlüsselset ist signiert
• Ausgestellte ID-Token und Access-Token sind signiert und verschlüsselt

Die Schlüssel und Zertifikate sind über das Entity Statement des jeweiligen Teilnehmer verfügbar (Root-claim "jwks" und Metadata-claim "signed_jwks_uri"). Die Angaben über die supporteten Signatur- und Verschlüsselungsalgorithmen sind ebenfalls über die Entity Statements der Teilnehmer öffentlich zugänglich.

Weitere Maßnahmen erhöhen die Sicherheit in der Teilnehmerkommunikation gegen Angriffsszenarien  :

• state [OAuth 2.0 for Native Apps (section-8.9)] → Der Ersteller des Authorization-Request generiert einen Zufallswert, der als state-Parameter Teil des Authorization-Request ist. Die Antwort auf den Request muss den state-Parameter unverändert an den Aufrufer zurückgeben. Der Aufrufer verifiziert den Wert. Ein state-Parameter wird sowohl in der Kommunikation des Anwendungsfrontend mit dem Authorization-Server des Fachdienstes, als auch in der Kommunikation des Authorization-Server des Fachdienstes mit dem Identity Provider gesetzt.
• nonce → Der Authorization-Server des Fachdienstes generiert einen Zufallswert, der als nonce-Parameter Teil des Authorization-Request ist. Dieser nonce-Wert muss vom Identity-Provider als claim im ID-Token an den Authorization-Server des Fachdienstes zurückgegeben werden. Dieser prüft den Rückgabewert gegen den Ausgangswert.
• PKCE [RFC7636 - Proof Key for Code Exchange by OAuth Public Clients] → Sowohl in der Kommunikation des Anwendungsfrontend mit dem Authorization-Server des Fachdienstes, als auch in der Kommunikation des Authorization-Server des Fachdienstes mit dem Identity Provider wird PKCE eingesetzt. Dies verhindert das Angreifer welche trotz der weiteren Maßnahmen in den Besitz eines Auth_Code geraten sind diesen gegen ein valides Token eintauschen können.

Zugang zur Testumgebung

Fachdienste können die Integration der TI-Föderation testen. Hierzu steht sowohl eine Referenzimplementierung des Federation Masters als auch ein von der gematik entwickelte Implementierung eines sektoralen IDPs bereit. Um Ende-zu-Ende Tests durchzuführen, ist eine Registrierung in der Testumgebung notwendig. Alle Informationen hierzu finden Sie hier: Fachdienste Test-Umgebungen 

Perspektivisch werden auch Tests gegen Referenzimplementierungen der sektoralen IDPs der Kostenträger inkl. Authenticator-Apps möglich sein. Die Bereitstellung beider Komponenten befindet sich aktuell noch in Abstimmung.