openDesk und die IAM-Frage: Wie Nubus von Univention das Single Sign-On liefert – und wie sich das Ganze auch mit Docker und Portainer betreiben lässt

openDesk ist der digitale Arbeitsplatz, den das Zentrum für Digitale Souveränität in der öffentlichen Verwaltung (ZenDiS) im Auftrag des Bundes entwickeln lässt – eine quelloffene Alternative zu Microsoft 365, zusammengesetzt aus neun eigenständigen Open-Source-Projekten: Nextcloud für Dateien, Collabora Online für Office-Dokumente, die OX App Suite für Mail, Kalender und Kontakte, Element auf Matrix für Chat, OpenProject für Projektmanagement, XWiki mit CryptPad für Wissensmanagement, NeoToolsuite für Videokonferenzen, eine Notes-App – und Nubus von Univention für die Identitäten.

Neun unabhängige Projekte mit eigenen Releasezyklen, eigenen Sicherheitsmeldungen und eigenen Update-Pfaden unter einer gemeinsamen Oberfläche zu vereinen, ist die eigentliche Integrationsleistung von openDesk. Damit das für Nutzerinnen und Nutzer trotzdem wie ein Arbeitsplatz wirkt, statt wie neun separate Logins, braucht es eine Klammer: Single Sign-on. Und Single Sign-on braucht ein sauberes Identity and Access Management im Hintergrund. Genau diese Rolle übernimmt Nubus.

Warum SSO für openDesk kein Nice-to-have ist

Ohne zentrales SSO müsste sich jede Nutzerin für Nextcloud, für OpenProject, für Element und für jede weitere Anwendung separat anmelden – mit potenziell unterschiedlichen Passwörtern, unterschiedlichen Rechten und unterschiedlichen Sicherheitsniveaus. Das widerspricht nicht nur der Idee eines einheitlichen Arbeitsplatzes, es ist auch aus Sicherheitssicht ein Problem: mehr Passwörter bedeuten mehr Angriffsfläche, mehr Supportaufwand und eine geringere Übersicht darüber, wer eigentlich worauf Zugriff hat.

Deshalb ist die IAM-Schicht bei openDesk kein optionales Zusatzmodul, sondern das Rückgrat der gesamten Suite. Sie entscheidet, wer sich anmelden darf, welche Rollen und Rechte jemand in welcher Anwendung hat, und sie ist die Stelle, an der Themen wie Zwei-Faktor-Authentifizierung oder die Anbindung an ein bestehendes Verzeichnis wie Active Directory oder LDAP verankert werden.

Nubus: die IAM-Schicht hinter openDesk

Nubus stammt vom Bremer Unternehmen Univention und baut auf dem langjährigen Univention Management Stack auf, den viele aus dem Univention Corporate Server kennen. Für openDesk wurde daraus eine eigenständige, für Kubernetes konzipierte Komponente.

Fachlich übernimmt Nubus mehrere Aufgaben gleichzeitig:

• Verzeichnisdienst und Identity Store – ein vorkonfiguriertes OpenLDAP, das Nutzer, Gruppen und weitere Objekte verwaltet und sich alternativ auch an ein bestehendes Active Directory oder LDAP anbinden lässt, statt ein eigenes Verzeichnis zu führen.
• Keycloak als Identity Provider – im Hintergrund läuft Keycloak, der eigentliche Motor für SSO über offene Standards wie OpenID Connect und SAML. Dadurch lässt sich Nubus sowohl als Identity Provider für openDesk als auch als Anbindung an externe Identity Provider nutzen.
• Univention Portal – die zentrale Startseite, über die Nutzerinnen und Nutzer nach einer einmaligen Anmeldung auf alle freigeschalteten Module zugreifen.
• Guardian – die Autorisierungskomponente für rollenbasierte Zugriffskontrolle (RBAC) über die einzelnen Fachanwendungen hinweg.
• Provisioning-Dienste – sorgen dafür, dass Änderungen an Nutzern und Gruppen automatisch an die angebundenen Anwendungen weitergereicht werden, technisch umgesetzt über eine Nachrichtenwarteschlange.

Univention hat außerdem gemeinsam mit der französischen Verwaltungsbehörde DINUM im Rahmen einer Kooperation die Anbindung externer Identity Provider ausgebaut – in beide Richtungen: openDesk als Identity Provider für andere Systeme oder ein externer Identity Provider als Quelle für openDesk. Für Organisationen, die bereits ein bestehendes IAM betreiben, ist das ein wichtiger Baustein, um openDesk nicht als isolierte Insellösung, sondern als integrierten Teil der vorhandenen Infrastruktur zu betreiben.

Die Betriebsrealität: Nubus ist Kubernetes-nativ

Wer Nubus in Betrieb nehmen will, sollte einen Punkt von Anfang an einplanen: Nubus ist konsequent für Kubernetes konzipiert und wird über Helm Charts ausgerollt. Es gibt keine offizielle, unterstützte Variante, die Komponente einfach per docker compose up zu starten. Die Container-Images existieren, aber ihr Zusammenspiel – Ingress, Zertifikate, Datenbanken, Objektspeicher, Nachrichtenwarteschlange – ist auf Kubernetes-Ressourcen wie Deployments, Services, Secrets und Ingress-Objekte ausgelegt.

Bevor man ein Docker/Portainer-Konzept aufsetzt, lohnt sich deshalb ein ehrlicher Blick auf die Komponenten, die im Hintergrund mitlaufen: ein S3-kompatibler Objektspeicher (MinIO), eine PostgreSQL-Datenbank für mehrere Dienste, ein Message-Queue-System (NATS) für die Provisionierung sowie Keycloak und die Portal- und Verwaltungskomponenten selbst. Das ist kein Ein-Container-Deployment, sondern ein kleines verteiltes System.

Konzeptskizze: openDesk und Nubus mit Docker und Portainer betreiben

Für ein Testsystem, eine Schulungsumgebung oder einen kleinen, ressourcenschonenden Produktivbetrieb lässt sich dennoch ein Konzept aufbauen, das auf vorhandener Docker- und Portainer-Infrastruktur aufsetzt – indem man Kubernetes selbst in Docker betreibt, statt Nubus gegen seine Architektur zu betreiben.

1. Fundament: ein leichtgewichtiger Kubernetes-Cluster in Docker

Auf dem Docker-Host kommt eine schlanke Kubernetes-Distribution zum Einsatz, die sich vollständig containerisiert betreiben lässt, etwa k3s beziehungsweise dessen Docker-Variante k3d, oder alternativ kind. Beide starten einen vollwertigen Kubernetes-Cluster als Docker-Container beziehungsweise Container-Verbund auf dem bestehenden Host. Für den produktiven Einsatz sollte dieser Cluster über mehrere Nodes verteilt werden; für Test- und Schulungszwecke reicht ein Single-Node-Setup.

2. Ingress und Zertifikate

Innerhalb dieses Clusters wird ein Ingress-NGINX-Controller installiert, den Univention als einzigen unterstützten Ingress-Controller für Nubus benennt, ergänzt um einen Zertifikatsmanager für TLS. Beide laufen als reguläre Pods im Cluster – nicht als eigenständige Docker-Container auf dem Host.

3. Nubus per Helm Chart deployen

Nubus selbst wird über den offiziellen Helm Chart in diesen Cluster ausgerollt, inklusive der mitgelieferten Standardkomponenten für Objektspeicher, Datenbank und Nachrichtenwarteschlange – oder, für einen schlankeren Aufbau, unter Anbindung bereits vorhandener PostgreSQL- und MinIO-Instanzen, die dann außerhalb des Clusters, etwa als klassische Docker-Container, weiterlaufen können.

4. Portainer als Verwaltungsebene

Hier kommt Portainer ins Spiel: Portainer verwaltet nicht nur klassische Docker-Umgebungen, sondern lässt sich auch an einen Kubernetes-Cluster als eigenes Environment anbinden. Der lokal in Docker laufende k3s-Cluster wird in Portainer registriert und ist damit über dieselbe Oberfläche sichtbar und steuerbar wie die übrigen Docker-Hosts – inklusive Deployments, Pods, Logs und Ressourcenübersicht. Für Organisationen, die Portainer bereits als zentrale Konsole für ihre Container-Landschaft nutzen, entsteht so ein einheitlicher Blick auf klassische Docker-Dienste und die Kubernetes-basierte IAM-Schicht, ohne für Nubus ein separates Werkzeug einführen zu müssen.

5. Anbindung der openDesk-Fachanwendungen

Die übrigen openDesk-Bausteine wie Nextcloud, Collabora oder OpenProject können, je nach gewünschtem Integrationsgrad, entweder klassisch als Docker-Container auf demselben Host laufen und sich per OpenID Connect gegen den in Nubus enthaltenen Keycloak authentifizieren, oder ebenfalls in den Kubernetes-Cluster wandern. Entscheidend ist an dieser Stelle nur, dass sie den von Nubus bereitgestellten Identity Provider ansprechen können – das Netzwerk- und Zertifikatskonzept muss also Docker-Container und Kubernetes-Pods gemeinsam denken.

Einordnung: Für wen sich das eignet

Ein solches Setup ist eine pragmatische Brücke zwischen einer vorhandenen Docker/Portainer-Landschaft und den tatsächlichen Anforderungen von Nubus – gut geeignet für Proof-of-Concepts, interne Testumgebungen oder kleinere Instanzen, bei denen der Aufbau eines vollständigen, mehrknotigen Kubernetes-Clusters unverhältnismäßig wäre. Für den produktiven Betrieb einer größeren Organisation bleibt ein „echter“, redundant ausgelegter Kubernetes-Cluster mit dedizierten Nodes für Datenbank, Objektspeicher und die IAM-Komponenten selbst die von Univention empfohlene und robustere Variante – gerade weil Nubus mit Keycloak, Verzeichnisdienst und Provisionierung die sicherheitskritischste Komponente der gesamten openDesk-Suite ist.

Übergangsphase: Anbindung des bestehenden AD/LDAP statt Umstellung auf einen Schlag

Gerade Behörden und Unternehmen, die bereits ein etabliertes Active Directory oder LDAP betreiben, müssen bei der Einführung von openDesk nicht sofort auf ein eigenständiges Verzeichnis in Nubus umsteigen. Da Nubus offene Schnittstellen für die Anbindung bestehender Verzeichnisdienste mitbringt, lässt sich das vorhandene AD oder LDAP zunächst als führende Identitätsquelle weiterbetreiben, während Nubus als IAM- und SSO-Schicht darüber gelegt wird.

Für die Praxis ergibt sich daraus ein stufenweises Migrationskonzept: In einer ersten Phase übernimmt Nubus lediglich die Synchronisation und Authentifizierung gegen das bestehende Verzeichnis, sodass sich Nutzerinnen und Nutzer mit ihren gewohnten Zugangsdaten per SSO an openDesk anmelden können, ohne dass Konten doppelt gepflegt werden müssten. Erst in einer zweiten Phase – wenn Prozesse, Rollen und Berechtigungen erprobt sind – kann bei Bedarf schrittweise auf das in Nubus integrierte Verzeichnis umgezogen werden, etwa organisationsweise oder nach Fachbereichen gestaffelt. So lässt sich das Risiko eines „Big-Bang“-Wechsels vermeiden und die Einführung von openDesk von der eigentlichen Verzeichnismigration entkoppeln.

Wie die Anbindung auf App-Ebene funktioniert

Nextcloud, OpenProject, Element und die übrigen openDesk-Module bringen jeweils ein eigenes OpenID-Connect-Plugin mit, statt Benutzerkonten selbst zu verwalten. Jedes dieser Plugins wird einmalig gegen den in Nubus laufenden Keycloak konfiguriert – mit Client-ID, Redirect-URL und den Rollen- beziehungsweise Gruppenattributen, die aus dem Token gelesen werden. Die eigentliche Authentifizierung läuft damit ausschließlich über Nubus; die einzelnen Anwendungen prüfen nur noch, ob ein gültiges Token vorliegt und welche Rolle darin steht.

Für die Übergangsphase bedeutet das: Das AD/LDAP bleibt unverändert die Quelle der Wahrheit für Benutzer und Gruppen, Nubus synchronisiert beziehungsweise bindet sich dagegen, und die App-Plugins bemerken von der schrittweisen Migration im Hintergrund nichts – sie sprechen ohnehin nur mit Nubus, nicht mit dem Verzeichnis selbst. Das entkoppelt die einmalige Einrichtung der App-seitigen Authentifizierung von der Frage, woher die Identitäten gerade kommen.

Fazit

openDesk steht und fällt mit einer sauberen IAM- und SSO-Schicht, und Nubus liefert diese Schicht als eigenständiges, für Kubernetes gebautes Produkt mit Keycloak, Verzeichnisdienst, Portal und Autorisierungslogik im Kern. Wer bereits mit Docker und Portainer arbeitet, muss darauf nicht verzichten – mit einem in Docker betriebenen Kubernetes-Cluster und Portainers Kubernetes-Anbindung lässt sich Nubus in die vorhandene Infrastruktur integrieren, ohne die eigentliche, von Univention unterstützte Architektur zu verlassen. Für den produktiven Einsatz in größerem Maßstab bleibt ein dediziertes Kubernetes-Setup jedoch die verlässlichere Wahl.