Dein Käfig ist ein Wörterbuch

Realm heißt Tenant. Client heißt App-Registrierung. Wer diese Übersetzung einmal im Kopf hat, merkt: Am Weg von Entra ID zu Keycloak ist technisch nichts schwer. Schwer ist nur, die Wörter loszulassen. Und genau daran verdient Redmond.

Es war ein Samstagnachmittag, und ich saß vor der Admin-Konsole von Keycloak. Die Isar OSC sollte ein zentrales Login bekommen, ein einziges, für Matrix, für OpenCloud, für OpenTalk, für Wordpress. Keine fünf Passwörter mehr, keine fünf Benutzerverwaltungen, keine fünf Stellen, an denen man einen Menschen vergisst, wenn er geht.

Und ich verstand kein Wort.

„Realm". „Client". „Protocol Mapper". „Client Scope". Das klang nach einem System, das mir fremd war, und ich hatte für den Nachmittag eingeplant, dass es fremd sein würde. Man liest sich ein, man tastet sich vor, man tritt in ein paar Rechen im hohen Gras. Kenne ich. Mache ich gern.

Zwei Stunden später kam der Groschen, und er fiel unangenehm laut.

Ich kannte das alles. Jedes einzelne Konzept. Ich kannte es seit zwanzig Jahren. Ich kannte es nur unter anderen Namen, einem anderen bunten Schildchen.

Die These, gleich vorweg

Ein Keycloak-Realm ist ein Entra-Tenant. Ein Keycloak-Client ist eine App-Registrierung. Alles andere folgt daraus.

Das ist die 30-Sekunden-Fassung dieses ganzen Artikels, und wer nur diese zwei Sätze mitnimmt, hat schon das Wichtigste. Denn wenn das stimmt, und es stimmt, dann fällt eine Behauptung in sich zusammen, die ich in Beratungsgesprächen seit Jahren höre und die immer im selben bedeutungsschweren Tonfall vorgetragen wird:

„Ein Wechsel weg von Entra ist zu komplex."

Nein. Ist er nicht. Nicht auf der Konzeptebene, und die ist die einzige, auf der dieser Satz behauptet wird. Was tatsächlich fehlt, ist ein Wörterbuch. Zwei Seiten Übersetzung, mehr nicht. Aber weil dieses Wörterbuch fehlt, fühlt sich Fremdheit an wie Komplexität, und Komplexität ist ein wunderbares Argument, weil sie nach Sachlichkeit klingt und nach Erwachsensein und nach jemandem, der die Dinge zu Ende gedacht hat. Unsinn.

Der Lock-in, um den es hier geht, ist kein technischer. Es ist ein lexikalischer.

Man bleibt nicht, weil man muss. Man bleibt, weil man die Wörter kennt.

Ich habe an diesen Wörtern mitgebaut

An dieser Stelle muss ich offenlegen, dass ich hier nicht von einer neutralen Werkbank aus schreibe. Von 2005 bis 2011 habe ich für Microsoft gearbeitet, und wer meinen kürzlichen Text über Azure Linux gelesen hat, weiß, dass ich die Embrace-Extend-Extinguish-Logik nicht aus Büchern sondern aus eigener Erfahrung auf der anderen Seite zitieren muss.

Vokabular war in diesen Jahren nie ein Nebenprodukt. Es war Kern-Strategie. Wer die Begriffe setzt, mit denen eine Branche denkt, muss seine Produkte nicht mehr verteidigen, weil die Konkurrenz dann in einer Fremdsprache antworten muss. Deutungshoheit durch "Wording". Zertifizierungen sind hier das schärfste Instrument, das je erfunden wurde. Der MCSE meiner Zeit war kein Wissensnachweis, er war ein Sprachkurs mit Urkunde, und heute heißt er SC-300 oder ähnlich und tut exakt dasselbe. Hunderttausende Menschen haben gelernt, Identität in Tenants, Verzeichnisrollen und App-Registrierungen zu denken, und sie haben dafür Geld und Wochenenden bezahlt. Diese Investition verteidigt man. Nicht aus Dummheit, sondern weil sie einem gehört.

Das ist kein Skandal, um es so klar zu sagen wie im Rust-Artikel. Jeder Anbieter benennt seine Dinge selbst, das ist sein gutes Recht. Aber man sollte sehen, was dabei entsteht: Ein Käfig, dessen Gitterstäbe aus Vokabeln bestehen. Er hat keine Tür, die abgeschlossen wäre. Er hat nur eine, die man nicht als Tür erkennt, weil daneben kein Schild in der eigenen Sprache hängt.

Hängen wir das Schild also auf.

Realm = Tenant

Ein Realm in Keycloak ist ein vollständig abgeschlossener Mandant. Eigene Benutzer, eigene Anwendungen, eigene Rollen, eigene Login-Seite, eigene Schlüssel zum Signieren der Tokens. Zwei Realms auf demselben Server wissen nichts voneinander. Praktisch also wie zwei getrennte Entra-Tenants.

Praktisch, nicht exakt, und der Unterschied ist wichtig genug für einen eigenen Satz: Zwei Entra-Tenants trennt eine Sicherheitsgrenze. Zwei Realms trennt eine Logik, die auf demselben Server, in derselben Datenbank und unter derselben Master-Ebene liegt. Es ist eine Isolation mit einem Hausmeister, der alle Schlüssel hat. Wer Mandanten trennt, weil ein Auditor es verlangt, sollte das wissen, bevor der Auditor es merkt.

Wer es greifbar braucht, schaue auf den Aussteller der Tokens:

Keycloak:  https://accounts.example.org/realms/isarosc
Entra ID:  https://login.microsoftonline.com/<tenant-id>/v2.0

Beide legen ihr OpenID-Connect-Discovery-Dokument unter denselben Standardpfad. <issuer>/.well-known/openid-configuration. Dieselbe Datei, dieselbe Struktur, derselbe Zweck. Das ist keine wohlwollende Ähnlichkeit, das ist schlicht derselbe Standard, an den sich beide halten.

Man muss das nicht glauben, man kann es abrufen. Beide Dokumente sind öffentlich, für Microsoft braucht man nicht einmal einen Tenant:

curl https://accounts.example.org/realms/isarosc/.well-known/openid-configuration
curl https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

Keycloak:

{
  "issuer": "https://accounts.example.org/realms/isarosc",
  "authorization_endpoint": ".../protocol/openid-connect/auth",
  "token_endpoint": ".../protocol/openid-connect/token",
  "userinfo_endpoint": ".../protocol/openid-connect/userinfo",
  "jwks_uri": ".../protocol/openid-connect/certs",
  "end_session_endpoint": ".../protocol/openid-connect/logout",
  "device_authorization_endpoint": ".../protocol/openid-connect/auth/device",
  "response_types_supported": ["code", "none", "id_token", "token", …],
  "subject_types_supported": ["public", "pairwise"],
  "id_token_signing_alg_values_supported": ["RS256", "ES256", "EdDSA", …],
  "scopes_supported": ["openid", "profile", "email", "offline_access", …]
}

Entra ID:

{
  "issuer": "https://login.microsoftonline.com/{tenantid}/v2.0",
  "authorization_endpoint": ".../common/oauth2/v2.0/authorize",
  "token_endpoint": ".../common/oauth2/v2.0/token",
  "userinfo_endpoint": "https://graph.microsoft.com/oidc/userinfo",
  "jwks_uri": ".../common/discovery/v2.0/keys",
  "end_session_endpoint": ".../common/oauth2/v2.0/logout",
  "device_authorization_endpoint": ".../common/oauth2/v2.0/devicecode",
  "response_types_supported": ["code", "id_token", "code id_token", …],
  "subject_types_supported": ["pairwise"],
  "id_token_signing_alg_values_supported": ["RS256"],
  "scopes_supported": ["openid", "profile", "email", "offline_access"]
}

Dieselben Feldnamen. Dieselbe Reihenfolge. Dieselbe Bedeutung. Zwei Systeme, die angeblich so furchtbar verschieden sind, dass ein Wechsel zur souveränen Variante „zu komplex" wäre, beantworten dieselbe Frage mit demselben Formular. Nicht ähnlich. Komplett deckungsgleich, bis auf die Werte.

Und dann steht da, wenn man Microsofts Dokument wirklich abruft, in der ersten Zeile das hier:

"issuer": "https://login.microsoftonline.com/{tenantid}/v2.0"

Kein Tippfehler und keine Kürzung von mir. Das sind geschweifte Klammern in der echten Antwort. Entra kann an dieser Stelle nicht sagen, wer es ist, weil es noch nicht weiß, wer du bist. Es reicht dir eine Schablone und trägt den Rest nach, sobald es deinen Benutzernamen kennt.

Keycloak steht in derselben Zeile einfach da: .../realms/isarosc. Fertig. Keine Klammern, kein Nachtrag, keine Frage offen.

Und ein Keycloak-Server kann beliebig viele Realms hosten, so wie man mehrere Entra-Tenants aus einer Hand verwaltet.

Client = App-Registrierung + Enterprise-App

Hier lohnt der genaue Blick, weil Microsoft an dieser Stelle zwei Objekte hat und Keycloak eines.

In Entra registrierst du eine App als App-Registrierung, das globale App-Objekt, die Bauanleitung. Pro Tenant bekommst du dazu einen Service Principal, der im Portal als Enterprise-Application auftaucht: die laufende Instanz, mit Nutzerzuweisungen, Berechtigungen, SSO-Einstellungen. Wer neu ist, hat diese Trennung mindestens einmal nicht verstanden, und ich nehme mich ganz sicher davon nicht aus.

In Keycloak ist beides ein einziges Objekt: der Client. Er trägt die Definition und die Instanz. Redirect-URIs und Secret und Rollen und Mapper, alles an einer Stelle.

Confidential gegen Public ist wieder eins zu eins. Serverseitiger Dienst mit Secret: confidential. SPA oder native App, die kein Secret sicher aufbewahren kann: public, und dann bitte mit PKCE. Genau wie in Entra.

Ehrlicherweise ist genau das der Punkt, an dem Keycloak für unsereins das sauberere Modell hat. Die Trennung in App-Registrierung und Enterprise-App löst vor allem ein Problem von Anbietern mandantenübergreifender Apps: eine Definition, viele Tenants, pro Tenant eine eigene Instanz mit eigenem Consent. Das ist sinnvoll gebaut. Wer aber schlicht seine fünf eigenen Dienste anbinden will, verwaltet ein Objekt, dessen Zweck er nie erlebt.

Rollen, Claims, Föderation: dasselbe in Grün

Bei Rollen gibt es zwei Ebenen. Realm-Roles gelten realm-weit, Client-Roles gehören zu einer Anwendung, und letztere sind das saubere Gegenstück zu Entras App-Rollen. Gruppen sind Gruppen. Composite Roles sind verschachtelte Rollen.

Eine Warnung an dieser Stelle, weil ich selbst darauf hereingefallen bin: Die naheliegende Gleichung „Realm-Roles = Verzeichnisrollen" ist falsch. Entras Verzeichnisrollen verwalten Entra selbst, Global Administrator und Konsorten, und sie kommen nicht einmal im roles-Claim an, sondern in wids. Keycloaks Realm-Roles sind dagegen Allzweckrollen für beliebige Apps. Das echte Gegenstück zu den Verzeichnisrollen sind die Client-Roles des eingebauten realm-management-Clients, realm-admin, manage-users und so weiter. Wer hier zu schnell übersetzt, baut sich ein Berechtigungsmodell, das erst in einem halben Jahr negativ auffällt.

Und dann ist da der Protocol Mapper. Er ist das, was in Entra „optionale Claims" und „Token-Konfiguration" heißt: eine kleine Regel, die entscheidet, was ins Token darf.

Bei der Föderation dasselbe Bild. User Federation hängt ein bestehendes LDAP oder Active Directory an einen Realm, konzeptionell also Entra Connect, nur dass Keycloak direkt mit dem Verzeichnis spricht. Identity Providers schalten einen fremden OIDC- oder SAML-Provider davor, das ist Brokering, vergleichbar mit B2B-Föderation.

So sah mein ID-Token aus, nachdem die Mapper standen:

{
  "iss": "https://accounts.example.org/realms/isarosc",
  "aud": "opencloud",
  "sub": "8f3b…",
  "exp": 1752580800,
  "preferred_username": "axel",
  "email": "axel@example.org",
  "email_verified": true,
  "roles": ["opencloudAdmin", "mitarbeiter"],
  "groups": ["/team-infra"]
}

Fremd? Kein bisschen. Und der Nachsatz „nachdem die Mapper standen" ist keine versteckte Koketterie, sondern die Pointe des nächsten Abschnitts 😄

Wo mich meine eigene Intuition verraten hat

Zwei Stellen haben mich Zeit gekostet. Beide, weil ich zu gut wusste, zu sehr darauf programmiert war, wie Entra funktioniert.

Erstens der master-Realm. In Entra sind Administratoren nichts als besonders privilegierte Benutzer in deinem Tenant. Global Administrator, fertig. Es gibt keinen Admin-Tenant. Keycloak trennt wesentlich strenger per default: Die Administratoren der Plattform leben in einem eigenen, mitgelieferten Realm namens master. Deine Organisation kommt in einen separaten Realm, bei mir isarosc.

master ist kein Tenant für deine Leute. Es ist das Steuerungs-Verzeichnis des Servers selbst.

Dort gehören ausschließlich Keycloak-Admins hinein. Niemals Endnutzer, niemals Dienste. Der häufigste Anfängerfehler ist, alles in master zu bauen, weil man ja schon eingeloggt ist und das Ding ja schon da ist. Tu es nicht. Kurios und lehrreich zugleich: Die Admin-Konsole ist selbst nur ein Client im master-Realm. Keycloak verwaltet sich mit den eigenen Mitteln, sehr schönes Design..

Zweitens der roles-Claim, der da war und trotzdem fehlte. OpenCloud verweigerte mir den Zugriff. Der Benutzer existierte, das Passwort stimmte, das Login klappte, und trotzdem: keine Berechtigung. Ich habe an OpenCloud gesucht, an der Client-Konfiguration, an den Redirect-URIs. Ich habe eine ganze Weile an der völlig falschen Stelle gesucht.

Und dann habe ich das Token aufgemacht, und die Rollen waren drin. Sie standen nur woanders, als ich sie erwartet hatte.

Das ist die Stelle, an der einen die Microsoft-Intuition am elegantesten reinlegt, denn hier ist nichts kaputt. Keycloak liefert Rollen von allein aus, dafür sorgt ein eingebauter Client Scope, den jeder Client automatisch mitbekommt. Nur liefert Keycloak sie verschachtelt und im Access Token: Realm-Rollen unter realm_access.roles, Client-Rollen unter resource_access.<client>.roles. Entra dagegen legt seine App-Rollen flach einfach in ein Feld namens roles. Beide Systeme sind standardkonform. Beide haben recht. Sie sind sich nur nicht einig, und OIDC schreibt an dieser Stelle nichts vor.

Der Dienst, der einen flachen roles-Claim erwartet, findet also nichts, obwohl alles da ist. Was fehlt, ist ein Mapper, der die Rollen dorthin schreibt, wo der Dienst hinschaut, mitsamt gesetztem Häkchen bei „Add to ID token", das per Default aus ist.

Das ist unangenehmer als ein simples Vergessen, denn es gibt hier keine Fehlermeldung, die auf die Ursache zeigt. Es gibt ein vollständig korrekt konfiguriertes System und ein Token, das die richtige Information am falschen Ort trägt.

Der teuerste Fehler ist nicht der, bei dem etwas fehlt. Es ist der, bei dem alles da ist und nur woanders steht.

Nicht der Name entscheidet, sondern die Tür

Die Frage, die fast jeder aus der Microsoft-Welt irgendwann stellt: Wenn derselbe Benutzername in zwei Realms existiert, wo lande ich beim Login? Woran erkennt Keycloak, wer da kommt?

Die Antwort war für mich der eigentliche Aha-Moment. Keycloak unterscheidet Realms nicht am Benutzernamen, sondern an der URL. Der Realm steht vorher fest, unabhängig davon, wer sich anmeldet.

https://accounts.example.org/realms/isarosc/...     → Login gegen isarosc
https://accounts.example.org/realms/master/...      → Login gegen master
https://accounts.example.org/admin/isarosc/console/ → Admin-Konsole für isarosc
https://accounts.example.org/admin/master/console/  → Admin-Konsole für master

Keycloak sucht nie über Realms hinweg. Eine Anwendung schickt dich zu ihrem konfigurierten Realm, der steckt in ihrem issuer. Sogar die Admin-Konsole gibt es pro Realm, mit lokalen Konten dieses Realms, denen Rollen des realm-management-Clients zugewiesen sind. Nur die Master-Konsole sieht alles.

Deshalb kann derselbe Benutzername in zwei Realms zwei verschiedene Passwörter, Rollen und MFA-Einstellungen haben. Es sind zwei getrennte Identitäten in zwei getrennten Verzeichnissen, die zufällig gleich heißen. Das ist richtig schick.

Nicht der Name entscheidet, sondern welche Deiner eignenen Türen du benutzt.

Und jetzt kommt die Stelle, an der ich beim Schreiben dieses Artikels selbst nochmal ins Grübeln kam. Ich wollte hier eigentlich schreiben: In Entra ist das genauso, die Tenant-ID sitzt ja im Pfad.

Stimmt aber nicht.

Denn die Anmelde-URL, die in der Praxis fast überall steht, ist login.microsoftonline.com/common. Das ist der Standard in Microsofts eigener Authentifizierungsbibliothek, und in /common steckt der Tenant gerade nicht. Entra nimmt dort deinen Benutzernamen entgegen und leitet daraus ab, wohin du gehörst. Home Realm Discovery heißt das. Auf Deutsch: Es fragt dich, wer du bist, und rät dann, wo du hinwillst.

Entra tut also genau das, was ich zwei Absätze weiter oben als Keycloaks Nichtverhalten gefeiert habe. Es kann den Tenant in den Pfad legen, tut es im Default aber nicht.

Das ist kein Fehler von Microsoft, es ist technisch bequem, und für einen Konzern mit Millionen Tenants ist es wahrscheinlich alternativlos. Aber es ist eben auch ein Mechanismus, der eine Entscheidung trifft, die man nicht sieht, keine Transparenz. Keycloak lässt das Raten weg. Der Realm steht sichtbar im Pfad, und wer die falsche Tür nimmt, merkt es sofort, statt irgendwo zu landen, wo er nicht hinwollte.

Ich habe an dieser Stelle zwei Absätze gestrichen, die schon geschrieben waren. So gründlich sitzt das Vokabular 😄

Die eine Design-Entscheidung, die man nicht vermasseln darf

Die häufigste Anfängerfrage lautet sinngemäß: Bekommt jeder Dienst seinen eigenen Realm?

Nein.

So wie man in Entra nicht pro App einen Tenant aufmacht, legt man in Keycloak nicht pro Dienst einen Realm an. Ein Realm, viele Clients:

Realm: isarosc
 ├── Client: matrix       (Chat)
 ├── Client: opencloud    (Dateiablage)
 ├── Client: opentalk     (Videokonferenz)
 ├── Client: opentalk-recorder
 └── Client: website      (CMS-Backend)

Eine Benutzerbasis. Ein Login. Ein Satz Rollen und Gruppen. Echtes Single Sign-On. Ein Realm pro Dienst würde getrennte Nutzerwelten erzeugen und ausgerechnet das SSO zerstören, für das man das Ganze überhaupt aufgebaut hat. Realms sind isoliert, das ist ihr Zweck. Es gibt keine B2B-Gasteinladung von Realm A nach Realm B. Wer Identitäten über Realms teilen will, föderiert sie über Brokering.

Wobei: Wer aktuelles Keycloak fährt, sollte sich das Organizations-Feature ansehen, wohl seit Version 26 an Bord. Es bringt Mandantentrennung innerhalb eines Realms, mit Einladungen und organisationsspezifischen Identity Providern, also ziemlich genau das B2B-Muster, das man aus Entra kennt und oben vermisst hat. Das ändert nichts an der Regel für Realms. Es heißt nur, dass die Antwort auf „wir haben aber externe Partner" nicht mehr automatisch „dann eben Brokering" lautet.

Und jetzt reden wir über Geld

Bis hierhin war das ein Wörterbuch. Jetzt kommt die Rechnung, und sie ist der eigentliche Grund, warum dieser Artikel existiert.

Conditional Access ist in der Microsoft-Welt kein Feature des Produkts. Es ist ein Feature der additiven Lizenz. Wer Richtlinien wie „aus diesem Netz verlange MFA" bauen will, braucht Entra ID P1 💵. Wer risikobasierte Anmeldung will, Identity Protection, also die Dinge, die man heute schlicht Stand der Technik nennt, braucht P2 💰.

Seit dem 1. Juli 2026, das war vor zwei Wochen, kostet P1 7 Dollar pro Nutzer und Monat, P2 10 Dollar. Vorher waren es 6 und 9. Das war Teil der aktuellen breiten Preisrunde über das halbe M365-Portfolio, kein Entra-spezifischer Griff, und ich will natürlich fair bleiben. Es bleibt eine Erhöhung. So erhöht man aber nur, wenn man sich selber sehr sicher ist, dass niemand geht.

Rechne das für einen Verein mit 40 Leuten. Für einen Mittelständler mit 200. Für eine Stadtverwaltung mit 2.000. P2 mal 2.000 mal 12 sind 240.000 Dollar. Jahr für Jahr. Unser Geld. Steuergeld. Das Dienstleistungsdefizit über den großen Tecih lässt grüßen.

Bevor jetzt jemand die Hand hebt: Das ist der US-Listenpreis. In der echten Welt steckt P1 in Business Premium und E3, P2 in E5, es gibt Behördenkonditionen, es gibt Non-Profit-Terms, und der Verein mit 40 Leuten zahlt vermutlich gar nichts. Die reale Rechnung ist also kleiner. Die Suiten jedoch wesentlich teurer. Die Logik ist dieselbe, und das ist der Punkt: Der Betrag steht nicht fest, weil er an anderen Orten von anderen Menschen zu intransparenten Zyklen festgelegt wird.

Und man muss präzise sein, sonst zerlegt einen der erste etwas kundige Leser: MFA selbst kostet in Entra nichts. Security Defaults und Per-User-MFA gibt es kostenlos, Microsoft erzwingt Letzteres inzwischen sogar. Hinter der Lizenzstufe steht nicht das Türschloss. Hinter der Lizenzstufe steht die Regel, wann es zufällt.

Genau das macht die Sache interessanter, nicht harmloser. Denn ein Schloss, das immer und für jeden gleich zufällt, ist im Betrieb unbrauchbar, und wer es ernst meint, braucht Bedingungen: dieser Standort, dieses Gerät, diese Anwendung, dieses Risiko. Verkauft wird also nicht die Sicherheit, sondern ihre Brauchbarkeit. Das ist der elegantere Schnitt, und ich sage das mit einem gewissen Respekt, weil ich weiß, wo solche Schnitte gemacht werden.

Keycloak liefert MFA, WebAuthn, Passkeys, Brute-Force-Detection und frei baubare Authentication Flows. Ohne Pro-Kopf-Lizenz. Ohne Staffel. Ohne Stufe darüber, in der die brauchbaren Bedingungen wohnen.

Nicht das Türschloss ist Premium. Die Regel, wann es zufällt, ist es.

Der Unterschied zwischen den beiden Systemen ist an dieser Stelle also (wie immer bei Open Source) nicht, dass Keycloak wesentlich billiger wäre, oder gar umsonst. Der Unterschied ist, dass bei Keycloak niemand einen Hebel in der Hand hält, an dem er ziehen kann, wenn seine eigenen Shareholdervalue-getriebenen Quartalszahlen es verlangen.

Der Vollständigkeit halber, weil Fairness zum Handwerk gehört: Entra ist schon ganz gut gebaut. Conditional Access ist klickfertig, gut dokumentiert und tut, was draufsteht. Wer eine fertige Richtlinie zusammenklickt, ist schneller fertig als ich mit meinem Flow. Das reicht für die meisten "Cloud-Architekten". An diesem Nachmittag war das richtig spürbar.

Und die Tabelle weiter unten setzt „Authentication Flows" neben „Conditional Access", weil das die nächstgelegene Zeile ist. Ehrlicherweise ist sie keinn 100%iges Match. Ein Auth Flow baut die Anmeldesequenz: Passwort, dann OTP, dann Bedingung. Conditional Access ist eine Policy-Engine, die Signale auswertet, die Keycloak schlicht nicht hat. Gerätekonformität aus Intune zum Beispiel. Man kann Keycloak vieles beibringen, aber man kann ihm kein Signal beibringen, das nirgends entsteht. Wer Conditional Access wegen der Gerätekonformität schätzt, bekommt hier keinen Ersatz, sondern eine andere Antwort auf eine andere Frage. Das gehört gesagt, bevor es jemand im Produktivbetrieb herausfindet.

Nur ist Bequemlichkeit der große goldenen Käfig, den Big Tech um uns gebaut hat. Das habe ich beim DNS-Cluster geschrieben, und es gilt hier nochmal eine Etage höher. Denn Identität ist nicht irgendein Dienst. Sie ist der Generalschlüssel für alle anderen. Wer sie aus der Hand gibt, hat alles andere gleich mitvergeben.

Kein Freibrief

Damit dieser Text nicht in die Falle tappt, die er anderen vorwirft, gehört ein weiterer Abschnitt dazu.

Keycloak gehört nicht niemandem. Es kam von Red Hat, und Red Hat gehört IBM, was ich auch andernorts nicht wirklich für ein Idyll halte. Seit April 2023 aber ist Keycloak CNCF-Incubating-Projekt, also in einer herstellerneutralen Stiftung, und das ist die strukturell genau DIE richtige Antwort, aus demselben Grund, aus dem die Rust Foundation die richtige Antwort war. Aber es ist eine Antwort in Arbeit, kein erreichter Zustand. Der Großteil der Entwicklung wird weiterhin von Menschen geleistet, die dafür von einem Konzern bezahlt werden.

Du betreibst es selbst. Kein verwalteter Dienst. Updates, Backups, Hochverfügbarkeit, Zertifikate, Datenbank. Alles bei dir. Wenn dein Keycloak steht, steht dein Chat, deine Dateiablage und deine Videokonferenz gleich mit, weil sie alle daran hängen. Das ist der Preis, und es ist derselbe Preis wie beim DNS-Cluster: Souveränität heißt eigene Verantwortung, nicht Ersparnis.

Die Admin-Konsole ist keine bunt polierte Schönheit in Flat-Optik. Wer aus dem Entra-Portal kommt, wird Dinge vermissen. Manches ist rau, manches ist schlecht dokumentiert, und für ein paar Einstellungen musst du wissen, wonach du suchst, bevor du sie findest. Willkommen im Club.

Und Keycloak allein macht dich nicht souverän. Ein Identity-Provider im eigenen Rack, der brav alle Dienste in fremden Hyperscaler-Clouds authentifiziert, hat genau gar nichts gewonnen. Das Werkzeug liefert die Möglichkeit. Die Praxis musst du selber leben.

Das Wörterbuch ist der Fluchtwagen

Realm ist Tenant. Client ist App-Registrierung. Rollen sind Rollen, Claims sind Claims, Föderation ist Föderation. Ein einziger Abschnitt Übersetzung, und was eben noch nach einem fremden System aussah, ist ein System, das man seit zwanzig Jahren kennt.

Deshalb ist der Satz „der Wechsel ist zu komplex" so perfekt, so wertvoll für Redmond. Er muss nicht einmal wahr sein. Er muss nur geglaubt werden, und geglaubt wird er verlässlich, weil Fremdheit sich exakt wie eine echte Schwierigkeit anfühlt und weil niemand gern zugibt, dass die eigene Expertise in weiten Teilen aus fremdbestimmten Vokabeln besteht.

Ich habe samals an diesen Vokabeln mitgebaut. Das ist der Grund, warum ich weiß, wie gut sie funktionieren. Und es ist der Grund, warum ich diesen Artikel schreibe: Ein Käfig, dessen Gitterstäbe aus Wörtern bestehen, hält nur so lange, wie man die Übersetzung nicht kennt.

Zwei Seiten. Mehr braucht es nicht.

Sie stehen unten.

Die vollständige Mapping-Tabelle

Ein Wort zur Benutzung: Die Zeilen sind nicht gleich belastbar. Was mit ≈ markiert ist, trägt im Alltag, bricht aber, wenn man sich draufstellt. Die Begründungen stehen oben.

Mini-Glossar

• Realm — abgeschlossener Mandant (≈ Tenant).
• Client — Anwendung, die den Realm zur Anmeldung nutzt (≈ App-Registrierung + Enterprise-App).
• Protocol Mapper — Regel, die Attribute, Rollen oder Gruppen in Token-Claims schreibt (≈ optionale Claims).
• Client Scope — bündelt Mapper und Berechtigungen wiederverwendbar (≈ Scopes).
• Identity Provider (IdP) — externe Anmeldequelle, die Keycloak einbindet (≈ B2B-Föderation).
• User Federation — Anbindung eines Nutzerverzeichnisses wie LDAP oder AD (≈ Entra Connect).
• master-Realm — Verwaltungs-Realm des Servers selbst (kein Entra-Gegenstück).

Dieser Text gehört in eine Reihe zur digitalen Souveränität. Die Sprachebene behandelt Eine Sprache, die niemandem gehört, die Datenebene der Umzug zu OpenCloud, die Basisebene der DNS-Cluster der Rebel Homebase. Identität ist die Ebene, die alle anderen aufschließt. Deshalb steht sie hier.

Bei Fragen: ihr wisst, wie ihr mich bekommt.
→ @axel:pandolin.online (Matrix)