© Sommai Larkjit / 123rf.com

Zentrale Authentifizierung und Autorisierung sind in der Cloud elementar. Man kann sie entweder als Dienstleistung einkaufen oder mit freien Komponenten selbst bauen. Wir vergleichen das kommerzielle Okta mit dem freien Keycloak und zeigen, worauf es zu achten gilt.

Wenn von der guten alten Zeit die Rede ist, kommen oft viel Folklore und romantische Verklärung im Spiel. Das Identitätsmanagement, also die Authentifizierung und Autorisierung, bietet dafür ein gutes Beispiel: Wo früher regelmäßig Insellösungen Usus waren, hat sich längst die Erkenntnis durchgesetzt, dass die zentrale Verwaltung von Zugangsdaten unverzichtbar ist.

Das gilt umso mehr in Zeiten der Cloud: Dass ein Mensch, der im Rahmen seiner täglichen Arbeit fünf verschiedene Online-Dienste nutzt, dafür fünf separate Sätze an Zugangsdaten braucht und seinen Benutzerzugang nicht an zentraler Stelle deaktivieren kann, ist kaum noch denkbar. Spätestens, wenn ein Mitarbeiter ein Unternehmen im Streit verlässt, gewinnt die zentrale Verwaltung von Zugangsdaten elementare Bedeutung. Anderenfalls könnte es durchaus passieren, dass der geschasste Kollege noch schnell wichtige Daten löscht, bevor der Admin seinen Zugang im Dienstedschungel sperren konnte.

Weil immer mehr Dienste und Anwendungen in die Cloud wandern, nimmt die Relevanz der zentralen Rechteverwaltung weiter zu. Auch das grundsätzliche Thema IT-Sicherheit spielt dabei eine Rolle: Wer die Authentifizierung und Autorisierung zentral steuert, kann verbindliche Regeln vorgeben, an die die Nutzer sich zu halten haben. Das kann durchaus fortgeschrittene Techniken umfassen wie den Ersatz von Passwörtern durch verschiedene, miteinander kombinierter Zugangstoken – eine Form der Zwei-Faktor-Authentifizierung also.

Nicht nur die Gepflogenheiten bei der Nutzerverwaltung haben sich verändert, sondern auch die Art und Weise und vor allem die Werkzeuge, die Administratoren für diese Aufgabe nutzen. Will ein Unternehmen zentrale Authentifizierung (“Wer bist du?”) und zentrale Autorisierung (“Was darfst du?”) einführen, bieten sich heute fast immer zwei Möglichkeiten an.

Variante 1 geht davon aus, dass man sich des Themas komplett entledigen möchte und den Betrieb der nötigen Infrastruktur einem Anbieter in der Cloud überlässt. Okta (Abbildung 1) ist dafür ein gutes Beispiel: Es fungiert als Dienst aus der Wolke, als zentrale Anlaufstelle sowohl für Autorisierung als auch für Authentifizierung und erfreut sich weltweit größter Beliebtheit. Über zahllose Integrationen in Dienste wie Salesforce oder AWS lässt sich Okta mit allen gängigen Online-Anwendungen verbinden, und zwar auch mit vielen, die beim Kunden üblicherweise On-Premises laufen.

Der Feature-Reichtum von Okta [1] weiß dabei durchaus zu beeindrucken: Features wie Single Sign-on (SSO) gehören zum Lieferumfang, fortgeschrittenere Ansätze wie das schon erwähnte Login ohne Passwörter unterstützt die Lösung ebenfalls. Weil Okta über APIs und Schnittstellen nach SAML- (Security Assertion Markup Language) und OpenID-Standard verfügt, lässt es sich sogar mit solchen Diensten verbinden, für die eine fertige Okta-Integration seitens des Herstellers nicht bereitsteht. Wer seine Logins und Passwörter nicht in der Cloud haben möchte, bindet Okta per LDAP oder Active Directory an ein lokales Benutzerverzeichnis an und genießt trotzdem sämtliche Vorzüge.

Abbildung 1: Okta fungiert als Identity Provider wahlweise mit Anbindung an bestehende Verzeichnisse oder mit der Möglichkeit, selbst als ein solches Verzeichnis zu dienen. Quelle: DataHub

Viele Unternehmen scheuen indes den Gedanken, die Authentifizierung der eigenen Dienste in irgendeiner Weise an die Cloud zu koppeln. Hier stehen stattdessen lokale Lösungen im Fokus. Aktuell ist das Werkzeug Keycloak so etwas wie die To-go-Lösung für zentralisierte Authentifizierung und Autorisierung. Es kommt mit einem Füllhorn an Funktionen daher: Wie Okta unterstützt es OpenID Connect, OAuth 2.0 sowie SAML, kann ebenfalls an bestehende Benutzerverzeichnisse andocken und bietet alternativ eine eigene Verwaltung für Nutzer und Dienste. Durch die Protokolle, die Keycloak ab Werk standardmäßig unterstützt, fungiert es auf Wunsch als Identity Provider für andere Dienste wie OpenStack oder Kubernetes. Auch die typischen Cloud-basierten Anwendungen wie AWS oder Microsoft 365 lassen sich mit Keycloak verbinden und nutzen.

Da stellt sich aus Admin-Sicht die Frage, welche Option sinnvoller ist und was den eigenen Bedürfnissen eher entspricht. Dieser Artikel wagt den Vergleich und zeigt, inwiefern sich die beiden Ansätze unterscheiden. Dabei spielt das Feature-Set eine ebenso große Rolle wie die Frage, welche betrieblichen und rechtlichen Herausforderungen die beiden Ansätze jeweils mit sich bringen.

Okta: Wunschlos glücklich?

Um die beiden Lösungen miteinander zu vergleichen, empfiehlt sich zunächst ein genauerer Blick auf die vorhandenen Funktionen. Die sind bei Okta durchaus umfangreich: Der Service versteht sich schließlich als nicht weniger als ein flexibler und neutraler Dienst für Identity im Internet. Der selbst erklärte Anspruch von Okta ist also umfassend.

Die Produktgestaltung erschließt sich jedoch nicht unbedingt auf den ersten Blick. Bei Okta hat man die Wahl zwischen der Customer Identity Cloud und der Workforce Identity Cloud. Okta unterscheidet strikt zwischen der Identifizierung von Webanwendungen, die Anbieter den Endanwendern einer Online-Plattform bieten wollen, und einer kompletten Lösung für die Beschäftigten und eigenen Dienste eines Unternehmens.

Der im Artikel skizzierte Einsatzbereich entspricht eher dem, was Okta unter Workforce Identity Management beschreibt: Es geht um die Absicherung von Diensten innerhalb einer Firma. Wie sich bei Keycloak später zeigen wird, fehlt dort eine entsprechende Einteilung; bei Okta spielt sie dagegen eine große Rolle, denn sie wirkt sich auf die Kosten aus, die Okta im Betrieb hervorruft. Doch dazu später mehr. Erwähnt sei noch, dass auch die Customer Identity Cloud die Möglichkeit zur Anbindung externer Kunden an Dienste ermöglicht. Unter der Haube nutzen die beiden Okta-Produkte vermutlich ohnehin dieselbe Infrastruktur.

Greift man hingegen zur Workforce-Variante, legt man sich damit implizit auf ein Feature Set und ein Abrechnungsmodell fest. Fest zum Lieferumfang gehört etwa Single Sign-on, das in den Varianten SSO und Adaptive SSO daherkommt. Die beiden Funktionen unterscheiden sich vorrangig durch die Fähigkeit der Adaptive-SSO-Option, zusätzliche Merkmale wie einen Standort- oder Gerätekontext bei der Authentifizierung und Autorisierung zu berücksichtigen. Auch die Autorisierung unter Beachtung externer Risikofaktoren ist in der Adaptive-Variante möglich, fehlt in der SSO-Version hingegen vollständig.

MFA mit vielen Optionen

Ähnlich verhält es sich mit der Mehrfaktorauthentifizierung (MFA). Die gilt heute als absoluter Standardbaustein im Sicherheitsbaukasten jedes Unternehmens. Entsprechend hat Okta das Feature durchaus im Angebot. Auch hier greift aber eine Unterscheidung zwischen MFA und Adaptive MFA. Das normale MFA-Feature bietet dabei die üblichen Funktionen, die Anwender von einer MFA-Lösung erwarten. Nutzer richten also einen zweiten Faktor wie einen OTP- oder U2F-Schlüssel (etwa von Yubikey) für ihre Anmeldung ein. Daneben sind biometrische Merkmale möglich, wofür das Betriebssystem aber Schützenhilfe leisten muss. Windows Hello und Apple TouchID lassen sich mit Okta verbinden. Wer einen Linux-Client nutzt, schaut bei der Funktion dagegen in die Röhre.

Der Hauptunterschied zwischen der normalen MFA-Funktion und der Adaptive-Variante betrifft wieder die äußeren Faktoren, innerhalb derer MFA sich nutzen lässt. Bei der normalen Variante lassen sich lediglich Filter auf Basis bestimmter IP-Bereiche setzen. Bei der Adaptive-Version kann hier ein proprietäres Feature namens Okta ThreatInsight zum Einsatz kommen, eine vom Anbieter gepflegte Bedrohungsdatenbank. Erkennt Okta während eines Anmeldeversuchs anhand dieser Datenbank verdächtige Umstände, bricht es den Vorgang ab. Der adaptiven Version vorbehalten bleibt die Möglichkeit, MFA auf bereits bekannte oder neue Geräte zu beschränken oder Faktoren wie eine neue IP-Adresse für einen Client zu blockieren.

Während SSO und MFA die mit Abstand am häufigsten genutzten Features von Okta sein dürften, kommt im Rahmen der Workforce Identity Cloud noch eine Reihe zusätzlicher Features hinzu. Unter dem Begriff Universal Directory bietet Okta etwa die Möglichkeit, verschiedene Benutzerverzeichnisse via LDAP oder Active Directory in der Cloud virtuell zu integrieren. Nach außen hin entsteht dann eine einheitliche Sicht. Obendrein bietet das Universal Directory eine LDAP-Anbindung für die Anmeldung hin zur Außenwelt. Benutzerattribute und Felder legt ein Unternehmen in diesem Ansatz nach Belieben und unbegrenzt an.

Ein ganzes Füllhorn an Features versteckt sich hinter der Bezeichnung Lifecycle Management. Hier bietet Okta verschiedene Werkzeuge und Features, um Nutzer anzulegen, Okta mit anderen Cloud-Diensten wie Office 365 zu integrieren und verschiedene Prozesse zu automatisieren. Das erleichtert der IT-Abteilung an verschiedenen Stellen die Arbeit, erfordert aber auch, dass sich der Anwender mit Okta und seinen Funktionen sehr detailliert befassen muss.

Weitere Funktionen beziehen sich auf das Verwalten des API-Zugriffs von Okta, die Unterstützung gemischter Umgebungen aus AWS, Azure, GCP und anderen Cloud-Diensten sowie die Möglichkeit, echte Ende-zu-Ende-Integration etwa von Linux-Systemen mit Okta zu implementieren. Das Advanced-Server-Access-Feature bietet beispielsweise die Möglichkeit, Linux-Server wie eine lokale LDAP-Instanz direkt an Okta anzubinden. Das setzt freilich voraus, dass der jeweilige Knoten irgendeinen Netzwerkpfad ins Internet und mithin zu Okta hat.

Wer keine Server integrieren möchte, dafür aber lokale Anwendungen, bucht stattdessen das Access Gateway. Hinter der Bezeichnung Workflow Management schließlich verbirgt sich eine Verwaltungsumgebung, mittels derer sich komplette Arbeitsabläufe in Okta nativ erstellen lassen.

Die Arbeit mit Okta

Wie viel Kontakt der Administrator mit Okta hat, hängt also vor allem von der Frage ab, welche Dienste des eigenen Unternehmens er an Okta andocken möchte. Geht es nur darum, eine SSO-Lösung für Webanwendungen und Cloud-Dienste wie Microsoft 365 zu realisieren, ist der Aufwand überschaubar und ein schneller Start möglich (Abbildung 2). Man bucht bei Okta die nötigen Dienste auf den eigenen Account, verbindet nötigenfalls einen vorhandenen LDAP- oder Active-Directory-Server mit Okta und hat anschließend den Service sofort zur Verfügung. Hinzu kommen gegebenenfalls noch Arbeitsschritte, um in Okta ein Rechteschema zu integrieren oder ein bestehendes Rechteschema On-Premises in Okta abzubilden. In vielen Setups dürfte das aber gar nicht nötig sein, insbesondere, wenn die Aufgabe nur darin besteht, MFA oder SSO mittels Okta zu realisieren. Dafür genügt es aus Sicht des Administrators, Okta mit den jeweiligen Diensten zu verbinden – schon klappt die geschützte Anmeldung.

Abbildung 2: Mit Standardanwendungen und Diensten wie Office respektive Microsoft 365 lässt Okta sich in kurzer Zeit verbinden. Für Firmen, die schnell IAM benötigen, eignet der Dienst sich mithin bestens. Quelle: Vu Long Tran

Weil Okta komplett in der Cloud läuft, entfallen aus Sicht des Administrators die meisten in der klassischen Systemadministration nötigen Arbeitsschritte. Hochverfügbarkeit etwa ist bei einer On-Premises-Lösung absolute Grundvoraussetzung. Schließlich will niemand die Zuverlässigkeit zentraler Dienste in einem Unternehmen von der Funktion eines einzelnen Systems abhängig machen. Bei Okta hat der Administrator das Problem schon deshalb nicht, weil die entsprechenden Komponenten in der Cloud laufen. Hier sorgt Okta als Betreiber für Redundanz und ausfallfreie Funktion.

Gerade weil Okta in der Cloud läuft, ergeben sich bei der Nutzung des Diensts allerdings Fragen im Hinblick auf Compliance und Datenschutz. Das typische Dilemma von DSGVO und Cloud-Act trifft Okta zwar im Regelfall nicht so sehr wie andere Diente, schließlich fungiert Okta zunächst als Identity-Broker. Der Anbieter weiß aber trotzdem, wer seine Dienste wann nutzt, und könnte diese Information im Falle eines Falles durchaus weitergeben. Hier muss der Kunde im Einzelfall prüfen, ob und inwieweit eine Okta-Nutzung infrage kommt.

Klar ist hingegen die Preisgestaltung des Diensts, denn damit wirbt Okta öffentlich und ohne das sonst oft übliche und leidige Versteckspiel. Das bedeutet allerdings nicht, dass es trivial wäre, die tatsächlichen Kosten für eine geplante Okta-Nutzung zu errechnen. Okta sieht für jedes der oben aufgeführten Features wie MFA oder SSO einen Preis pro Benutzer pro Monat vor. SSO kostet monatlich 2 US-Dollar pro Nutzer, MFA 3 US-Dollar. Wer nur diese beiden Features nutzt, kommt pro Anwender also auf rund 5 Euro monatlich – ein durchaus überschaubarer Betrag. Wirklich teuer kommt der Advanced-Server-Access-Teil des Produkts zur Anbindung physischer Systeme. Dafür berechnet Okta 15 US-Dollar pro Monat, sodass der anfallende monatliche Gesamtbetrag beim heute üblich großen Fuhrpark an Systemen bereits merklich ins Geld gehen kann.

Der Vollständigkeit halber gilt es zu erwähnen, dass Okta sich in letzter Zeit nicht gerade durch positive Nachrichten hervorgetan hat. Das betrifft besonders den Bereich der Sicherheit. Im Oktober 2023 etwa schafften es Angreifer, in das Kundenportal des Unternehmens einzudringen und dort Daten mitgehen zu lassen. Das betraf in Summe zwar nur jeden hundertsten Kunden, doch handelt es sich nicht um das erste Problem. Bereits 2022 waren Angreifer auf vergleichbare Weise in das System eines Okta-Kunden eingedrungen, an den Okta den eigenen Endanwender-Support ausgelagert hatte. Schon damals gab es Hinweise auf potenzielle Probleme bei der Sicherheit der Plattform durch Unternehmen wie Cloudflare und 1Password. Der erneute Vorfall im Oktober 2023 führte dazu, dass Okta an der Börse knapp 2 Milliarden US-Dollar an Wert verlor.

Keycloak: selbst machen

Nicht zuletzt ist die Frage, ob man Dienste in die Cloud auslagert oder nicht, auch eine Frage der Philosophie. Für Unternehmen, die Okta nicht trauen oder zentrale Dienste wie die Authentifizierung und Autorisierung nicht in externe Hände legen wollen, steht Keycloak [2] als lokale Alternative zur Verfügung. Mit der Cloud hat Keycloak höchstens insofern zu tun, als es als SSO- und MFA-Lösung für Dienste in der Cloud fungieren kann. Die zu Keycloak gehörenden Komponenten laufen jedoch ausschließlich lokal und stehen unter der vollständigen Kontrolle des Betreibers der Maschinen mit den Keycloak-Diensten. Obendrein steht Keycloak unter der Apache License 2.0, also unter einer freien Lizenz. Es handelt sich also um quelloffene Software, die ihre Autoren zudem kostenlos verteilen.

Bei kostenloser Open-Source-Software denken manche Administratoren instinktiv an grobe Bastelei und viel Handarbeit. Diesen Vorwurf muss Keycloak sich allerdings keineswegs gefallen lassen. Tatsächlich verteilen die Autoren ihr Werk nach technischen Standards auf der Höhe der Zeit – manchem mag es vielleicht sogar etwas zu modern sein. Denn die Keycloak-Entwickler raten ausdrücklich davon ab, Keycloak als Paket zu installieren und empfehlen stattdessen ein Ausrollen des Diensts als Container. Dafür benötigt man zumindest eine lokale Runtime für Container, üblicherweise Podman oder Docker.

Viel schöner noch finden die Keycloak-Entwickler allerdings den Betrieb in Kubernetes (Abbildung 3). Die eigentliche Inbetriebnahme beschränkt sich dann auf wenige Kommandozeilenbefehle. Produktiv einsetzen lässt sich der Dienst dann aber meist noch nicht. Zudem ist es schließlich keine komplett triviale Angelegenheit, Kubernetes sinnvoll produktiv zu betreiben. Hat man diese Hürde aber erst einmal überwunden, lässt Keycloak sich flott installieren und nutzen. Unter Kubernetes kommt der Administrator zudem in den Genuss des Keycloak-Operators für K8s. Mittels dieser Komponente lassen sich diverse Eigenschaften von Keycloak unmittelbar über die Kubernetes-APIs steuern, zum Beispiel der Betrieb eines HA-Clusters zur Vermeidung eines SPOF.

Abbildung 3: Keycloak läuft bevorzugt als Dienst in Kubernetes. Man kann es aber auch anderen Anwendungen in K8s mittels eines Gatekeeper-Containers als Authentifizierungskomponente voranstellen. Quelle: Red Hat

Die übrige Keycloak-Konfiguration erfolgt wahlweise per Konfigurationsdatei oder mittels eines schicken und gut funktionierenden Assistenten in Keycloaks Weboberfläche (Abbildung 4). In einem eigenen Dokument geben die Entwickler sogar Ratschläge hinsichtlich der Frage, wie Keycloak sich sinnvoll konfigurieren und absichern lässt, um den Administrator trotz produktiven Betriebs gut schlafen zu lassen.

Abbildung 4: Keycloak kommt mit einem grafischen Frontend daher, über das sich sämtliche zentralen Einstellungen des Werkzeugs steuern lassen. Quelle: Keycloak

Standardfunktionen

Das Feature Set von Keycloak ähnelt weitgehend dem von Okta. So lässt sich das Tool problemlos an bestehende Benutzerverzeichnisse anbinden und mit anderen OpenID-Connect- oder SAML-Diensten koppeln. Bei Bedarf exponiert Keycloak diese Schnittstellen selbst, um gegenüber anderen Werkzeugen als Identity Provider (IdP) aufzutreten.

Wer ein LDAP-Verzeichnis oder Active Directory an Keycloak anbindet, findet umfassende Importfunktionen für das Anmelden von Verzeichnisbenutzern an Keycloak vor. Zudem gibt es ein detailliert arbeitendes Feature für das Mapping von Gruppen und Benutzern. Wie Okta lässt sich Keycloak an soziale Netze anbinden, was eine Anmeldung via Facebook-, Google- oder Apple-Account ermöglicht. Dazu gilt es allerdings, den jeweiligen Nutzern ein Mapping für eine Rolle oder generell für Berechtigungen zuzuweisen. Eine automatische Überbrückungsfunktion erlaubt daneben das Anbinden von Kerberos-Verzeichnissen.

Der Corporate-Identity-Abteilung dürfte gefallen, dass sich die äußere Erscheinung von Keycloak detailliert anpassen lässt. Das ist etwa dann hilfreich, wenn ein Dienst für die Anbindung an Keycloak zum Einsatz kommt und beim Login das entsprechende Fenster aufgehen soll, das den Nutzer zu Keycloak weiterleitet.

Darüber hinaus unterstützt Keycloak verschiedene Funktionen, die sich auf die eine oder andere Weise auch in Okta finden. So beherrscht Keycloak eine gewisse Form des Lifecycle Managements für Accounts. Dazu ermöglicht es Selbstregistrierung und bietet eine Seite an, mittels derer sich Anwender ihr Passwort zurücksetzen können.

Handarbeit nötig

Keycloak folgt trotz der Auslieferung im Container einem eher klassischen Ansatz, sodass sich der Administrator auf einige Handarbeit einstellen muss. Das merkt man besonders deutlich bei der Integration externer Dienste als Client für Keycloak. So lässt sich Okta in wenigen Sekunden mittels einer vorgefertigten Integration seitens des Anbieters mit Microsoft 365 verknüpfen. Keycloak dagegen fehlt eine solche Möglichkeit.

Wer also im konkreten Beispiel Microsoft 365 anbinden will, weiß zwar grundsätzlich, dass das mit Keycloak geht: Schließlich unterstützt die Office-Umgebung von Microsoft SAML ab Werk. Trotzdem muss der Administrator im Keycloak-GUI etliche Einstellungen vornehmen und eine für MS-365-spezifische Client-Konfiguration anlegen. Immerhin hat die Keycloak-Dokumentation für viele Standarddienste entsprechende Beispiele parat (Abbildung 5). Das Anbinden anderer Services setzt aber eine vorherige Recherche im Netzwerk voraus. Einiges Stöbern fördert beispielsweise Anleitungen für das Anbinden von Keycloak an Microsoft 365 sowie für die Integration mit Shibboleth und Keystone in die private Cloud-Umgebung OpenStack zutage. Der Aufwand für derartige Integrationen ist bei Keycloak jedoch in jedem einzelnen Fall ungleich höher als bei Okta.

Abbildung 5: Okta besticht durch eine umfassende, vorgefertigte Integration vieler gängiger Dienste. Diese fehlt in Keycloak auf der Server-Seite. Quelle: Vu Long Tran

Auch preislich verfängt Keycloak nur auf den ersten Blick. Zwar lässt sich der Dienst per se tatsächlich kostenlos installieren und nutzen. Um ihn zu betreiben, benötigt man aber eine gewisse Infrastruktur. Im bevorzugten Szenario der Keycloak-Entwickler ist das ein ausgewachsener K8s-Cluster, der im Regelfall erheblichen personellen und finanziellen Aufwand bedingt. Freilich: Nur für Keycloak stampft niemand ein Kubernetes aus dem Boden. Im Regelfall werden lediglich Firmen, die bereits K8s betreiben, Keycloak auf diese Weise nutzen. Das engt implizit den Benutzerkreis von Keycloak ein, denn Kubernetes findet sich ja üblicherweise eher in größeren Firmen.

Fazit

Wie so oft ist die Entscheidung zwischen Keycloak und Okta auch eine Entscheidung grundsätzlich für oder gegen die Cloud. Datenschutzthemen spielen hier zwar eine geringere Rolle als bei anderen Cloud-Diensten, weil Okta vorrangig als Broker arbeitet und je nach Konfiguration keine eigenen Daten hält. Wer aber die volle Kontrolle über seine Daten behalten möchte, muss auf Okta verzichten.

Wer dagegen mit der Nutzung von Diensten in der Cloud kein Problem hat, findet in Okta eine elegante und gut funktionierende Alternative zum Betrieb einer eigenen IdP-Lösung. Dabei punktet Okta vor allem mit der fertigen Integration in viele Cloud-Dienste sowie mit einer einigermaßen einfachen und intuitiven Konfiguration. Das Preismodell fällt hinreichend übersichtlich aus und wird daneben nicht von Mondpreisen dominiert, wie sie im Cloud-Kontext manchmal anfallen. Wer für eine kleinere Firma SSO und MFA benötigt, kommt mit Okta mit einiger Wahrscheinlichkeit schneller und günstiger ans Ziel als mit Keycloak.

Keycloak spielt seine Stärken vor allem aus, wenn es gilt, Hunderte oder gar Tausende Nutzer zu verwalten: Hier würden die Gebühren für Okta früher oder später eben doch opulent ausfallen. Zudem halten große Unternehmen üblicherweise die benötigte Infrastruktur für Keycloak bereits vor, sodass sich der IdP-Dienst dort einfach als weiterer Baustein in den ohnehin laufenden Betrieb von IT-Komponenten einfügt. (jcb/jlu)