Keycloak im Unternehmen: Single Sign-On und IAM selbst betreiben

Identity- und Access-Management ist eine der wenigen Komponenten, die jedes Unternehmen braucht, aber keines wirklich besitzen will. Managed-Anbieter rechnen pro Nutzer ab, und bei zehntausend Identitäten wird das schnell zu einem festen Posten in der Bilanz. Keycloak verspricht denselben Funktionsumfang ohne diese Lizenz, verlagert dafür aber die Verantwortung zu Ihnen. Dieser Artikel klärt, wann sich selbst betriebenes IAM mit Keycloak lohnt und wann der Managed-Weg die ehrlichere Wahl ist.

Was Keycloak tatsächlich leistet

Keycloak ist ein Open-Source-Identity-Provider, der die relevanten Standards des Identity- und Access-Managements vollständig abdeckt. Es spricht OpenID Connect (OIDC) und OAuth 2.0 für moderne Anwendungen und APIs, und es spricht SAML 2.0 für die ältere, aber im Enterprise-Umfeld noch sehr präsente Welt aus On-Premise-Software und etablierten Dienstleisterportalen.

Daraus ergibt sich der erste konkrete Nutzen: Single Sign-On über heterogene Anwendungslandschaften hinweg. Ein Nutzer authentifiziert sich einmal, und Webanwendungen, interne Tools und Drittsysteme akzeptieren dieselbe Session, ob sie nun OIDC oder SAML sprechen. Keycloak vermittelt zwischen den Protokollen, statt dass jede Anwendung ihre eigene Anmeldung pflegt.

Der zweite Nutzen ist Föderation und Identity Brokering. Keycloak kann sich als Vermittler vor bestehende Identitätsquellen schalten: Es bindet ein Active Directory oder einen LDAP-Verzeichnisdienst als User Federation an, und es delegiert die Anmeldung an externe Identity-Provider (etwa einen Behörden-Login, ein Partnerunternehmen oder Microsoft Entra ID), ohne dass die nachgelagerten Anwendungen davon etwas merken. Für B2B-Szenarien mit vielen externen Organisationen ist das ein zentrales Argument.

Das alles gibt es ohne Lizenz pro Nutzer. Genau hier liegt die wirtschaftliche Attraktivität, und genau hier beginnt das Missverständnis.

Der ehrliche Trade-off gegenüber Managed-IAM

Die naheliegende Rechnung lautet: Okta, Auth0 oder Microsoft Entra kosten pro aktivem Nutzer, Keycloak kostet nichts, also spart man. Diese Rechnung ist unvollständig.

Was Sie bei Keycloak nicht zahlen, sind Lizenzgebühren. Was Sie stattdessen übernehmen, ist Betriebsverantwortung. Ein Managed-IAM-Anbieter betreibt die Hochverfügbarkeit, spielt Sicherheitspatches ein, garantiert Verfügbarkeit per SLA und stellt Compliance-Zertifizierungen bereit. Bei Keycloak tun Sie das selbst, oder ein Partner tut es für Sie. Der Tausch ist also nicht Funktion gegen Funktion, sondern Lizenzkosten gegen interne Betriebskosten.

Das ist kein Argument gegen Keycloak. Es ist ein Argument gegen die naive Annahme, Open Source sei umsonst. Ab einer gewissen Nutzerzahl kippt die Rechnung deutlich zugunsten des Eigenbetriebs, weil die Lizenzkosten linear mit den Nutzern wachsen, die Betriebskosten eines gut aufgesetzten Keycloak-Clusters aber weitgehend konstant bleiben. Bei kleinen Nutzerzahlen oder einem Team ohne dediziertes Plattform-Know-how kippt sie in die andere Richtung.

Die ehrliche Frage ist deshalb nicht "Lizenz ja oder nein", sondern: Haben wir die Fähigkeit und den Willen, ein sicherheitskritisches System dauerhaft zu betreiben? Wer diese Frage nicht klar mit Ja beantworten kann, sollte den Managed-Weg ernsthaft prüfen, auch wenn er auf dem Papier teurer aussieht.

Sauberes Realm- und Client-Design

Wenn die Entscheidung für den Eigenbetrieb fällt, entscheidet die Architektur über Erfolg oder Schmerz, nicht die Installation. Keycloak ist in einer Stunde aufgesetzt. Ein tragfähiges Modell zu entwerfen, das man in drei Jahren noch versteht, dauert länger.

Der zentrale Strukturbegriff ist das Realm. Ein Realm ist ein isolierter Mandant mit eigenen Nutzern, Rollen und Clients. Eine häufige Fehlentscheidung ist, alles in einen einzigen Realm zu legen oder umgekehrt für jede Anwendung einen eigenen Realm anzulegen. Die belastbare Faustregel: ein Realm pro Vertrauenszone. Interne Mitarbeiter, externe Kunden und Partnerorganisationen gehören typischerweise in getrennte Realms, weil sie unterschiedliche Authentifizierungswege, Passwort-Richtlinien und Lebenszyklen haben.

Innerhalb eines Realms wird jede Anwendung als Client modelliert. Hier kommt es auf Disziplin an: vertrauliche Clients mit serverseitigem Secret klar von öffentlichen Clients (Single-Page-Apps, mobile Apps) trennen, Redirect-URIs restriktiv halten statt mit Wildcards aufweichen, und Rollen sowie Berechtigungen über Client-Scopes sauber strukturieren. Ein unsauberes Client-Modell rächt sich nicht sofort, sondern dann, wenn Sie unter Zeitdruck eine neue Anwendung anbinden müssen und niemand mehr durchblickt, welcher Scope welche Berechtigung trägt.

Betrieb: Härtung, Hochverfügbarkeit und die Datenbank

Keycloak ist ein zustandsbehaftetes System mit hohen Verfügbarkeitsanforderungen. Fällt es aus, kann sich niemand mehr anmelden, an keiner angebundenen Anwendung. Das macht den Betrieb zum eigentlichen Projekt.

Drei Themen entscheiden:

Datenbank. Keycloak speichert Realms, Clients, Nutzer und Konfiguration in einer relationalen Datenbank (PostgreSQL ist die übliche und solide Wahl). Diese Datenbank ist der kritische Zustand. Sie muss redundant ausgelegt, gesichert und überwacht sein. Eine Keycloak-Installation ist nur so verfügbar wie die Datenbank dahinter.

Clustering und Session-Strategie. Für Hochverfügbarkeit betreibt man mehrere Keycloak-Instanzen hinter einem Load Balancer. Damit Sessions nicht bei jedem Knotenausfall verloren gehen, müssen die Instanzen ihren Session-Zustand teilen (in aktuellen Versionen über eine verteilte Infinispan-Schicht). Die Token-Strategie gehört zur selben Entscheidung: kurze Lebensdauer für Access Tokens, kontrollierte Refresh-Token-Rotation, und ein durchdachtes Logout-Verhalten über alle Anwendungen hinweg. Wer hier nachlässig ist, baut sich entweder ein Sicherheitsloch oder eine Quelle ständiger Re-Logins.

Härtung. Standardkonfiguration ist keine Produktionskonfiguration. Admin-Konsole vom öffentlichen Netz trennen, TLS erzwingen, Brute-Force-Schutz aktivieren, Passwort- und MFA-Richtlinien setzen, die ausgelieferten Token-Claims auf das Nötige reduzieren. Identität ist das Hauptangriffsziel: Wer den Identity-Provider kompromittiert, kompromittiert alles dahinter.

Upgrade-Disziplin: das unterschätzte Dauerthema

Managed-IAM aktualisiert sich im Hintergrund. Beim Eigenbetrieb ist die Aktualisierung Ihre Aufgabe, und Keycloak entwickelt sich schnell. Versionen erscheinen in kurzer Folge, einzelne Major-Sprünge brachten in der Vergangenheit erhebliche Brüche mit sich, etwa der Wechsel des darunterliegenden Application-Servers oder die Umstellung des Admin-Themes.

Das bedeutet konkret: ein reproduzierbares Deployment (Konfiguration als Code, nicht von Hand geklickt), eine Staging-Umgebung, auf der jedes Upgrade vor Produktion getestet wird, und ein festes Wartungsfenster. Wer Keycloak einmal aufsetzt und dann Jahre nicht anfasst, sammelt ungepatchte Sicherheitslücken an und steht irgendwann vor einem Migrationssprung über mehrere Major-Versionen, der weit teurer ist als kontinuierliche kleine Updates. Upgrade-Disziplin ist kein Nice-to-have, sie ist Teil der Betriebskosten, mit der man von Anfang an rechnen muss.

Der DSGVO- und Datenresidenz-Vorteil

Hier liegt das stärkste strategische Argument für Keycloak im DACH-Raum, und es ist eines, das die reine Kostenrechnung nicht erfasst. Bei selbst betriebenem IAM bleiben die Identitätsdaten, also Anmeldedaten, Profile, Berechtigungen und Authentifizierungsprotokolle, vollständig auf Ihrer eigenen Infrastruktur.

Sie bestimmen die Datenresidenz selbst: ein Rechenzentrum in Deutschland, eine europäische Cloud-Region, eine On-Premise-Umgebung. Es gibt keinen US-amerikanischen Verarbeiter im Pfad, keine Frage nach Standardvertragsklauseln, keine Diskussion über Drittlandtransfers für die sensibelste Datenkategorie überhaupt. Für regulierte Branchen, öffentliche Auftraggeber und Unternehmen mit klarer Souveränitätsanforderung ist das oft kein Komfortmerkmal, sondern eine harte Voraussetzung. Keycloak gibt Ihnen diese Kontrolle, weil Sie den gesamten Stack besitzen.

Der Vollständigkeit halber: Auch Managed-Anbieter bieten europäische Regionen an. Der Unterschied ist die Eigentumsfrage. Beim Eigenbetrieb ist die Datenhoheit nicht zugesichert, sondern strukturell gegeben.

Fazit: selbst betreiben wenn, managed wählen wenn

Keycloak ist ein mächtiges, ausgereiftes Identity- und Access-Management mit vollständiger OIDC- und SAML-Unterstützung, Single Sign-On, Föderation und Identity Brokering, und das ohne Lizenz pro Nutzer. Es ist aber ein System, das man betreiben muss, kein SaaS zum Vergessen.

Selbst betreiben, wenn: die Nutzerzahl hoch genug ist, dass Lizenzkosten ins Gewicht fallen; Datenresidenz und Souveränität eine harte Anforderung sind; Sie ein Team (intern oder über einen Partner) haben, das Betrieb, Härtung und Upgrades dauerhaft trägt; und die Anwendungslandschaft heterogen genug ist, dass Föderation und Protokollvermittlung echten Wert schaffen.

Managed wählen, wenn: die Nutzerzahl klein ist; kein Plattformteam zur Verfügung steht; die Verfügbarkeit per SLA garantiert sein muss, ohne dass Sie sie selbst herstellen wollen; und die Datenresidenz über eine europäische Region des Anbieters ausreichend abgedeckt ist. In diesem Fall ist die Lizenzgebühr der Preis dafür, ein Risiko abzugeben, das Sie sonst selbst tragen.

Die falsche Antwort ist, Keycloak zu wählen, weil es nichts kostet, und den Betrieb zu unterschätzen. Genau so entstehen ungepatchte, schlecht modellierte Identity-Provider, die zum größten Sicherheitsrisiko im Unternehmen werden.

Keycloak-Strategie mit DNA Solutions klären

DNA Solutions berät und begleitet Unternehmen im DACH-Raum beim Aufbau und Betrieb von selbst betriebenem Identity- und Access-Management mit Keycloak, vom Realm- und Client-Design über Härtung und Hochverfügbarkeit bis zur Upgrade-Strategie. Wenn Sie vor der Entscheidung zwischen Keycloak und einem Managed-Anbieter stehen oder eine bestehende Installation produktionsreif machen wollen: Sprechen Sie uns an.