FreeIPA vs. Keycloak: Unterschiede, Einsatzbereiche und die richtige Identity-Architektur

Wer Linux-Server, Benutzer und Zugriffsrechte zentral verwalten möchte, stößt häufig auf FreeIPA. Wer Single Sign-on für Webanwendungen benötigt, beschäftigt sich mit Keycloak. Beide Systeme verwalten Identitäten und Authentifizierung, setzen jedoch an unterschiedlichen Schichten an.

Darum ist der Vergleich sinnvoll, obwohl es keinen pauschalen Sieger gibt: FreeIPA organisiert Linux-Identitäten, Hosts und hostnahe Policies. Keycloak stellt moderne Anmeldeprotokolle, Sessions und anwendungsspezifische Claims bereit. Die zentrale Architekturfrage lautet nicht nur „welches Produkt?“, sondern „welche Komponente soll für welche Entscheidung verantwortlich sein?“

Kurzantwort: keine vollständigen Alternativen

FreeIPA und Keycloak überschneiden sich bei Benutzern, Gruppen und Authentifizierung. Die Überschneidung macht sie aber nicht austauschbar. FreeIPA ist eine Linux-zentrierte Identity-Management-Domäne mit LDAP, Kerberos, SSSD-Integration, Hosts und Policies. Keycloak ist ein Identity Provider und Access-Management-System für Webanwendungen und APIs mit OpenID Connect, OAuth 2.0 und SAML 2.0.

FreeIPA allein ist richtig, wenn Linux-Hosts und deren Zugriffsregeln die Aufgabe sind. Keycloak allein ist richtig, wenn Web-SSO auf einer vorhandenen Benutzerquelle oder mit eigenen Benutzern benötigt wird. Beide zusammen sind sinnvoll, wenn Linux und Webanwendungen dieselbe kontrollierte Identitätsquelle nutzen sollen, ohne Betriebssystem- und Anwendungsautorisierung zu vermischen.

Schnelle Entscheidungshilfe

• Linux-Identitäten, Hosts, SSH, HBAC und sudo: FreeIPA.
• Webanwendungen, OIDC, SAML und Single Sign-on: Keycloak.
• Gemeinsame Identitätsquelle für Linux und Webanwendungen: FreeIPA plus Keycloak prüfen.

Was ist FreeIPA?

FreeIPA bündelt einen LDAP-basierten Verzeichnisdienst, Kerberos, Verwaltung für Benutzer, Gruppen, Hosts und Services sowie optionale DNS- und PKI-Funktionen. Linux-Clients werden in die Domäne aufgenommen und verwenden typischerweise SSSD. Der IPA Provider in SSSD versteht neben Identitäten und Authentifizierung auch FreeIPA-spezifische Regeln wie Host Based Access Control, zentrale sudo-Regeln und SELinux User Maps.

• Benutzer und POSIX-Gruppen werden zentral geführt statt auf jedem Linux-System separat.
• Kerberos ermöglicht ticketbasierte Authentifizierung für kompatible Dienste.
• Host-Enrollment bindet Systeme kontrolliert an Realm, Directory und Policies an.
• HBAC beschreibt, welche Benutzer oder Gruppen auf welche Hosts und Services zugreifen dürfen.
• Zentrale sudo-Regeln delegieren administrative Befehle nachvollziehbar an Gruppen und Hostgruppen.
• Integriertes DNS und eine integrierte CA sind verfügbar, müssen aber bewusst in das Betriebsmodell eingeordnet werden.
• Replicas verteilen Directory-, Kerberos- und je nach Rollenzuweisung weitere Dienste für Verfügbarkeit und Wartung.

Für Linux-Administratoren entsteht damit ein konsistentes Modell: Konto, Gruppe, SSH-Schlüssel, Hostzugriff und sudo-Berechtigung lassen sich zentral verwalten, automatisieren und prüfen. Das ist mehr als ein LDAP-Server. Gleichzeitig ist FreeIPA kein allgemeiner OIDC- oder SAML-Identity-Provider für beliebige Webanwendungen. Solche Protokolle gehören nicht zu seinem primären Architekturzweck.

Was ist Keycloak?

Keycloak ist ein Identity- und Access-Management-System für Anwendungen. Es spricht nativ OpenID Connect, OAuth 2.0 und SAML 2.0, verwaltet Browser-Sessions und Tokens und kann Anmeldungen über externe Identity Provider vermitteln. Anwendungen registrieren sich als Clients und erhalten nur die Rollen und Claims, die sie benötigen.

• Single Sign-on für mehrere Webanwendungen und APIs.
• Realm- und Client-Rollen, Protokoll-Mapper, Scopes und anwendungsspezifische Claims.
• Konfigurierbare Authentifizierungsflows und MFA für Anmeldungen, die tatsächlich über Keycloak laufen.
• Identity Brokering zu OIDC-, SAML- und weiteren unterstützten Identity Providern.
• LDAP User Federation mit Import- und Edit-Mode-Entscheidungen, Synchronisierung und Mappern.
• Token-, Refresh-Token- und Session-Laufzeiten als Teil des Sicherheits- und Deprovisioning-Modells.

Keycloak ist deshalb für Nextcloud, GitLab, OpenProject, interne Portale und eigene Anwendungen interessant, sofern die konkret eingesetzte Version eine dokumentierte OIDC- oder SAML-Anbindung bietet. Es ersetzt aber weder das Enrollment von Linux-Hosts noch SSSD, HBAC oder zentrale sudo-Regeln.

FreeIPA und Keycloak im direkten Vergleich

Die Tabelle beschreibt den jeweiligen Kernzweck. Erweiterungen können zusätzliche Integrationen ermöglichen, ersetzen aber nicht automatisch das native Betriebsmodell des anderen Systems.

Wann ist FreeIPA die richtige Wahl?

Ein realistisches Beispiel ist ein Unternehmen mit mehreren Dutzend oder Hunderten Linux-Systemen. Administratoren benötigen einheitliche Konten, SSH-Authentifizierung, zentral gepflegte Gruppen, begrenzte sudo-Rechte und Regeln dafür, wer auf Produktions-, Test- oder Identity-Hosts zugreifen darf. Neue Systeme sollen reproduzierbar per Ansible aufgenommen und beim Offboarding zuverlässig entzogen werden.

Hier ist FreeIPA die passende Kernkomponente. Linux-Hosts konsumieren Identitäten und Policies über SSSD; HBAC verbindet Benutzer- oder Gruppenbezug mit Hostgruppen und Services; sudo-Regeln lassen sich separat modellieren. Kerberos, DNS-Discovery und Zeit-Synchronisierung bilden die technische Vertrauensbasis. Automation kann den gewünschten Zustand für Hosts und Policies wiederholbar ausrollen.

FreeIPA allein reicht aus, wenn keine zentralen Webanwendungen OIDC oder SAML benötigen. Ein zusätzlicher Keycloak-Cluster nur für SSH, sudo oder Linux-Logins würde neue Datenbank-, Proxy-, Zertifikats-, Monitoring- und Recovery-Aufgaben schaffen, ohne diese Hostfunktionen zu verbessern.

Wann ist Keycloak die richtige Wahl?

Eine andere Organisation betreibt mehrere Webanwendungen und eigene APIs. Benutzer sollen sich einmal anmelden, MFA verwenden und anschließend mit gezielt gemappten Rollen auf Anwendungen zugreifen. Externe Partner sollen über einen vorhandenen Identity Provider eingebunden werden, während interne Anwendungen OIDC oder SAML konsumieren.

Hier ist Keycloak die passende Schicht. Es normalisiert Anmeldewege, stellt Tokens aus, verwaltet Sessions und übersetzt Gruppen oder Attribute in Client-Rollen und Claims. Die Benutzer können lokal in Keycloak liegen oder aus einer unterstützten LDAP-Quelle stammen. Welche Variante richtig ist, hängt von Source of Truth, Lifecycle, Schreibrechten und Ausfallanforderungen ab.

Eine zusätzliche FreeIPA-Installation wäre unnötig, wenn keine Linux-Domäne, keine zentralen Host-Policies und kein Bedarf an Kerberos/SSSD bestehen. Keycloak kann mit einem bestehenden LDAP-Verzeichnis föderieren; daraus folgt nicht, dass dieses LDAP durch FreeIPA ersetzt werden muss.

Wann ist FreeIPA plus Keycloak sinnvoll?

Die Kombination ist sinnvoll, wenn ein Unternehmen sowohl Linux-Hosts als auch Webanwendungen betreibt und eine gemeinsame, kontrollierte Identitätsquelle nutzen möchte. FreeIPA bleibt dann die Source of Truth für Linux-Identitäten, Gruppen, Hosts, Kerberos, HBAC und sudo. Keycloak übernimmt Web-SSO, Protokollübersetzung, MFA für Keycloak-Anmeldungen sowie anwendungsspezifische Rollen und Claims.

Textalternative zum Architekturdiagramm

FreeIPA ist die zentrale Quelle für Linux-Benutzer, Gruppen, Hosts und hostnahe Zugriffsregeln. Linux-Systeme fragen diese Informationen über SSSD und Kerberos ab. Keycloak wird über LDAP User Federation an die benötigten Benutzer- und Gruppendaten angebunden. Webanwendungen vertrauen Keycloak über OIDC oder SAML. FreeIPA wird dadurch nicht automatisch zum OIDC-Provider; Keycloak verwaltet dadurch keine HBAC- oder sudo-Regeln. Betriebssystem- und Anwendungsautorisierung bleiben getrennte Entscheidungen.

Federation: die wichtigen technischen Entscheidungen

Benutzerimport oder Laufzeitabfrage

Keycloaks LDAP-Federation kann Benutzer importieren oder, abhängig von Konfiguration und Feature-Grenzen, stärker zur Laufzeit mit der externen Quelle arbeiten. Importierte Benutzer erhalten einen lokalen Keycloak-Datensatz, während die Passwortvalidierung weiterhin gegen LDAP erfolgen kann. Der gewählte Edit Mode bestimmt, ob Attribute nur gelesen, nach LDAP geschrieben oder lokal verwaltet werden. Diese Entscheidung muss je Attribut und Lifecycle geprüft werden; „federiert“ bedeutet nicht automatisch „vollständig bidirektional synchronisiert“.

Gruppen, Rollen und Claims

FreeIPA-Gruppen sind nicht automatisch Keycloak-Rollen. LDAP-Mapper können Gruppen übernehmen, anschließend müssen Realm- oder Client-Rollen und Claims bewusst zugeordnet werden. Ein Token sollte nicht jede Directory-Gruppe enthalten. Client-spezifische Scopes begrenzen Informationsweitergabe, Tokengröße und unbeabsichtigte Berechtigungen.

Passwörter, Kerberos und MFA

Bei LDAP-Federation kann Keycloak Anmeldeinformationen gegen FreeIPA validieren. Kerberos kann zusätzlich als Authentifizierungsweg integriert werden, setzt aber korrektes DNS, Zeit, SPNs, Keytabs und Browser-/Proxy-Verhalten voraus. Entscheidend: Eine MFA-Anmeldung in Keycloak schützt nicht automatisch eine Linux-SSH-Anmeldung. SSH folgt SSSD-, PAM-, Kerberos- und SSH-Konfiguration; MFA muss dort separat entworfen und getestet werden.

Deaktivierung, Tokens und Sessions

Wird ein Konto in FreeIPA deaktiviert, können bereits ausgestellte Access Tokens, Refresh Tokens oder Anwendungssessions bis zu ihren jeweiligen Grenzen weiterwirken. Synchronisationsintervalle, Cache, Token-Laufzeiten, Session-Revoke und Anwendungssessions bestimmen, wann Zugriff tatsächlich endet. Offboarding muss deshalb als Ende-zu-Ende-Prozess getestet werden, nicht nur als Directory-Änderung.

Ausfallverhalten

Ist FreeIPA nicht erreichbar, können SSSD-Caches bestehende Linux-Identitäten je nach Konfiguration zeitweise weiter nutzbar machen; neue oder nicht gecachte Informationen stehen jedoch nicht zuverlässig bereit. Keycloak-Logins gegen einen nicht erreichbaren LDAP-Provider können fehlschlagen, insbesondere wenn Passwortvalidierung oder Benutzerauflösung die externe Quelle benötigt. Bereits ausgestellte Web-Tokens bleiben bis zu Ablauf oder aktiver Prüfung grundsätzlich eine separate Zustandsfrage.

Ist Keycloak nicht erreichbar, sind neue Web-Logins und Token-Erneuerungen betroffen. Bestehende Anwendungssessions oder Tokens können abhängig von Laufzeiten und Validierungsmodell weiter funktionieren. Linux-Anmeldungen über FreeIPA sind davon nicht automatisch betroffen. Diese Trennung ist ein Vorteil, muss aber in Monitoring und Incident-Runbooks sichtbar sein.

Dokumentiert, möglich, getestet oder empfohlen?

• Offiziell dokumentiert: FreeIPA stellt Directory-, Kerberos-, Host-, HBAC-, sudo-, DNS- und PKI-Funktionen bereit; Keycloak dokumentiert OIDC, OAuth 2.0, SAML, Identity Brokering, LDAP User Federation, Kerberos und Authentifizierungsflows.
• Technisch mögliche Integration: Keycloak kann über seinen LDAP-Provider an das von FreeIPA verwendete Directory angebunden und über Mapper auf benötigte Attribute und Gruppen ausgerichtet werden.
• Praktisch bei ForgeOne dokumentiert: Der bestehende Lab-Beitrag „Keycloak an FreeIPA und Red Hat IdM anbinden“ zeigt LDAP-Federation, LDAPS, Sync und Benutzerauflösung. Dieser Vergleich behauptet keinen zusätzlichen neuen Lab-Test.
• Architekturempfehlung: FreeIPA als Source of Truth für Linux-Identitäten und Keycloak als Web-SSO-Schicht reduziert doppelte Pflege. Das ist eine Empfehlung, keine zwingende Produktvorgabe; bestehende Directories und Governance können zu einem anderen Zielbild führen.

Häufige Fehler bei der Auswahl von FreeIPA und Keycloak

• Keycloak als Ersatz für Linux-Hostverwaltung behandeln. Empfehlung: Host-Enrollment, SSSD, HBAC und sudo in FreeIPA oder einer gleichwertigen Linux-IdM-Schicht belassen.
• FreeIPA als vollständigen Ersatz für modernes Web-SSO betrachten. Empfehlung: Für OIDC, OAuth 2.0 und SAML einen dafür ausgelegten Identity Provider verwenden.
• Benutzer unabhängig in beiden Systemen pflegen. Empfehlung: Eine Source of Truth und klare Ownership für Attribute, Passwörter und Deprovisioning festlegen.
• LDAP-Gruppen ungeprüft mit Keycloak-Rollen gleichsetzen. Empfehlung: Mapper, Scopes und Client-Rollen nach Least Privilege modellieren.
• MFA-Wirkung über Protokolle hinweg überschätzen. Empfehlung: Web-SSO, SSH, Kerberos und lokale Recovery-Zugänge separat testen.
• Federation mit vollständiger bidirektionaler Synchronisierung verwechseln. Empfehlung: Importmodus, Edit Mode, Sync-Richtung und Konfliktverhalten dokumentieren.
• Hochverfügbarkeit nur für eine Komponente planen. Empfehlung: FreeIPA-Replicas, Keycloak-Instanzen, Datenbank, DNS, Reverse Proxy und abhängige Netze gemeinsam betrachten.
• Backup und Disaster Recovery nur auf VM-Snapshots reduzieren. Empfehlung: anwendungskonsistente Backups und getestete Wiederanläufe für beide Systeme planen.
• Die Komplexität der Kombination unterschätzen. Empfehlung: nur kombinieren, wenn gemeinsame Identitäten einen messbaren Betriebs- oder Governance-Vorteil bringen.

Betrieb, Sicherheit und Hochverfügbarkeit

FreeIPA betreiben

FreeIPA benötigt verlässliche DNS-Auflösung, konsistente Hostnamen und Zeit-Synchronisierung, weil Kerberos empfindlich auf Namens- und Zeitfehler reagiert. Replicas erhöhen Verfügbarkeit und erlauben Wartung, ersetzen aber kein Backup: fehlerhafte Löschungen oder Konfigurationen können repliziert werden. CA-Rollen, Zertifikatslebenszyklen, Replikationstopologie und DNS-Discovery gehören in Monitoring und Runbooks.

SSSD-Caching kann bekannte Benutzer und Regeln bei kurzen Störungen abfedern, ist aber keine pauschale Offline-Garantie. Cache-Laufzeiten, gecachte Credentials, HBAC-Auswertung und der konkrete Dienst bestimmen das Verhalten. Restore-Verfahren müssen Version, Rollen und Replikationszustand berücksichtigen und regelmäßig isoliert geprobt werden.

Keycloak betreiben

Keycloak benötigt eine unterstützte, hochverfügbare Datenbank, TLS, korrekt konfigurierte Hostnamen und einen Reverse Proxy, der Forwarded Header kontrolliert setzt. Für Hochverfügbarkeit werden mehrere Keycloak-Instanzen und das dokumentierte Cluster-/Cache-Modell geplant. Realm-Konfiguration, Clients, Mapper, Authentifizierungsflows und Signing Keys gehören in Backup-, Export- und Recovery-Überlegungen.

Token- und Session-Laufzeiten beeinflussen Sicherheit, Verfügbarkeit und Offboarding. Zu lange Laufzeiten verzögern den Entzug, zu kurze Laufzeiten erhöhen die Abhängigkeit von Keycloak. Admin-Endpunkte, Management-Port, Datenbankzugriff und Proxy-Grenzen müssen getrennt geschützt werden.

Die Kombination betreiben

Die Kombination fügt eine Federation-Abhängigkeit hinzu. Neue Web-Logins können sowohl von Keycloak als auch von FreeIPA abhängen; bestehende Web-Tokens haben einen eigenen Lebenszyklus. Neue Linux-Anmeldungen hängen von FreeIPA, Netzwerk und Cache ab, nicht von Keycloak. Gruppenänderungen müssen durch Federation, Mapper und Token-Erneuerung bis zur Anwendung gelangen. Genau diese Kette gehört in funktionale Tests und Alarmierung.

FreeIPA, Keycloak oder beides?

• Zentrale Linux-Serververwaltung mit SSH, HBAC und sudo: FreeIPA.
• Web-SSO für mehrere Anwendungen und APIs: Keycloak.
• Linux-Hosts und Web-SSO mit gemeinsamer Identitätsquelle: FreeIPA plus Keycloak prüfen.
• Bestehendes LDAP und ausschließlich Web-SSO: Keycloak mit dem vorhandenen LDAP anbinden, bevor eine zusätzliche FreeIPA-Domäne geplant wird.
• Wenige lokale Anwendungen ohne zentralen IAM-Bedarf: zusätzliche Identity-Infrastruktur kritisch hinterfragen.

Die Kombination ist nicht automatisch die beste Wahl. Sie lohnt sich, wenn gemeinsame Identitäten, konsistentes Offboarding und klare Governance den zusätzlichen Betrieb von Federation, Datenbank, Proxy, Monitoring, Backups und Recovery rechtfertigen.

Digitale Souveränität braucht Betriebskompetenz

FreeIPA und Keycloak sind Open Source, können selbst betrieben werden und nutzen offene Standards. Das unterstützt Kontrolle über Identitäten und reduziert unnötige Abhängigkeit von proprietären Cloud-Diensten. Selbstbetrieb bedeutet aber auch eigene Verantwortung für Hardening, Updates, Schlüssel, Zertifikate, Backups, Restore-Tests, Monitoring und Incident Response.

Digitale Souveränität entsteht daher nicht allein durch die Lizenz. Sie entsteht durch dokumentierte Verantwortlichkeiten, reproduzierbare Automation, getestete Recovery-Pfade und die Fähigkeit, Komponenten kontrolliert zu aktualisieren oder zu ersetzen. Eine offene Architektur bleibt nur dann souverän, wenn das Team sie sicher betreiben kann.

ForgeOne-Praxisbezug

ForgeOne betrachtet Identity-Architektur zusammen mit Enterprise Linux, SSSD, Kerberos, LDAP, Keycloak, Ansible und Plattformintegration. Für eine tragfähige Entscheidung werden Source of Truth, Protokolle, Autorisierungsgrenzen, Lifecycle, Ausfallverhalten und Betriebsverantwortung gemeinsam geplant. Die bestehenden FreeIPA- und Red-Hat-IdM-Inhalte zeigen die Linux-Seite; die Keycloak-Seite ordnet Web-SSO und Federation ein.

Zur Vertiefung dokumentiert ForgeOne die praktische Anbindung von Keycloak an FreeIPA und Red Hat IdM sowie die Enterprise-Architektur mit HBAC, sudo und Keycloak. Für das übergreifende Zielbild sind außerdem Security & Identity, Linux & Infrastruktur, Ansible und digitale Souveränität relevant.

Fazit

FreeIPA und Keycloak beantworten unterschiedliche Fragen. FreeIPA ordnet Linux-Identitäten, Hosts und hostnahe Policies. Keycloak verbindet Anwendungen über moderne Protokolle, Sessions und Claims. Wer nur eine dieser Aufgaben hat, sollte nicht automatisch beide Plattformen betreiben. Wer beide Aufgaben hat, kann sie über eine klar begrenzte Federation verbinden.

Die belastbare Architektur trennt Benutzerquelle, Authentifizierungsprotokoll und Autorisierung. Sie dokumentiert außerdem, wie Deaktivierung, Ausfälle, Tokens, Caches, Backups und Recovery tatsächlich funktionieren. Erst dann wird aus zwei leistungsfähigen Open-Source-Produkten ein beherrschbares Identity-System.