Souveräne IT mit Open Source: So gelingt der eigene modulare Anwendungs-Stack
Digitale Souveränität ist mehr als ein Internet-Hype oder ein Marketingslogan. Digitale Souveränität entscheidet darüber, ob Organisationen ihre Prozesse selbst gestalten können – oder ob sie von Herstellern, Lizenzmodellen und proprietären Schnittstellen abhängig bleiben. Die gute Nachricht: Wer auf offene Standards und Open Source setzt, kann eine Vielzahl von IT-Diensten nahtlos technisch integrieren – vom Fileserver bis zur Fachanwendung – und so einen auf die eigenen Bedürfnisse optimierten Software Stack Schritt für Schritt aufbauen, von dessen Modularität profitieren und sich von den Diensten der Hyperscaler unabhängig machen.
Damit Applikationen und Dienste reibungslos zusammenspielen, braucht es ein verbindendes Element: ein Identity & Access Management (IAM), das die Integration und Steuerung von Nutzenden, Rollen und Rechten übernimmt – und dabei alle Anwendungen sicher miteinander verknüpft und einen anwendungsübergreifenden Datenfluss ermöglicht. Ein solches IAM verwaltet die Benutzeridentitäten, regelt die Zugriffsberechtigungen und ermöglicht die Automatisierung ganzer Prozessketten. Kurzum: Ohne IAM kein Anwendungs-Stack – zumindest keiner, der langfristig kontrollierbar bleibt.
Ich möchte Ihnen im Folgenden zentrale Bausteine für eine technisch solide Umsetzung eines offenen IAM vorstellen und zeigen, welche Standards sich bewährt haben und welche Architekturentscheidungen den Unterschied machen. Von Single Sign-on mit OpenID Connect oder SAML Single Logout mit Frontend Logout oder Backchannel Logout, User Lifecycle mit SCIM Management, eine Single Source of Truth für Rollen und kontextuelle Steuerung der Rechtevergabe für diese, Automatisierung und Deployment mit Kubernetes & Helm bis Provisionierung.
- IAM als Fundament eines souveränen Anwendungs-Stacks
- Baustein 1: Single Sign-on und Single Logout
- Baustein 2: User Lifecycle Management
- Baustein 3: Berechtigungen und Rollen
- Automatisierung und Deployment mit Kubernetes & Helm
- Bestehende Systeme sicher integrieren
- Open Source in der Praxis: Beispiele für souveräne IT
- Fazit: IAM als Schlüssel zur digitalen Souveränität
IAM als Fundament eines souveränen Anwendungs-Stacks
Wer einen Anwendungs-Stack selbst betreiben will, braucht mehr als Container, Rechenressourcen und einen bunten Mix aus (Open-Source-)Komponenten. Die Herausforderung liegt in einer durchdachten Architektur: Wie greifen alle Dienste sauber ineinander – und wie bleibt der Überblick über Zugriffe, Rollen und Datenflüsse erhalten?
Genau hier kommt das Identity & Access Management (IAM) ins Spiel. Denn so vielseitig moderne Anwendungen auch sind – ohne zentrales Identitäts- und Berechtigungsmanagement entstehen Schattenidentitäten, fragmentierte Rollen und Sicherheitslücken. Wer kein übergreifendes IAM hat, steht früher oder später vor denselben Problemen wie bei klassischen Insellösungen: Anmeldedaten wandern per E-Mail durchs Haus, ehemalige Mitarbeitende behalten ungewollt Zugriff auf sensible Daten, und überhaupt weiß niemand so genau, wer eigentlich welche Rechte hat. Ein offenes IAM löst diese Probleme auf Basis etablierter Protokolle und Schnittstellen.
Ein solides Fundament allein macht aber noch kein sicheres Haus. Es braucht auch die passenden Bausteine – angefangen bei der Authentifizierung.
Baustein 1: Single Sign-on und Single Logout
Ein moderner Anwendungs-Stack umfasst häufig Dienste wie Dateiablage, Webmailer, Videokonferenzen, Office- und Projektmanagement-Software oder branchenspezifische Fachverfahren. Damit die Anmeldung bei den verschiedenen Applikationen für Nutzer*innen nicht immer komplexer und zeitaufwändiger wird, braucht es ein zentrales Verfahren zur Authentifizierung: Single Sign-on (SSO).
Mit SSO melden sich Nutzer*innen einmalig am System an und erhalten Zugriff auf alle angeschlossenen Dienste. Die Anmeldung wird über Protokolle wie OpenID Connect (OIDC) oder SAML abgewickelt. Beide sind als offene Standards weit verbreitet und werden von fast allen modernen Webanwendungen unterstützt.
So bequem SSO ist – es löst nur die halbe Aufgabe. Denn während der Login häufig problemlos klappt, bleibt der Logout oft auf der Strecke. Single Logout (SLO) bedeutet, dass mit einer einzigen Abmeldung auch alle Sitzungen in den verbundenen Diensten geschlossen werden. In der Praxis wird dieser Schritt jedoch häufig vergessen – mit Folgen für Sicherheit und Datenschutz. Eine Abmeldung im E-Mail-Client beendet nicht automatisch die Sitzung im Videokonferenzdienst, der Dateiablage oder der Projektplattform – ein Einfallstor für Missbrauch.
Abhängig vom verwendeten Protokoll gibt es unterschiedliche Verfahren für Single Logout – etwa den Frontend Logout, bei dem der Browser alle Sitzungen aktiv beendet, oder den Backchannel Logout, bei dem das IAM direkt mit den angebundenen Diensten kommuniziert. Welcher Weg möglich ist, hängt von den Möglichkeiten der jeweiligen Anwendung ab – und von der Sorgfalt bei deren technischer Integration.
Die Realität zeigt: Während SSO schnell als Erfolg verbucht wird, ist SLO die eigentliche Herausforderung. Ein fehlender Logout-Mechanismus mag harmlos erscheinen, kann aber zum Sicherheitsrisiko werden – gerade bei sensitiven Daten oder öffentlich zugänglichen Arbeitsplätzen.
Baustein 2: User Lifecycle Management
Single Sign-on ermöglicht den komfortablen Zugriff auf die IT-Dienste, aber was passiert davor und danach? Wer Benutzerkonten wirklich sauber verwalten will, muss den gesamten Lebenszyklus der Identitäten im Blick behalten: vom Anlegen neuer Benutzer oder Gruppen über Änderungen bis hin zum Löschen. Genau darum geht es beim User Lifecycle Management.
Viele Systeme setzen allein auf Login Event: Ein Konto wird automatisch erstellt, sobald sich jemand zum ersten Mal anmeldet. Für einfache Szenarien mag das reichen – doch für eine kontrollierte, nachvollziehbare IT-Verwaltung ist dieses Modell zu kurz gedacht. Denn: Was passiert, wenn sich jemand nie einloggt? Oder wenn eine Person die Organisation verlässt?
Ohne zentrale Ereignissteuerung entstehen schnell Schattenidentitäten – Konten, die im System existieren, aber keiner nachvollziehbaren Person mehr zugeordnet sind. Auch Rechte und Gruppenmitgliedschaften lassen sich in solchen Setups nur schwer synchron halten. Der Verlust des Überblicks ist nicht nur ein organisatorisches Problem, sondern auch ein Datenschutz- und Sicherheitsproblem.
Für die technische Umsetzung gibt es verschiedene Ansätze:
Über APIs – ob offen oder proprietär – lassen sich Daten oft direkt in Zielsysteme schreiben. Das bietet Flexibilität, ist aber in der Regel mit hohem Integrationsaufwand und geringer Wiederverwendbarkeit verbunden.
Ein Verzeichnisdienst (z. B. auf LDAP-Basis) kann als gemeinsame Quelle für Benutzer- und Gruppendaten dienen, funktioniert aber meist nur bei Systemen, die aktiv darauf zugreifen können.
System for Cross-domain Identity Management (SCIM) ist ein offener Standard zur Provisionierung von Identitätsdaten. Er erlaubt es, Ereignisse wie Kontoanlage, Namensänderung oder Löschung standardisiert und automatisiert zwischen Systemen zu übertragen – inklusive Gruppen und Berechtigungen.
Ein durchgängiges User Lifecycle Management mit SCIM oder einem vergleichbaren Mechanismus ist nicht nur komfortabler, sondern auch sicherer. Es verhindert Datenleichen, reduziert Fehlerquellen und ermöglicht es, Identitäten über Systemgrenzen hinweg konsistent zu verwalten – egal, wie groß oder heterogen der eigene Stack ist.
Baustein 3: Berechtigungen und Rollen
Zugang allein genügt nicht – genauso wichtig ist die Frage: Was darf ein Benutzer innerhalb einer Anwendung eigentlich tun? Wer ein offenes IAM betreibt, muss nicht nur Identitäten verwalten, sondern auch Rechte differenziert vergeben und kontrollieren. Dazu müssen Gruppen, Rollen und Berechtigungen so abgebildet werden, dass sie automatisiert in verschiedene Anwendungen übertragen werden können. Viele IAM-Systeme setzen dafür auf Rollenmodelle, die bestimmten Benutzergruppen bestimmte Rechte zuweisen – etwa ”Lehrkraft“, ”Mitarbeitende“,”Projektverantwortliche“ oder ”Admin“.
Technisch gibt es dafür zwei gängige Wege:
OIDC erlaubt es, Rollen und Berechtigungen in sogenannten Claims mitzugeben. Diese enthalten Informationen wie Gruppen, Rollenbezeichnungen oder Attribute – etwa role=project-admin. Das funktioniert gut, setzt aber voraus, dass sich IAM und Anwendung darauf einigen, welche Begriffe welche Bedeutung haben. Standardisiert ist das nicht.
SCIM geht einen Schritt weiter: Der Standard definiert explizit, wie Entitlements und Roles provisioniert werden können. Das heißt: Gruppenmitgliedschaften und Rechte können direkt mit übertragen und systemübergreifend konsistent gehalten werden – vorausgesetzt, die Zielanwendung unterstützt SCIM vollständig. Wie bei OIDC gilt auch hier: IAM und Anwendung müssen sich über die Bedeutung eines Entitlements einig sein.
In der Realität stößt man hier jedoch schnell an Grenzen. Viele Anwendungen interpretieren Claims unterschiedlich oder ignorieren Entitlements vollständig. Wer auf Nummer sicher gehen will, braucht deshalb eine klare Architekturentscheidung: Es muss eine führende Instanz geben, in der Benutzer, Rollen und Berechtigungen verwaltet werden – eine Single Source of Truth. Ein IAM erfüllt diese Rolle idealerweise: Es speichert die Rechtevergabe zentral, synchronisiert sie mit anderen Systemen und bleibt dabei unabhängig von konkreten Anwendungen.
Neben der statischen Rechtevergabe nach Rollen gewinnt die kontextuelle Steuerung an Bedeutung: Wer, wann, wo, mit welchem Gerät worauf zugreifen darf – diese Bedingungen lassen sich über moderne IAM-Systeme granular abbilden. So entsteht ein Rechtemodell, das nicht nur differenziert, sondern auch flexibel genug für hybride Szenarien bleibt.
Automatisierung und Deployment mit Kubernetes & Helm
Wer offene Komponenten wie IAM, Verzeichnisdienste, Office-Anwendungen oder Dateiablagen zuverlässig betreiben will, braucht eine Plattform, die wiederholbare Deployments, Updates und Integrationen ermöglicht – auch im laufenden Betrieb.
Kubernetes hat sich in vielen Organisationen als Standard etabliert, um containerisierte Anwendungen skalierbar und resilient zu betreiben. In Kombination mit dem Paketmanager Helm lassen sich komplexe Setups wie ein IAM samt zugehöriger Dienste deklarativ beschreiben, automatisiert installieren und bei Bedarf reproduzieren – etwa in Test-, Integrations- und Produktivumgebungen.
Gerade in selbst aufgebauten Anwendungs-Stacks ist das essenziell: Ohne automatisiertes Deployment werden Releases schnell unübersichtlich, Konfigurationen inkonsistent und Erweiterungen riskant. Kubernetes und Helm schaffen hier Struktur und machen es einfacher, auch das IAM modular zu betreiben, regelmäßig zu aktualisieren und nachvollziehbar zu integrieren. Voraussetzung für diese Wiederholbarkeit ist ein konsequenter Continuous-Delivery-Ansatz. Nur wenn Builds, Tests und Deployments standardisiert und automatisiert ablaufen, lässt sich die Qualität des Gesamtsystems zuverlässig sichern – auch über viele Komponenten hinweg.
Bestehende Systeme sicher integrieren
In vielen Organisationen existieren bereits gewachsene Infrastrukturen – etwa ein zentrales Active Directory zur Benutzerverwaltung. Wer digitale Souveränität erreichen will, muss nicht bei null anfangen, sondern kann vorhandene Systeme klug einbinden.
Gerade bei der Einführung eines offenen IAM ist es oft sinnvoll, zunächst bestehende Verzeichnisse einzubeziehen und aus ihnen Identitätsdaten zu übernehmen oder synchron zu halten. In hybriden Szenarien kann das neue IAM direkt zum führenden System werden oder parallel zum bestehenden Verzeichnis arbeiten und dieses perspektivisch Schritt für Schritt ablösen.
Technisch stehen dafür verschiedene Wege offen: Manuelle Exporte lassen sich schnell umsetzen, sind aber fehleranfällig und nicht nachhaltig. Besser sind Anbindungen per LDAP, SCIM oder API, bei denen automatisiert Änderungen an Benutzerdaten abgerufen oder ereignisbasiert übertragen werden. Entscheidend ist, dass Prozesse wie Onboarding, Rollenvergabe und Offboarding nahtlos funktionieren – unabhängig davon, wo die Daten ursprünglich gepflegt wurden.
In der Praxis ist ein schrittweiser Übergang oft sinnvoll: Vorhandene Systeme bleiben zunächst bestehen, während neue Komponenten standardkonform angebunden und getestet werden können. So lässt sich der Wechsel kontrolliert gestalten – ohne Funktionseinbußen, aber mit wachsendem Zugewinn an Kontrolle.
Open Source in der Praxis: Beispiele für souveräne IT
Ein modularer Anwendungs-Stack besteht aus mehr als den einzelnen Diensten – entscheidend ist ihr Zusammenspiel. Erst wenn Identitäten, Rollen, Anwendungen und Datenflüsse über offene Standards integriert werden, entsteht eine Architektur, die unabhängig betreibbar, anpassbar und langfristig tragfähig ist. Dass dieser Anspruch auch in sehr großen Umgebungen praktikabel umsetzbar ist, zeigt das vom Zentrum für Digitale Souveränität (ZenDiS) vorangetriebene Projekt openDesk.
openDesk setzt auf eine Kombination bewährter Open-Source-Komponenten: Open-Xchange für E-Mail und Kalender, Nextcloud für Dateien, Collabora für die Online-Bearbeitung von Dokumenten,Element für Messaging, OpenProject für Projektmanagement – und das IAM Nubus von Univention, das als zentrales Bindeglied das technische Zusammenspiel der Komponenten ermöglicht und den komfortablen Zugriff auf alle Dienste über ein modernes Portal gewährleistet. Der modulare Aufbau funktioniert – unter anderem beim Robert Koch-Institut und in der Bundestagsverwaltung.
Nubus zeigt, welche wichtige Rolle ein offenes IAM in dieser Architektur spielen kann: Es verwaltet nicht nur Identitäten, sondern übernimmt die zentrale Steuerung von Zugriffsrechten und stellt diese Informationen über offene Schnittstellen bereit. Ein Beispiel dafür ist das ambitionierte Open-Source-Projekt des Landes Schleswig-Holstein, das mit Nubus momentan einen neuen landesweiten Verzeichnisdienst aufbaut. Dieser löst perspektivisch die bisherige Active-Directory-Umgebung ab und ermöglicht den sicheren Zugriff auf Fachanwendungen, Endgeräte und zentrale IT-Systeme – rollenbasiert, datenschutzkonform und vollständig unter eigener Kontrolle.
Zum Einstieg in eine souveräne Cloud-Infrastruktur mit Nubus als IAM helfen fertig konfigurierte Integrationen. So ermöglicht z.B. die Active-Directory-Verbindung, ein offenes IAM mit einem bestehenden AD zu synchronisieren – inklusive Konten, Gruppen und Passwörtern. Auch gibt es fertige Integrationspakete für komplette Anwendungen, wie z.B. Nextcloud oder Open-Xchange, die die Anbindung von Drittsoftware an Nubus besonders einfach gestalten. Weitere Pakete werden zur Zeit entwickelt und sukzessive veröffentlicht. Zudem unterstützen Connectoren zu Google Workspace, Apple School Manager oder Microsoft 365 beim Single Sign-on an diesen Cloud-Diensten. Diese Tools erleichtern den sanften Umstieg auf offene, kontrollierbare Architekturen – ohne sofort alles ersetzen zu müssen.
Die Projekte zeigen: Digitale Souveränität ist keine abstrakte Zielmarke, sondern lässt sich mit Open Source konkret umsetzen – schrittweise, nachvollziehbar und nachhaltig.
Fazit: IAM als Schlüssel zur digitalen Souveränität
Digitale Souveränität entsteht nicht durch das Label eines Produkts, sondern durch eine Architektur, die offen, steuerbar und anpassbar bleibt. Wer IT-Dienste selbst betreiben oder in bestehende Strukturen integrieren möchte, braucht ein IAM, das mitwächst – von der Authentifizierung über Rollen und Berechtigungen bis zur vollständigen Automatisierung.
Viele Organisationen bauen sich aus LDAP, Skripten und Datenbankabgleichen ein eigenes IAM-System zusammen – in der Hoffnung auf maximale Flexibilität. Doch solche Eigenkonstruktionen stoßen schnell an Grenzen: fehlende Protokollierung, mangelhafte Skalierung, Sicherheitsrisiken. Wer stattdessen auf ein etabliertes Open Source IAM setzt, profitiert von getesteten Standards, Community Support und Erweiterbarkeit – ohne technische Schulden.
Ein souveräner IT Stack braucht mehr als Container und Dienste. Erst mit einem zentralen IAM lassen sich Identitäten, Rollen und Zugriffsrechte verlässlich verwalten – über alle Applikationen hinweg. Es ist das verbindende Element, das aus Einzelteilen ein funktionierendes Ganzes macht: interoperabel, kontrollierbar und langfristig tragfähig.
