Keycloak an FreeIPA und Red Hat IdM anbinden

Kurzüberblick

SSO braucht eine reproduzierbare Identity-Plattform, saubere Zertifikate, kontrollierte Clients und nachvollziehbare Federation- oder LDAP-Anbindung.

Der Beitrag baut Keycloak mit Podman beziehungsweise der jeweiligen Integrationsaufgabe Schritt für Schritt auf und zeigt die sicherheitsrelevanten Entscheidungen.

Teams erhalten eine belastbare Basis für SSO, MFA, Federation, zentrale Anmeldung und sichere Anwendungsintegration.

Getestete Umgebung / Validierung

• Stand: September 2026

• Produkt & Version: Keycloak 26.x

• Infrastruktur: getrennte Keycloak-Referenzinstanzen mit Podman, PostgreSQL und TLS

• Sicherheit: Admin-Passwörter, Client-Secrets und interne Tokens werden durch Platzhalter ersetzt.

1. Ausgangslage & Voraussetzungen

Ausgangspunkt ist eine leere oder gezielt getrennte Keycloak-Instanz. DNS, TLS, persistente Volumes, Datenbank, Reverse Proxy und Truststore müssen vor produktiver Nutzung bewusst vorbereitet werden.

2. Schritt-für-Schritt-Anleitung

Die folgenden Schritte beschreiben den praktischen Ablauf. Führe sie in der angegebenen Reihenfolge aus und prüfe nach jedem größeren Abschnitt das Ergebnis.

Dieser zweite Teil setzt auf Keycloak 26.7 mit Podman installieren und die bestehende FreeIPA-Serie auf. Du lernst, wofür Keycloak im Identity-Stack zuständig ist, warum FreeIPA oder Red Hat Identity Management weiterhin das führende Verzeichnis bleiben und wie Keycloak Benutzer über LDAP sichtbar macht.

Kurz gesagt: FreeIPA oder Red Hat IdM verwalten Identitäten, Gruppen, Kerberos, Hostzugriffe, HBAC, sudo und PKI-nahe Betriebsfunktionen. Keycloak übersetzt diese Identitäten in moderne Web- und API-Logins über OIDC, OAuth2 und SAML. Dadurch können Anwendungen wie grommunio, XWiki, OpenProject, ForgeOneCMS oder interne Portale denselben zentralen Identitätsbestand nutzen.

Die Screenshots stammen aus einem isolierten lokalen Keycloak-Lab mit synthetischem LDAP-Verzeichnis. Die Konfiguration orientiert sich an FreeIPA/Red Hat IdM: schreibgeschützte Benutzerquelle, sauberer Realm, LDAP-Sync, keine Klartext-Geheimnisse im Artikel und keine echten Kundendaten.

Was Keycloak in diesem Aufbau tut

Keycloak ist in diesem Szenario nicht dein primäres Benutzerverzeichnis. Es ist die SSO-Schicht vor Anwendungen: Login-Seiten, Sessions, MFA-Flows, Tokens, Claims, Rollenabbildung, OIDC/SAML-Clients und Identity Brokering. Das IdM bleibt zuständig für Benutzerlebenszyklus, Gruppen, Linux-Integration und zentrale Verzeichnisdaten.

Vorher lesen: FreeIPA und Red Hat IdM

Wenn du noch keinen IdM-Server hast, starte mit FreeIPA installieren. Wenn du Architektur, HBAC, sudo, PKI und Keycloak-Rolle im größeren Umfeld verstehen willst, lies danach FreeIPA in großen Umgebungen. Für RHEL-Umgebungen ist Red Hat Identity Management die supportete Enterprise-Variante.

Zielbild der Integration

Der Zielzustand ist bewusst klar getrennt: Benutzer und Gruppen liegen im IdM. Keycloak bindet das Verzeichnis über LDAP oder LDAPS an. Anwendungen sprechen nicht direkt mit FreeIPA, sondern mit Keycloak. Dadurch kannst du MFA, Client-Richtlinien, Token-Lebensdauer, Redirect-URIs und Claim-Mapping zentral verwalten.

FreeIPA / Red Hat IdM
  -> LDAP / LDAPS
  -> Keycloak User Federation
  -> OIDC / SAML Clients
  -> Anwendungen und Portale

Schritt 1: Realm für Anwendungen trennen

Verwende den `master`-Realm nicht als Sammelplatz für Anwendungen. Lege für die Umgebung einen eigenen Realm an, zum Beispiel `forgeone-idm`. Dort konfigurierst du User Federation, MFA und Anwendungs-Clients getrennt von der Keycloak-Administration.

http://127.0.0.1:18080/admin/forgeone-idm/console/

Schritt 2: LDAP-Provider hinzufügen

In Keycloak gehst du zu User Federation und fügst einen LDAP-Provider hinzu. Für FreeIPA und Red Hat IdM ist das der zentrale Einstiegspunkt. Im Lab wurde ein synthetisches LDAP-Verzeichnis verwendet; in Produktion verwendest du deinen echten IdM-FQDN, idealerweise per LDAPS.

http://127.0.0.1:18080/admin/forgeone-idm/console/#/forgeone-idm/user-federation

3. Ergebniskontrolle / Technische Abnahme

4. Typische Fehler & Troubleshooting

• Container startet nicht: Podman-Logs, Environment, Ports, Volumes und SELinux-Kontexte kontrollieren.

• Zertifikate werden nicht vertraut: CA-Kette, Truststore und Reverse-Proxy-Konfiguration kontrollieren.

• LDAP oder Federation liefert keine Benutzer: Bind-DN, Filter, Mapper, Uhrzeit und Gruppenmodell kontrollieren.

5. Fazit & Ausblick

Keycloak ist damit als Identity-Baustein eingeordnet und technisch überprüfbar. Darauf bauen FreeIPA/Red Hat IdM, Federation, Theming und Anwendungsintegration auf.

Schritt 3: Verbindung und Suchbasis setzen

Setze die Verbindung so, dass Keycloak nur den vorgesehenen Benutzerbaum liest. Verwende in Produktion `ldaps://ipa01.example.test:636`, ein eigenes Bind-Konto mit minimalen Leserechten und ein internes CA-Zertifikat im Keycloak-Truststore. Für das lokale Lab wurde `ldap://forgeone-keycloak-ldap:389` genutzt.

http://127.0.0.1:18080/admin/forgeone-idm/console/#/forgeone-idm/user-federation

UI display name: freeipa-example-test
Vendor: Red Hat Directory Server
Connection URL: ldaps://ipa01.example.test:636
Bind DN: uid=svc-keycloak,cn=users,cn=accounts,dc=example,dc=test
Users DN: cn=users,cn=accounts,dc=example,dc=test
Edit mode: READ_ONLY
Import users: ON
Sync registrations: OFF

Schritt 4: TLS und Truststore planen

LDAPS ist nur sauber, wenn Keycloak der CA des IdM-Servers vertraut. Importiere die interne Root- oder Intermediate-CA in den Keycloak-Truststore und teste danach die Verbindung. Ohne korrekte Trust Chain bekommst du später schwer lesbare Login- oder Sync-Fehler.

install -d -m 0750 /opt/keycloak/conf/truststores
cp example-test-root-ca.pem /opt/keycloak/conf/truststores/example-test-root-ca.pem

keytool -importcert -noprompt \
  -alias example-test-root-ca \
  -file /opt/keycloak/conf/truststores/example-test-root-ca.pem \
  -keystore /opt/keycloak/conf/truststores/keycloak-truststore.p12 \
  -storetype PKCS12

Schritt 5: Import, Sync und Schreibmodell entscheiden

Für viele Enterprise-Umgebungen ist `READ_ONLY` der richtige Start: Benutzer werden im IdM gepflegt, Keycloak liest und synchronisiert sie. Passwörter werden nicht nach Keycloak kopiert. Die Authentifizierung läuft gegen das externe Verzeichnis. Änderungen am Benutzerlebenszyklus bleiben im IdM.

Keycloak kann Benutzer importieren oder direkt aus LDAP lesen. Importierte Benutzer verbessern viele Keycloak-Funktionen, erzeugen aber lokale Metadaten. Das ist keine zweite Wahrheit, sondern ein Cache- und Mapping-Modell. Gruppen, Rollen und Claims müssen deshalb bewusst geplant werden.

Schritt 6: Full Sync ausführen

Nach dem Speichern führst du einen Full Sync aus. Im Lab wurden zwei synthetische Benutzer importiert. In Produktion solltest du zuerst mit einer kleinen Suchbasis oder Testgruppe arbeiten und erst danach breiter synchronisieren.

# Lab-Prüfung über kcadm:
/opt/keycloak/bin/kcadm.sh create "user-storage/<provider-id>/sync?action=triggerFullSync" \
  -r forgeone-idm

/opt/keycloak/bin/kcadm.sh get users -r forgeone-idm \
  --fields username,email,firstName,lastName,origin

http://127.0.0.1:18080/admin/forgeone-idm/console/#/forgeone-idm/users

Schritt 7: Benutzer gezielt suchen

Suche nicht blind über sehr große Verzeichnisse. Prüfe gezielt einzelne Benutzer, Attribute und E-Mail-Adressen. Wenn Benutzer fehlen, kontrollierst du Suchbasis, Objektklassen, Filter, Bind-Rechte, Paging und LDAP-Mapping.

http://127.0.0.1:18080/admin/forgeone-idm/console/#/forgeone-idm/users

Schritt 8: Mapper und Gruppen nicht überspringen

Der reine Benutzer-Sync reicht für produktive Anwendungen selten aus. Du brauchst saubere Mapper für Username, E-Mail, Vorname, Nachname, Gruppen und gegebenenfalls Rollen. Bei FreeIPA/Red Hat IdM solltest du Gruppen nicht willkürlich in Keycloak-Rollen verwandeln, sondern ein klares Claim-Modell bauen.

Schritt 9: MFA gehört in den Login-Flow

MFA kann in Keycloak pro Realm, Gruppe oder Flow aktiviert werden. Dadurch bleibt das IdM die Identitätsquelle, während Keycloak den Web-Login absichert. Für Admins sollte MFA verpflichtend sein; für Benutzer hängt es von Schutzbedarf, Anwendung und Risiko ab.

Schritt 10: Betriebschecks

Prüfe nach der Integration nicht nur die Oberfläche. Entscheidend sind Logs, Sync-Ergebnis, Login-Test, Account-Sperren, deaktivierte Benutzer, Gruppenänderungen, Zertifikatskette und die Frage, was passiert, wenn LDAP temporär nicht erreichbar ist.

podman logs --tail=200 forgeone-keycloak-lab | grep -i ldap
curl -fsS https://sso.example.test/realms/forgeone-idm/.well-known/openid-configuration | jq '.issuer'
ldapsearch -H ldaps://ipa01.example.test:636 \
  -D "uid=svc-keycloak,cn=users,cn=accounts,dc=example,dc=test" \
  -W \
  -b "cn=users,cn=accounts,dc=example,dc=test" "(uid=mathias)" uid mail cn

Abschlusscheck

Am Ende sollten Realm, LDAP-Verbindung, Truststore, Bind-Konto, Suchbasis, Importmodell, Sync, Benutzeranzeige, Mapper, MFA-Plan und Betriebschecks nachvollziehbar dokumentiert sein. Erst dann ist Keycloak bereit, Anwendungen über OIDC oder SAML anzubinden.

Nächster Teil der Serie

Der nächste logische Schritt ist Keycloak Federation: ein Keycloak kann einen anderen Keycloak als Identity Provider verwenden. Das ist nützlich, wenn Mandanten, Organisationen oder bestehende SSO-Landschaften getrennt bleiben sollen, aber trotzdem zentral zusammenarbeiten müssen.