SSO mit Keycloak und Authentik: Self-hosted Identity für den Mittelstand

Key Takeaways

• Single Sign-On reduziert Passwort-Risiken und Helpdesk-Aufwand gleichzeitig
• Keycloak und Authentik sind die zwei reifen Open-Source-Alternativen zu kommerziellen IDaaS-Lösungen
• Self-hosted Identity schafft volle DSGVO-Kontrolle ohne Cloud-Abhängigkeit
• NIS-2 fordert Zugriffskontrolle und Protokollierung — beides liefern beide Produkte nativ
• Integration mit Microsoft 365 und Active Directory ist produktionsreif und gut dokumentiert

Warum Identity Management für KMU kein Luxus mehr ist

Mittelständische Unternehmen mit 50 bis 500 Mitarbeitenden haben oft dasselbe Problem: Jeder Dienst hat seine eigenen Zugangsdaten. Das ERP-System läuft mit einer Benutzerdatenbank, das CRM mit einer anderen, das VPN wieder separat — und Microsoft 365 obendrauf. Das Ergebnis sind schwache oder wiederverwendete Passwörter, ein überlasteter Helpdesk und keine zentrale Sicht darauf, wer wann auf was zugegriffen hat.

Genau hier setzt Single Sign-On (SSO) an. Mit einer zentralen Identity-Plattform authentifiziert sich ein Benutzer einmal und erhält danach kontrollierten Zugang zu allen verbundenen Diensten — ohne erneute Passworteingabe. Das klingt nach Enterprise-Infrastruktur, ist aber mit den richtigen Open-Source-Werkzeugen auch für KMU ohne dediziertes Security-Team realisierbar.

NIS-2 macht das Thema zusätzlich dringend: Artikel 21 der Richtlinie fordert explizit Maßnahmen zur Zugriffskontrolle und zur Authentifizierung. Wer keine zentrale Identity-Verwaltung hat, kann diese Anforderung kaum nachweisbar erfüllen. Und DSGVO-Konformität bedeutet konkret: Wenn Ihre Nutzerdaten bei einem US-amerikanischen IDaaS-Anbieter liegen, haben Sie ein Drittland-Transfer-Problem, das Sie mit einer Self-hosted-Lösung von vornherein vermeiden.

Die zwei Platzhirsche: Keycloak und Authentik im Vergleich

Keycloak

Keycloak ist ein Open-Source Identity- und Access-Management-System, ursprünglich von JBoss entwickelt und seit Jahren unter dem Dach von Red Hat in der Enterprise-Welt etabliert. Es unterstützt OpenID Connect (OIDC), OAuth 2.0, SAML 2.0 und LDAP-Federation nativ.

Stärken:

• Extrem feingranulare Konfiguration über das Realm-Konzept mit Policies und Authentication Flows
• Sehr ausgereifte SAML-Unterstützung für ältere Enterprise-Anwendungen
• Große Community, umfangreiche Dokumentation, viele fertige Integrationen
• Produktionsreif für Hochverfügbarkeits-Szenarien im Cluster-Betrieb

Schwächen:

• Administrationsinterface nicht intuitiv für Einsteiger — Lernkurve ist steil
• Java-basiert: höherer Ressourcenbedarf, längere Startzeiten als Python-basierte Alternativen
• Konfigurationsfehler in Authentication Flows sind leicht möglich und können gravierende Sicherheitslücken erzeugen

Authentik

Authentik ist ein neueres Projekt, geschrieben in Python/Django mit einem modernen React-Frontend. Es positioniert sich als Identity Provider mit Fokus auf Flexibilität und Bedienbarkeit und ist besonders bei DevOps-Teams beliebt, die Infrastructure-as-Code bevorzugen.

Stärken:

• Deutlich intuitiveres Admin-UI mit klarer Informationsarchitektur
• Authentication Flows als grafisch konfigurierbares Konzept — Abläufe lassen sich ohne tiefes Framework-Wissen anpassen
• Bessere Docker- und Kubernetes-Integration durch Python-Stack und kleinere Images
• Eingebaute SCIM-Unterstützung für automatisiertes User-Provisioning

Schwächen:

• Kleinere Community als Keycloak — manche Randfragen bleiben länger offen
• SAML-Unterstützung vorhanden, aber bei komplexen Enterprise-SAML-Szenarien weniger ausgereift
• Bei sehr komplexen LDAP-Hierarchien (verschachtelte OUs, Cross-Domain) schneller an Grenzen

Welches System passt für welchen KMU-Kontext?

Kriterium	Keycloak	Authentik
Team mit Java/Enterprise-Erfahrung	Ja	Nein
DevOps-/Docker-affines Team	bedingt	Ja
SAML für Legacy-Apps zwingend	Ja	bedingt
Schnelle Ersteinrichtung	Nein	Ja
Kubernetes-nativer Betrieb	möglich	bevorzugt
Hochverfügbarkeit mit Clustering	Ja	möglich

Für einen typischen Mittelstandsbetrieb mit Active Directory, Microsoft 365 und einer Handvoll SaaS-Anwendungen ist Authentik oft der schnellere Einstieg. Keycloak ist die bessere Wahl, wenn Legacy-SAML-Anwendungen oder komplexe Policy-Regeln zwingend erforderlich sind.

DSGVO und NIS-2: Was Self-hosted Identity konkret bedeutet

Der entscheidende Unterschied zu kommerziellen IDaaS-Lösungen wie Okta, Azure AD B2C oder Auth0: Bei Self-hosted Identity verlassen Benutzerdaten, Authentifizierungslogs und Token nie Ihre Infrastruktur. Das ist kein Marketing-Argument, sondern ein technischer Fakt mit rechtlicher Relevanz.

DSGVO-Aspekte:

• Keine Drittland-Datenübertragung — bei EU-Hosting bleiben alle Daten im EU-Rechtsraum
• Vollständige Kontrolle über Löschfristen und Datenportabilität ohne Abhängigkeit von Export-APIs eines Anbieters
• Klare Datenzuordnung im Verarbeitungsverzeichnis nach Art. 30 DSGVO
• Keine AGB-Änderungen eines SaaS-Anbieters, die plötzlich neue Verarbeitungszwecke erlauben

NIS-2-Aspekte nach Artikel 21:

• Zugriffskontrolle nachweisbar: Jeder Authentifizierungsvorgang wird protokolliert und kann auditiert werden
• Multi-Faktor-Authentifizierung für alle verbundenen Dienste zentral erzwingbar
• Privileged Access Management: Admin-Accounts können separat in eigenen Realms oder mit verschärften Policies behandelt werden
• Audit-Logs bleiben unter eigener Kontrolle — keine Abhängigkeit von SaaS-Exportfunktionen mit fraglicher Vollständigkeit

Praktische Integration: Active Directory und Microsoft 365

Die häufigste Frage in KMU-Umgebungen lautet: Wie verbindet sich Keycloak oder Authentik mit dem bestehenden Active Directory und Microsoft 365?

Active Directory als Identity-Quelle einbinden

Beide Systeme können Active Directory oder LDAP allgemein als Benutzerquelle nutzen. Das bedeutet: Benutzer werden nicht doppelt angelegt, sondern aus dem AD synchronisiert oder per LDAP-Lookup zur Laufzeit authentifiziert.

Authentik — LDAP-Outpost (Beispiel docker-compose.yml):

services:
  authentik-ldap:
    image: ghcr.io/goauthentik/ldap
    environment:
      AUTHENTIK_HOST: https://authentik.intern.example.com
      AUTHENTIK_TOKEN: ${AUTHENTIK_BOOTSTRAP_TOKEN}
    ports:
      - "389:3389"
      - "636:6636"

Über den eingebauten LDAP-Outpost stellt Authentik selbst einen LDAP-Dienst bereit — ideal für Anwendungen, die kein OIDC oder SAML sprechen, aber LDAP-Bind unterstützen.

Keycloak — AD-Federation: In Keycloak wird AD über einen User Federation Provider eingebunden. Die Konfiguration erfolgt unter Realm Settings > User Federation > Add provider > Active Directory. Die Option Import Users sorgt dafür, dass Benutzer beim ersten Login in Keycloak angelegt werden — ohne vollständige Vorab-Kopie aller AD-Daten.

Microsoft 365 als Service Provider anbinden

Microsoft 365 kann als SAML Service Provider konfiguriert werden, wobei Keycloak oder Authentik die primäre Authentifizierung übernehmen. In Azure AD wird unter Enterprise Applications > New Application > Non-gallery application die SAML-Integration konfiguriert.

Die SAML-Metadaten-URL in Authentik folgt dem Muster:

https://authentik.intern.example.com/api/v3/providers/saml/<provider-id>/metadata/

Diese URL liefert das SAML-Metadaten-XML, das direkt in Azure AD importiert werden kann. Microsoft übernimmt daraus automatisch Entity-ID, SSO-URL und das Signing-Zertifikat.

Wichtiger Hinweis zur Hochverfügbarkeit: Bei vollständiger SAML-Federation übernimmt Ihre Self-hosted-Lösung die Authentifizierung für Microsoft 365. Ein Ausfall des Identity Servers bedeutet, dass sich Benutzer nicht mehr bei Microsoft 365 anmelden können. Redundanz ist hier keine optionale Ergänzung, sondern betriebliche Pflicht.

Security-Hardening: Was Out-of-the-Box oft fehlt

Beide Systeme sind mächtig — aber fehlkonfiguriert auch gefährlich. Folgende Punkte werden in der Praxis häufig übersehen.

Brute-Force-Schutz aktivieren

Keycloak: Unter Realm Settings > Security Defenses > Brute Force Detection aktivieren. Die Default-Werte sind oft zu tolerant. Empfehlung: Max Login Failures auf 5 setzen, Wait Increment auf 30 Sekunden.

Authentik: Über Policies > Password Policy und zusätzlich Reputation Policies für IP-basiertes Rate-Limiting konfigurieren.

Token-Laufzeiten prüfen

Zu lange Access-Token-Laufzeiten sind ein klassisches Sicherheitsproblem. Empfohlene Keycloak-Realm-Einstellungen für KMU:

Access Token Lifespan:  300 Sekunden  (5 Minuten)
SSO Session Idle:      1800 Sekunden  (30 Minuten)
SSO Session Max:      36000 Sekunden  (10 Stunden)
Refresh Token Max Reuse: 0            (kein Reuse)

MFA für alle Benutzer erzwingen

Das wichtigste Sicherheitsfeature — und standardmäßig nicht aktiviert. In Authentik wird ein MFA-Stage über Flows > default-authentication-flow hinzugefügt. In Keycloak setzt man unter Authentication > Flows > Browser den OTP-Step auf Required. Beide Systeme unterstützen TOTP (Google Authenticator, Aegis) und WebAuthn/FIDO2.

Logging und SIEM-Integration mit Wazuh

Authentifizierungslogs sind für NIS-2-Compliance und Incident Response essenziell. Beide Systeme können strukturierte Logs an externe SIEM-Systeme wie Wazuh forwarden. Authentik schreibt JSON-Logs, die Wazuh via Filebeat einliest. Eine praxisnahe Custom-Rule für Brute-Force-Erkennung:

<rule id="100200" level="10">
  <if_sid>0</if_sid>
  <field name="authentik.event">login_failed</field>
  <description>Authentik: Fehlgeschlagener Login-Versuch</description>
  <group>authentication_failed,identity</group>
</rule>

<rule id="100201" level="14" frequency="5" timeframe="120">
  <if_matched_sid>100200</if_matched_sid>
  <same_field>authentik.client_ip</same_field>
  <description>Authentik: Brute-Force-Angriff erkannt (5 Fehler in 2 Minuten)</description>
  <group>authentication_failures,attack,identity</group>
</rule>

Diese Regel erzeugt bei fünf fehlgeschlagenen Logins von derselben IP innerhalb von zwei Minuten einen Alert der Kritikalitätsstufe 14 — hoch genug für eine automatische Eskalation.

Deployment-Empfehlung: Schrittweiser Aufbau für den Mittelstand

Für einen strukturierten Einstieg ohne Big-Bang-Migration hat sich folgende Phasenplanung bewährt:

Phase 1 — Fundament (Woche 1–2):

• Authentik auf dediziertem Server oder in Kubernetes deployen
• LDAP-Anbindung an bestehendes Active Directory einrichten und testen
• Erste OIDC-Anwendung (z. B. Gitea, Nextcloud, Grafana) anbinden
• MFA für alle Administratoren aktivieren, danach für alle Benutzer ausrollen

Phase 2 — Microsoft-Integration (Woche 3–4):

• SAML-Federation mit Microsoft 365 zunächst mit einer Pilotgruppe testen
• Rollback-Verfahren dokumentieren und testen, bevor der Rollout auf alle Benutzer erfolgt
• SSO-Session-Policies an Unternehmensrichtlinien anpassen

Phase 3 — Security und Compliance (Woche 5–6):

• Wazuh-Integration für Login-Monitoring konfigurieren
• Alerting-Regeln für Brute-Force und ungewöhnliche Login-Zeiten aktivieren
• Technische Dokumentation für NIS-2-Nachweise erstellen

Ressourcenbedarf: Ein Authentik-Deployment für 100–200 Benutzer läuft stabil auf einer VM mit 4 vCPUs und 8 GB RAM. Keycloak benötigt aufgrund der JVM-Basis mehr: 4 vCPUs und 12–16 GB RAM sind für produktive Umgebungen empfohlen.

Häufige Fallstricke und wie man sie vermeidet

Admin-Interface im Internet exponiert: Das Admin-UI beider Systeme darf niemals direkt aus dem Internet erreichbar sein. Betrieb hinter VPN oder mit IP-Whitelist — kein Verhandlungsthema.

Kein Backup der Realm-Konfiguration: Keycloak und Authentik speichern die gesamte Konfiguration in der Datenbank. Ein täglicher Export der Realm- und Flow-Konfiguration gehört in die Backup-Routine — nicht erst nach dem ersten Ausfall.

Self-signed Certificates in der Produktion: In vielen Tutorials wird der schnelle Weg mit selbst signierten Zertifikaten gezeigt. In der Produktion führt das zu Problemen mit SAML-Signaturen und Browser-Warnungen. Let's Encrypt oder eine interne PKI sind Pflicht.

Keine Hochverfügbarkeit eingeplant: Wenn SSO der einzige Authentifizierungsweg für Microsoft 365 ist und der Identity-Server ausfällt, steht das Unternehmen. Redundanz ist kein Overhead, sondern Teil der Betriebsanforderung.

Fazit: Self-hosted Identity ist für KMU realistisch umsetzbar

Keycloak und Authentik sind produktionsreife Lösungen, die auch ohne Enterprise-IT-Abteilung betreibbar sind — vorausgesetzt, die initiale Einrichtung erfolgt sorgfältig und mit dem richtigen Know-how. Der Vorteil gegenüber SaaS-Lösungen ist real: volle Datenkontrolle, DSGVO-konforme Verarbeitung ohne Drittland-Transfer und eine vollständige Audit-Trail-Basis für NIS-2-Nachweise.

Der Betrieb einer eigenen Identity-Plattform bedeutet aber auch Verantwortung für Updates, Backup, Monitoring und Incident Response. Gerade für KMU ohne dediziertes Security-Team ist es sinnvoll, die Log-Auswertung und das Alerting an ein spezialisiertes Team auszulagern. Das Vyrex Security Team verbindet Self-hosted Identity-Infrastruktur auf Basis von Keycloak und Authentik mit einem Managed SIEM auf Wazuh-Basis — inklusive vorkonfigurierter Erkennungsregeln für Authentifizierungsangriffe, Anomalieerkennung und Compliance-Reporting für NIS-2. So behalten Sie die Datenkontrolle, ohne den Monitoring-Aufwand intern schultern zu müssen.