Ein Messenger-Service besteht immer aus den zwei Teilkomponenten Messenger-Proxy und Matrix-Homeserver. Der Messenger-Proxy dient als Prüfinstanz und leitet alle Anfragen an den Matrix-Homeserver weiter. Der Matrix-Homeserver basiert auf dem offenen Kommunikationsprotokoll Matrix. Welche Schnittstellen der Messenger-Service nutzt und anbietet ist in der folgenden Abbildung dargestellt:
Der Messenger-Proxy als Prüfinstanz aller eingehenden, sowie ausgehenden Anfragen zum Matrix-Homeserver ist für die Regelung der gemäß Matrix-Client-Server-API und Matrix-Server-Server-API geltenden Aufrufe zuständig. Daher ist es erforderlich, dass der Messenger-Proxy für jeden Messenger-Service als Forward- sowie Reverse-Proxy bereitgestellt wird. Die folgende Abbildung verdeutlicht die beide gerade skizzierten Funktionsweisen.
Bei Aufruf der Client-Server-API durch einen TI-Messenger-Client aus dem Internet fungiert der Messenger-Proxy als Reverse-Proxy. Beim Aufruf der Server-Server-API im Rahmen einer Server-To-Server Kommunikation fungiert der Messenger-Proxy als Forward-, sowie als Reverse-Proxy.
|
🔥
|
Der Messenger-Proxy routet gültige Anfragen zum Matrix-Homeserver und muss nicht selbst das Matrix-Protokoll implementieren. |
Diese von der gematik nicht normativ vorgegebene Schnittstelle wird benötigt, um die geforderte 2-Faktor-Authentifizierung zu realisieren, da diese Funktionalität aktuell von keinem Matrix-Homeserver angeboten wird (siehe MSC1998). Hierfür muss der Messenger-Proxy die Möglichkeit bieten, mit externen Authentisierungsdiensten zu interagieren.
|
💡
|
Mit der zukünftigten Unterstützung von OIDC durch die Matrix-Homeserver, wird die geforderte Unterstützung durch den Messenger-Proxy nicht mehr benötigt. |
Der Messenger-Proxy muss die Schnittstelle I_TiMessengerContactManagement als REST-Webservice über HTTPS gemäß TiMessengerContactManagement.yaml umsetzen, um den TI-Messenger-Clients die Verwaltung einer persönlichen Freigabeliste zu ermöglichen.
Die Schnittstelle findet u.a. Verwendung in AF_10061 - Einladung von Akteuren außerhalb einer Organisation.
Die Berechtigungsprüfung findet bei der Client-Server Kommunikation sowie bei der Server-Server Kommunikation statt (siehe Stufen der Berechtigungsprüfung).
Eine aktuelle Version der Föderationsliste wird vom Messenger-Proxy über die Schnittstelle I_internVerification abgerufen. Der Abruf erfolgt entweder zyklisch über ein vom Anbieter definiertes Intervall oder im Rahmen der Föderationsprüfung, wenn eine Domain in der aktuell vorliegenden Liste nicht enthalten ist.
Der Messenger-Proxy muss sicherstellen, dass die vom Registrierungs-Dienst bereitgestellte Föderationsliste valide ist. Hierzu muss der Messenger-Proxy die Signatur der Föderationsliste unter Verwendung des mitgelieferten Signaturzertifikates (x5c-Header) überprüfen (siehe Aktualisierung der Föderationsliste).
Für bestimmte Funktionalitäten ist es notwendig, dass Anfragen nicht durch die Berechtigungsprüfung des Messenger-Proxys abgelehnt werden. So muss eine Anfrage des VZD-FHIR-Directory an die .well-known Datei erlaubt sein, um einen eigenen Port für Anfragen des VZD-FHIR-Directoy zu hinterlegen, um später über diesen Port den /_matrix/federation/v1/openid/userinfo-Endpunkt aufzurufen. Hierzu muss der Messenger-Proxy ebenfalls den Zugriff erlauben, damit das VZD-FHIR-Directory einen Matrix-OpenID-Token prüfen lassen kann.
Werden durch einen Anbieter eines TI-Messenger-Fachdienstes mehrere Matrix-Domains in einem gemeinsamen Messenger-Service betrieben, so muss die logische Trennung der Matrix-Domains sichergestellt werden. Die Art der Umsetzung bleibt dem Hersteller eines TI-Messenger-Fachdienstes überlassen.
|
💡
|
Empfehlung der gematik ist eine Mandantentrennung über seperate Messenger-Services, die jeweils eine eigene Domain verwalten, zu realisieren. |
Eine mögliche Umsetzung wäre die Mandantentrennung über einen Matrix-Server zu realisieren, der mehrere Domains unterstützt. Diese Funktionalität wird aktuell von keinem Matrix-Server angeboten.
|
🔥
|
Bei einer logischen Mandantentrennung muss sichergestellt werden, dass die Prüfung der Föderationszugehörigkeit (Zuordnung SMC-B zu Domain) sichergestellt ist und jeder mandantenübergreifende Zugriff verhindert wird. |
Der Matrix-Homeserver muss die Server-Server API und Client-Server API gemäß der Matrix-Spezifikationen in der Version v1.3 umsetzen.
Der Matrix-Homeserver eines Messenger-Services:
-
muss Anfragen vom eigenen Messenger-Proxy akzeptieren und
-
Anfragen anderer Messenger-Proxies NICHT akzeptieren.
|
💡
|
Als Referenz für einen Homeserver wird die synapse Referenzimplementierung empfohlen. |