Eine Matrix-Domain für mehreren Organisationen

[benkuly]

Aus wirtschaftlicher und ökologischer Sicht ergibt es keinen Sinn, warum pro Organisation ein kompletter Fachdienst hochgefahren werden muss. So müssen hier bei sehr kleinen Organisationen schnell mal tausende Fachdienste betrieben werden. Dies bedeutet mit den aktuell gängigen Matrix-Komponenten einen enormen Ressourcen-Bedarf und ist im Angesicht der Energie- und Klimakrise mindestens kritisch anzusehen. Auch der Betrieb wird dadurch deutlich komplexer und aufwendiger.

Aus technischer und organisatorischer Sicht ist solch eine Anforderung gar nicht notwendig. Es können problemlos tausende Organisationen auf einem Fachdienst existieren. Die Regeln der Sichtbarkeit und Einladungsprüfung (wenn nicht bereits auf den Client ausgelagert via #155) können hier problemlos durch den Proxy (über Client-Server-API) geschehen. Ein Proof-Of-Concept zeigt uns, dass solch ein Szenario auf jeden Fall umsetzbar ist.

Mein Vorschlag wäre nun, dass man es den Betreibern überlässt, wie Organisationen getrennt werden, ob über Domains oder erweiterte Proxies.

Bemerkung: Manchen mag die angesprochenen Probleme sicherlich bekannt vorkommen. Wir setzen uns bereits seit 1,5 Jahren dafür ein und wollen hier nochmals die öffentliche Diskussion dazu anregen.

[AlexB030]

Hallo @benkuly ,
wir haben intern über diesen Ansatz gesprochen und dabei wurde auch bemerkt, dass diese Diskussion vor über einem Jahr schon einmal geführt wurde und es damals keine fundamentalen Argumente dagegen gab.
Aus der aktuellen internen Diskussion heraus wurden einige Aspekte identifiziert, die wir für "schwierig" halten, was aber nicht heißen muss, dass das nicht geht.

Unsere finale Erkenntnis war, dass die Spec es grundsätzlich nicht verbietet. Wir würden das Thema aber gerne im Rahmen von einem der geplanten Tech-Talks genauer betrachten bzw. erzählt bekommen. Tatsächlich auch mit dem Ziel den Vorschlag in der Präsentation auf die Probe zu stellen und zu schauen, ob es wirklich keine verhindernden Gründe gibt.

Wäre das eine Option?

Gruß,
Alex (gematik)

[benkuly]

Ich finde der Begriff "Matrix-Domain", wie er überall in der Spec verwendet wird, lässt keine Interpretation zu, die es erlauben würde mehrere Organisationen pro Matrix-Domain zu erlauben. Vor allem im Teil Berechtigungskonzept wäre der Begriff "Organisation" an mancher Stelle eindeutiger, um Domain von Organisation zu trennen. Dennoch können wir dies gerne in Tech-Talks behandeln.

[mb010865]

We were also doing our architecture design following the discussions 1,5 years ago.
The message was clear: 1 Organisation <-> 1 Messenger-Instance (Matrix-Domain). Every Arztpraxis has to have its own Homeserver-Instance.
Because as mentioned here this could be a nightmare in terms of Scalability, Maintainability, Security and Ressources (and Price ;-) ) with 10000s of Synapses we started our own implementation of the components especially designed for having very many smaller homeservers deployed.
I can tell this is a nightmare too in the beginning as for some functionality the Matrix spec leaves options and one has to look how Synapse does it to be compatible but long-term it pays off.
In my opinion Synapse fits well to bigger organizations (clinics, insurance etc.) or for small single instances with an Administrator taking care. But as a Fachdienst for this amount of Praxen it's not really working well (maybe if you have an extraordinary amount of operating staff).
Also in points of maintenance you will need Python programmers. So when you don't want to have multilanguage maintenance teams you have to do all the rest also in Python which in my eyes is not the best choice in longterm for such background systems.

[nikzen]

Aus unserer Sicht ist eine Domain pro Organisation absolut notwendig. Matrix ist ein dezentrales Protokoll und Domains eignen sich optimal für die Identifikation von juristischen Personen (So funktioniert das Internet).

Neben einer Domain pro Organisation MUSS ein Matrix Homeserver die jeweiligen Organisationen im Backend logisch trennen. Wenn der Homeserver das nicht kann, dann MUSS man einen Matrix Homeserver pro Organisation nehmen und diese logisch trennen. Das kann man sehr gut betreiben und ist keine so große Herausforderung.

Wenn man nicht einen Matrix Homeserver pro Organisation betreiben möchte, dann MUSS man einen Matrix Homeserver nehmen der mandantenfähig ist und eine logische Trennung macht. Hier MUSS aus unserer Sicht der Nachweis erbracht werden, dass es hier auch wirklich zu einer logischen Trennung kommt.

Am Ende des Tages ist die Diskussion hier alleinig relevant für die Kostenseite bei den FD Anbietern.

PS: Bzgl der Diskussion um Python (Da Synapse vermutlich der Homeserver der Wahl ist). Als Anbieter ist man verpflichtet einen SDLC, SLA, etc. nachzuweisen. Das heißt wenn man ein Python Produkt betreibt, wo man nicht der PO ist, MUSS man entweder entsprechende Serviceverträge mit den Herstellern des Produktes eingehen, oder die eigenen Fähigkeiten aufbauen. Wie will man ansonsten denn sicherstellen, dass alles wie gewünscht läuft und Fehler entsprechend schnell gelöst werden.

[Johennes]

In der aktuellen Version der Spec können mehrere Messenger-Services innerhalb eines Fachdienstes betrieben werden (https://gemspec.gematik.de/docs/gemSpec/gemSpec_TI-M_Basis/latest/#2). Daher gehe ich davon aus, dass sich dieses Thema erledigt hat.

[benkuly]

@Johennes Nein das Thema ist nach wie vor offen.

Fachlich: Ein Krankenhaus kann z. B. mehrere SMC-B/BSNR/etc. haben und ist dadurch gezwungen, auch mehrere Domains mit mehreren Messenger-Services zu nutzen. Dadurch ist kein klassisches Inhouse-Messaging über TIM mehr möglich. Auch Verbände möchten ihren Mitgliedern ggf. einen TIM auf ihrer Domain anbieten. Auch das ist nach meinem Verständnis nicht wirklich möglich.

Technisch Der Homeserver Synapse, den nach meinem Kenntnisstand fast alle TIM-Mitbewerber nutzen, ist nicht Multi-Domain fähig. Dadurch ergibt sich der Bedarf, für jede winzige Organisation eigene Infrastruktur hochzufahren. Das skaliert aber ökonomisch überhaupt nicht, selbst wenn man davon ausgeht, dass alles in Containern läuft.

Klima Aufgrund der technischen Beschränkungen ergibt sich ein massiver unnötiger Ressourcenmehrverbrauch.

Ich kenne die Lösung nicht und habe sie mit euch (gematik) seit 3 Jahren regelmäßig mit immer wechselden Teammitgliedern diskutiert. Das Problem bleibt aber dennoch bestehen und ist meiner Meinung nach nicht zu unterschätzen, weil sich dadurch ergibt, ob ein Nutzer nun 10 Cent oder 10 Euro im Betrieb kostet.

[Johennes]

Sorry, ich glaube ich habe die Problematik bisher nicht richtig verstanden. Es scheint im Kern eigentlich gar nicht um Domains zu gehen sondern darum aus Wirtschaftlichkeitsgründen mehrere Organisationen auf demselben Messenger-Service (= Homeserver + Proxy) zu betreiben, richtig?

[benkuly]

Prinzipiell schon ja. Bedeutet aber auch, dass eine Domain von mehrere Organisationen verwendet werden kann. Quasi eine logische Trennung. Das ist auch ohne weiteres durch den Proxy möglich (PoC haben wir bereits schon vor 2,5 Jahren gezeigt). Dennoch habt ihr bisher bei der gematik dagegen argumentiert, da anderer Proxies in der Föderation diese Trennung nicht kennen und daher nicht die selbe Prüfung durchführen können, wir der logische-trennung-proxy.

[Johennes]

Ok, ich habe mir intern nochmal historischen Kontext zu diesem Thema geholt.

Dennoch habt ihr bisher bei der gematik dagegen argumentiert, da anderer Proxies in der Föderation diese Trennung nicht kennen und daher nicht die selbe Prüfung durchführen können, wir der logische-trennung-proxy.

Ich glaube das ist genau der Knackpunkt. Der ausgehende Proxy könnte die logische Trennung auflösen. Der eingehende allerdings nicht, so dass hier Proxy-Prüfungen wegfallen müssten.

Ich finde insgesamt ist es eine gute Idee aus Gründen der Wirtschaftlichkeit mehrere Organisationen auf einem Homeserver zu kombinieren. Der Gedanke dafür dieselbe Domain zu verwenden scheint aber Nachteile zu haben und rührt wahrscheinlich auch daher, dass Synapse momentan nicht multi-domain-fähig zu sein scheint. Anstatt die TIM-Spec an diese Feature-Lücke von Synapse anzupassen fände ich es daher besser darauf hinzuwirken, dass Synapse das fehlende Feature in Zukunft erhält.

[benkuly]

Ich denke vor allem die fachliche Probleme wie hier beschrieben sollten gelöst werden und das ist Stand jetzt mit mehreren Domains nicht möglich. Die einfachste Lösung wäre halt auf die doppelte Einladungs-Prüfung zu verzichten, wobei ich mich sogar gerade Frage, ob das mit der aktuellen Vorab-Spec überhaupt noch der Fall wäre.

[Johennes]

Die einfachste Lösung wäre halt auf die doppelte Einladungs-Prüfung zu verzichten, wobei ich mich sogar gerade Frage, ob das mit der aktuellen Vorab-Spec überhaupt noch der Fall wäre.

Hm, soweit ich sehe haben wir momentan folgende Einschränkungen an der CS-API:

• Einladungen nur für Nutzer von Homeservern aus der TI-Föderation (A_25532)
• Nur ePA: Keine Einladung von Versicherten (A_25705)

An der SS-API haben wir Invites nicht explizit eingeschränkt. Allerdings gibt es diese generischen Einschränkungen:

• Eingehend: Events nur von Homeservern aus der TI-Föderation (A_25533)
• Eingehend: Falls origin gesetzt ist, nur Werte von Homeservern aus der TI-Föderation (A_25540)
• Ausgehend: Falls destination gesetzt ist, nur Werte von Homeservern aus der TI-Föderation (A_25541)

Wenn jetzt jemand mehrere Organisationen hinter einer Domain betreibt, dann müsste doch jede Organisation einen Eintrag in die Föderationsliste einpflegen. Wenn es dort mehrere Einträge mit derselben Domain gibt, wäre es dann bei allen eingehenden Prüfungen aber unmöglich die Domain in die sendende Organisation aufzulösen. Im Extremfall könnte eine Organisation dann gar nicht mehr in der Föderationsliste stehe und trotzdem noch ander Föderation teilnehmen weil die eingehenden Prüfungen das gar nicht feststellen können.

[benkuly]

Stimmt, genau das war das Problem. Dennoch könnte dieses Verhalten ja durch entsprechende automatisierte Tests und ggf. sogar im Sicherheitsgutachten überprüft werden. Aber nach meinem letzten Stand ist die gematik nicht dazu bereit, diesen Kompromiss einzugehen und setzt weiterhin auf Multi-Domain (auch wenn dies verschiedene fachliche Anwendungsfälle komplett ausklammert).

[Johennes]

Aus SI-Sicht kann ich das als nicht-SI-Mensch leider nur teilweise bewerten. Wir würden hier allerdings eine harte Sicherheitsprüfung im Betrieb durch einen Zulassungstest und ein Gutachten ersetzen. Ein gewisser Abstrich scheint mir das schon zu sein.

Kannst du vielleicht nochmal die fachlichen Probleme erläutern, die du bei einem 1:1-Mapping von Organisationen und Domains siehst?

Fachlich: Ein Krankenhaus kann z. B. mehrere SMC-B/BSNR/etc. haben und ist dadurch gezwungen, auch mehrere Domains mit mehreren Messenger-Services zu nutzen. Dadurch ist kein klassisches Inhouse-Messaging über TIM mehr möglich. Auch Verbände möchten ihren Mitgliedern ggf. einen TIM auf ihrer Domain anbieten. Auch das ist nach meinem Verständnis nicht wirklich möglich.

Könnten mehrere Homeserver in einem Krankenhaus nicht einfach in-house föderieren? Spielst du darauf an, dass Dinge wie das User Directory hier nur lokal verfügbar wären?

Den Fall mit den Verbänden verstehe ich auch nicht ganz. Sorry, ist mit Sicherheit fehlendes Domainwissen (😜) auf meiner Seite.

[benkuly]

Könnten mehrere Homeserver in einem Krankenhaus nicht einfach in-house föderieren? Spielst du darauf an, dass Dinge wie das User Directory hier nur lokal verfügbar wären?

Ja, es gibt kein gemeinsames user directory. Außerdem springt aufgrund der Föderation die vom Nutzer hinterlegte Berechtigungsprüfung an. Mal davon abgesehen, dass sich ein Krankenhaus berechtigterweise fragen wird, warum er denn jetzt mehrere Fachdienste einkaufen und bezahlen muss.

Den Fall mit den Verbänden verstehe ich auch nicht ganz. Sorry, ist mit Sicherheit fehlendes Domainwissen (😜) auf meiner Seite.

Gespräche mit verschiedenen Verbänden hat ergeben, dass sie gerne ihren Mitgliedern einen oder mehrere TIM-Accounts anbieten wollen. Beispielsweise für Einzelpraxen. Nach meinem Verständnis ist das nicht möglich ohne Domain-Trennung.

Am Ende bedeutet es, dass für jede noch so kleine Organisation eine eigene Domain notwendig ist, was insgesamt auch Verwirrung stiften könnte, weil es dann massenweise Matrix-IDs nach folgendem Schema geben wird: @mueller:mueller.anbieter.xyz

[Johennes]

Ok danke, verstanden.

Mir ist mittlerweile noch von einem Mitlesenden ohne GitHub-Account folgendes zugetragen worden:

• Krankenhäuser mit mehreren Abteilungen / SMC-Bs könnten ihren TIM-Service auch nur an einer Abteilung für alle betreiben.
• Es gab wohl mal die Idee einer übergeordneten SMC-B, die mehrere SMC-Bs zusammenfasst. Wie dort der aktuelle Stand ist, ist mir allerdings nicht bekannt.

[Johennes]

Vielleicht könnten wir das Thema mal von einer anderen Seite her betrachten. Was müsste sich technisch ändern damit die Föderationsprüfung bei eingehender Kommunikation auch dann möglich ist wenn mehrere Organisationen hinter derselben Domain hängen?

Dass wir hier anstatt der aktuellen Proxyprüfung auf Tests oder Gutachten setzen kann ich mir momentan nur schwer vorstellen. Vielleicht gibt es aber Möglichkeiten diese Problem technisch zu lösen.

Wäre es z.B. möglich, dass Fachdienste bei Server-Server-Requests im Header zusätzlich zum Servernamen noch ein weiteres Feld senden, mit dem der empfangende Fachdienst die Organisation gegen die Föderationsliste verifizieren kann?

Für Prüfungen die den Servernamen aus der URL extrahieren würde das wahrscheinlich nicht funktionieren.

[Johennes]

Kurze Zusammenfassung von IRL Diskussionen mit verschiedenen Leuten:

• Die Erweiterung des Headers in Server-Server-Requests ist u.U. nicht trivial weil hierfür die eingebauten Signaturmechanismen von Matrix-Homeservern aufgebohrt werden müssen.
• Die Echtheit der existierenden origin und destination Attribute wird prinzipiell über DNS gewährleistet. Zusätzliche Attribute müssten aber separat verifiziert werden (z.B. über Signatur mit der SMC-B)
• Das VZD selbst verhindert Mehrfacheinträge zur selben Domain aktuell nicht