Integrationsarchitektur des Intercom-Service
Der Intercom-Service ist ein kleines, aber entscheidendes Bauteil der openEDU-Infrastruktur. Er ist ein proxys und Broker in der Browserebene, der die Kommunikation zwischen Anwendungen ermöglicht — Dateiauswahl, Erstellung von Videokonferenzräumen, silentes Single Sign-on zwischen Apps und Portal-Navigation. Indem er die OpenID-Connect-Sitzung der Nutzerin oder des Nutzers hält und sie über einen vertrauenswürdigen Vermittler für den Rest der Suite bereitstellt, lässt er einen Katalog getrennt betriebener Dienste wie einen zusammenhängenden Arbeitsbereich wirken.
Was der Intercom-Service ist
Der Intercom-Service ist ein schlanker Proxy, der im Browser-Kontext der Nutzerin oder des Nutzers läuft. Jede teilnehmende Anwendung bindet den Intercom-Service als iframe ein und kommuniziert über postMessage mit ihm. Da der iframe auf der Origin des Intercom-Service liegt, kann er Anmeldedaten und Sitzungszustände halten, die die einzelnen Anwendungen nicht direkt miteinander teilen können — der iframe handelt als vertrauenswürdiger Vermittler im Namen der Nutzerin oder des Nutzers.
Dieses Design hält den Intercom-Service bewusst schlank. Er speichert keine Anwendungsdaten; er vermittelt Navigation, Sitzung und Absichten zwischen Anwendungen, die sonst durch die Same-Origin-Policy des Browsers voneinander getrennt wären.
Bereitgestellte Funktionalitäten
Über die Suite hinweg stützen sich Anwendungen auf den Intercom-Service für gemeinsame Browser-Funktionen:
- Silentes Login — Weitergabe von OpenID-Connect-Tokens zwischen Anwendungen ohne für die Nutzerin sichtbaren erneuten Anmeldeschritt.
- Portal-Navigation — Abruf der zentralen Navigationsstruktur, sodass alle Anwendungen dasselbe Portalmenü anzeigen.
- Dateiauswahl — Öffnen einer Datei aus dem Dateiablage-Dienst der Suite in einer anderen Anwendung.
- Videokonferenzräume — Erstellen von Konferenzräumen aus einer kollaborierenden Anwendung heraus.
- Backchannel-Logout — Koordination der Sitzungsbeendigung über alle Anwendungen, sodass ein einzelnes Logout alle Sitzungen beendet.
Diese Funktionen sind der Klebstoff, der eine Plattform aus vielen Diensten wie eine integrierte Lösung statt einer Sammlung unzusammenhängender Websites wirken lässt.
Integration mit der Identitätsebene
Die Authentifizierung ist auf Keycloak zentralisiert, das als OpenID-Connect-Provider der Suite dient. Der Intercom-Service nimmt über einen eigenen OIDC-Client an diesem Realm teil, der auf die Claim-Namenskonvention der Plattform abgestimmt ist (der opendesk_username-Claim). Da der Intercom-Service die OIDC-Sitzung hält, kann er im Namen einer untergeordneten Anwendung ein silentes Login ausführen: Die Anwendung leitet zum Intercom-Service weiter, der Broker tauscht die gespeicherte Sitzung gegen Tokens, und die Anwendung fährt fort, ohne die Nutzerin oder den Nutzer zu einer Eingabe aufzufordern.
Standardmäßig wird der OIDC-Client über den Keycloak-Bootstrap-Prozess der Suite bereitgestellt, sodass seine Claims zentral und konsistent mit dem Rest der Plattform gesteuert werden. Das Backchannel-Logout wird über denselben OIDC-Flow koordiniert, sodass das Beenden einer Sitzung an einer Stelle auf alle Anwendungen übergeht, die sich auf den Broker stützen.
Was der Intercom-Service vermittelt
Der Intercom-Service wird mit der Menge vertrauenswürdiger Anwendungen konfiguriert, die er vermittelt, und die Suite aktiviert genau die Integrationen, die eine jeweilige Bereitstellung benötigt. In der openEDU-Plattform gehören dazu:
- Dateiablage — die Dateidienste Nextcloud und OpenCloud, die appübergreifende Dateiauswahl und silentes Zugreifen ermöglichen.
- Groupware — der Groupware-Backend OX App Suite, mit optionaler Unterstützung für den Grommunio-Stack, falls aktiviert.
- Wiki — der Dienst XWiki.
- Kommunikation — die Matrix-Bereitstellung (Synapse) für Messaging und Video, wobei der Intercom-Service für den Matrix-Server und seinen Application-Service-Hook konfiguriert ist.
Die Plattform behandelt die Backend-Liste des Brokers als opt-in: Eine Bereitstellung aktiviert die Integrationen, die sie tatsächlich betreibt, sodass der Intercom-Service stets die konkrete Dienstauswahl der Instanz widerspiegelt statt eines festen Katalogs. Das entspricht dem modularen Design der Plattform, bei dem jeder Dienst unabhängig aktiviert oder deaktiviert werden kann.
Wie Anwendungen den Broker nutzen
Anwendungen nehmen am Broker teil, indem sie den Intercom-Service-iframe einbetten und auf die Endpunkte des Brokers ausrichten. In der Praxis:
- Chat (Element) ist mit den Navigations- und Silent-Login-URLs des Intercom-Service konfiguriert, sodass der Messaging-Client das gemeinsame Portal rendert und sich gemeinsam mit der restlichen Suite silten anmeldet.
- Notes verwendet die Basis-URL des Brokers als Integrationsendpunkt für appübergreifende Sitzungs- und Navigationsfunktionen.
Das Muster ist konsistent: Eine Anwendung deklariert eine kleine Menge an Integrations-URLs, die auf den Intercom-Service zeigen, und der Broker übernimmt die gemeinsame Sitzungs- und Navigationsfragen in ihrem Namen. Keine Anwendung benötigt eine eigene Föderations- oder Sitzungslogik.
Bereitstellungsmuster
Der Intercom-Service läuft als Kubernetes-Workload, verwaltet über die Helm/helmfile-Konfiguration der Plattform, neben den übrigen Diensten der Suite:
- Er ist als Standard-Container-Image auf einer schlanken Alpine-Basis verpackt statt ein dienstspezifisches System-Image zu erfordern, sodass er ohne plattformspezifische Abhängigkeiten auf jedem Kubernetes-Cluster einsetzbar ist.
- Er läuft gehärtet — non-root, read-only-Wurzeldateisystem, abgelegte Linux-Capabilities und ein restriktives seccomp-Profil, konsistent mit dem Sicherheitsansatz der übrigen Suite.
- Er stellt einen Health-Endpunkt für Kubernetes-Liveness- und Readiness-Probes bereit.
- Sein Sitzungszustand liegt in der gemeinsamen Redis-basierten Cache-Ebene der Plattform.
- Er läuft hinter dem Ingress der Plattform, geschützt durch dieselbe TLS- und Ingress-Konfiguration wie jeder andere Dienst.
Da er Sitzungszustand hält und Tokens vermittelt, wird der Intercom-Service als sicherheitskritisches Bauteil behandelt: Er wird mit derselben Härtung und derselben Zertifikatsverwaltung bereitgestellt wie die identitätsbezogenen Dienste der Suite.
Bezug zum Upstream
Der Intercom-Service wird upstream vom openEDU-CE-Projekt gepflegt und für die Unified Collaboration Environment verpackt. openEDU setzt denselben Intercom-Service ein und konfiguriert ihn für die Claim-Namenskonvention und Backend-Auswahl der Bildungsplattform. Die Erweiterung des Brokers für den Bildungs-Stack durch die Plattform — Hinzufügen der Dateiablageunterstützung über die Community-Edition hinaus sowie Konfiguration der Groupware-, Wiki- und Kommunikations-Backends für die jeweilige Bereitstellung — ist im Community-Beitrag Den Intercom-Service erweitern dokumentiert.
Weiterführende Informationen
- Systemarchitektur-Überblick — die gesamte Plattformarchitektur
- Identitäts- und Authentifizierungsarchitektur — wie OIDC- und SAML-Föderation behandelt werden
- Sicherheitsarchitektur — wie Sitzungs- und Identitätsdaten geschützt werden
- Den Intercom-Service erweitern — der Community-Beitrag zu vermittelten Integrationen und Governance
Der Intercom-Service ist das, was aus einem Katalog unabhängig betriebener Dienste einen gemeinsamen Arbeitsbereich macht — ein kleiner Broker, der einen großen Teil der Integrationslast der Plattform trägt.
