Was ist Keycloak?
Keycloak ist ein Open-Source-System für Identity und Access Management. Es beantwortet für jede deiner Anwendungen zwei Fragen: Wer ist diese Person, und was darf sie. Es bringt Single Sign-On, Mehr-Faktor-Authentisierung, Social Login und Föderation mit LDAP und Active Directory mit und spricht OAuth 2.0, OpenID Connect und SAML 2.0. Hinter dem Projekt steht Red Hat, es ist ein CNCF Incubating Project und unter Apache 2.0 lizenziert.
Das Problem dahinter
Jede Anwendung muss wissen, wer sie benutzt. Ohne zentrale Instanz löst das jede für sich, und in einer Organisation entsteht ein bekanntes Durcheinander:
- Jede Anwendung hat ihre eigene Benutzertabelle, eigene Passwortregeln und einen eigenen Reset-Ablauf.
- Eine neue Person wird von Hand an sechs Stellen angelegt. Wer geht, wird an vier entfernt, und niemand weiss sicher, an welchen vier.
- Mehr-Faktor-Authentisierung muss überall einzeln gebaut werden.
- «Wer hat Zugriff worauf» lässt sich nur beantworten, indem man alle Anwendungsverantwortlichen fragt.
Ein Identity Provider nimmt den Anwendungen diese Aufgabe ab. Es gibt einen Ort, an dem Benutzende existieren, eine Anmeldemaske, einen Satz Regeln zu Passwörtern und zweiten Faktoren und eine Stelle, an der du nachsiehst, wenn jemand das Unternehmen verlässt.
Was Single Sign-On tatsächlich bedeutet
Sichtbar ist: einmal anmelden, danach mehrere Anwendungen ohne erneute Anmeldung erreichen. Interessant ist der Mechanismus, denn er trägt das Sicherheitsargument.
Die Anwendung sieht das Passwort nie. Stattdessen leitet sie den Browser zu Keycloak, Keycloak prüft die Identität so, wie es konfiguriert ist, und schickt den Browser mit einem signierten Token zurück, das aussagt, wer die Person ist und was sie darf. Die Anwendung prüft die Signatur und vertraut dem Inhalt.
Die Folge: Eine kompromittierte Anwendung kann keine Zugangsdaten preisgeben, die sie nie hatte. Und genau deshalb ist die Einführung eines zweiten Faktors eine Änderung an einem System statt an fünfzehn.
OpenID Connect ist das moderne Protokoll dafür und die richtige Wahl für neue Anwendungen. SAML 2.0 ist älter, gesprächiger und das, was sehr viel Unternehmens- und Verwaltungssoftware unterstützt. Keycloak kann beides, und häufig ist genau das der Grund für die Wahl: Gewachsene Landschaften enthalten beide Sorten.
Zwei verschiedene Probleme, ein Name
Vor der Frage, ob du einen Identity Provider brauchst, steht die Frage, welchen davon. Die Antworten laufen weit auseinander.
Mitarbeitenden-Identität betrifft die eigenen Leute: Angestellte und Externe, die sich an internen Systemen anmelden. Die Zahlen sind durch den Personalbestand begrenzt, das Verzeichnis existiert meist schon, und in den meisten Organisationen steht dort ein Microsoft-Umfeld mit Active Directory oder Entra ID. Keycloak föderiert damit, statt es zu ersetzen.
Kunden-Identität betrifft die Nutzenden eines Produkts, das du verkaufst. Wie viele es sind, begrenzt nur der Erfolg des Produkts, und kontrollieren lassen sie sich am wenigsten: Wer sich anmeldet, bringt ein Google- oder Microsoft-Konto mit und will genau das benutzen.
An dieser Unterscheidung hängt die Wirtschaftlichkeit. Ein Preis pro Nutzerin ist beim Personalbestand erträglich und bei Kundenzahlen schmerzhaft: Die Rechnung wächst mit dem Erfolg, und jedes ruhende Konto kostet weiter. Genau hier hört der Eigenbetrieb auf, eine Betriebsfrage zu sein, und wird zu einer Preisfrage, denn der Umschlagpunkt kommt früher, als Teams erwarten.
Für Kunden-Identität ist Föderation die Funktion, die am meisten Arbeit spart. Anmeldung mit dem Konto, das die Person schon hat, Google, Microsoft, Apple oder der Identity Provider ihres Arbeitgebers, ist eingebaut. Teams unterschätzen das regelmässig, bauen es selbst, einmal pro Anwendung, und pflegen es danach.
Der Nutzen ist in beiden Fällen derselbe: Anwendungen haben nicht mehr je eine eigene Vorstellung davon, wer eine Person ist, sondern eine Stelle zum Anmelden und ein Token zum Prüfen.
Wann du einen brauchst
- Mehr als eine Handvoll Anwendungen mit überlappenden Nutzenden. Die Kosten des Verzichts wachsen mit der Zahl der Benutzertabellen.
- Ein Produkt mit Kundenkonten, wo der Preis pro Nutzerin mit dem Erfolg wächst und Föderation erwartet wird.
- Ein echter Prozess für Ein- und Austritte. Zentrale Identität macht aus dem Offboarding eine Handlung statt einer Checkliste.
- Mehr-Faktor-Authentisierung als Vorgabe, weil sie sich an einer Stelle sehr viel leichter durchsetzen lässt.
- Eine Revision, die wissen will, wer worauf Zugriff hat. Eine Antwort statt fünfzehn.
Wann nicht
Eine einzelne Anwendung mit wenigen internen Nutzenden braucht das nicht. Die eingebaute Anmeldung genügt, und ein Identity Provider wäre mehr Infrastruktur, als das Problem rechtfertigt.
Wenn ein gehosteter Identity-Dienst passt und der Preis stimmt, ist das eine legitime Antwort mit weniger Betrieb. Okta, Auth0 und Microsoft Entra ID lösen das gut, und ein Managed Keycloak von einem beliebigen Anbieter ebenso. Der sinnvolle Vergleich ist der Preis pro Nutzerin bei deiner erwarteten Grösse gegen die Kosten des Keycloak-Betriebs, und der Punkt, an dem sich das dreht, ist meist klarer, als man erwartet. Unser Vergleich SaaS gegen Open Source rechnet das durch, und Open-Source-IAM behandelt die Alternativen zu Keycloak.
Warum der Betrieb kein Wochenende ist
Keycloak ist schnell installiert. Das ist die Falle: Die Installation ist nicht die Arbeit.
- Es ist der kritischste Dienst, den du betreibst. Steht der Identity Provider, stehen alle Anwendungen dahinter, auch die, mit der du es reparieren würdest. Hochverfügbarkeit ist hier keine Kür.
- Es hat eine Datenbank, und die enthält deine Nutzenden. Backups, geübte Wiederherstellung und dieselbe Sorgfalt wie bei jedem primären Datenspeicher.
- Upgrades betreffen alles. Keycloak veröffentlicht regelmässig, und grosse Versionen haben in der Vergangenheit Wesentliches geändert. Ohne Testumgebung und Rückweg wird das unangenehm, weil der Wirkungsbereich total ist.
- Realm-Konfiguration ist mächtig und folgenreich. Realms, Clients, Rollen, Scopes, Mapper, Flows. Ein falsch gesetzter Token-Mapper gibt einer Anwendung stillschweigend mehr Rechte als beabsichtigt.
- Zertifikate und Schlüsselwechsel. Signaturschlüssel müssen rotieren, und das ohne Bruch aller Integrationen will geplant sein.
- Sitzungs- und Token-Laufzeiten sind eine Sicherheitsentscheidung. Die Voreinstellungen sind ein Ausgangspunkt, keine Antwort.
Wo VSHN hineinpasst
VSHN betreibt Keycloak auf Schweizer Cloud-Infrastruktur ab CHF 360 pro Monat, mit bis zu 99.99% SLA, 24/7-Betrieb und ohne Preis pro Nutzerin, gemeinsam mit Inventage, die die Keycloak-Expertise einbringen. Die Fragen zu Verfügbarkeit, Upgrades und Backups oben sind genau das, was der Dienst abnimmt.
Wenn du noch früher stehst und zwischen gehostetem Dienst und Eigenbetrieb abwägst, sind die verlinkten Vergleichsseiten der nützliche Einstieg.