Keycloak speichert die öffentlichen Credential-Daten eines Passkeys. Der Authenticator oder der Anbieter synchronisierter Passkeys verwaltet den privaten Schlüssel. Der Browser verwendet ihn nur für die hinterlegte Relying Party ID. Diese Bindung verhindert, dass eine gefälschte Domain eine gültige WebAuthn-Signatur erhält.
Ein Passkey-Rollout im Unternehmen ist erst dann verantwortbar, wenn der Verlust eines Smartphones, eine Kontosperre und ein nicht unterstützter Browser über dokumentierte Abläufe gelöst werden. Sonst verlagert sich das Anmelderisiko in improvisierte Credential-Resets beim Support. Die IT-Security-Schulungen behandeln die zugehörigen Themen Identitätsprüfung, Authentifizierung und Zugriffsschutz.
1. Freigegebene Keycloak-Baseline herstellen
Die laufende Instanz liefert ihren exakten Versionsstand über die Keycloak-Kommandozeile. Bei einem Container führst du den Befehl in dem Image aus, das später in Produktion läuft:
/opt/keycloak/bin/kc.sh --versionDie Hauptversionsnummer reicht für eine Freigabe nicht aus. Das Freigabeprotokoll enthält:
- Die vollständige Keycloak-Version einschließlich Patchstand
- Die für Authentifizierung und WebAuthn relevanten Sicherheitsmeldungen
- Die Upgrade-Hinweise für den eingesetzten Ausgangsstand
- Die Kompatibilität eigener Provider, Themes und Event Listener
Die Staging-Umgebung verwendet dieselben Realm-Flows, Reverse-Proxy-Hostnamen und Erweiterungen wie die Produktion. Nach dem Upgrade testet das IAM-Team Registrierung, Anmeldung und Abbruch mit den vorgesehenen Clients. Mit dieser freigegebenen Basis folgt die Konfiguration der WebAuthn-Policy.
2. WebAuthn Passwordless Policy konfigurieren
Die Admin Console trennt die allgemeine WebAuthn Policy von der WebAuthn Passwordless Policy. Die Einstellungen für die passwortlose Anmeldung findest du unter Authentication → Policies → WebAuthn Passwordless Policy. Feldnamen können sich zwischen Keycloak-Versionen unterscheiden, deshalb dokumentiert das Runbook die Bezeichnungen und Werte der tatsächlich installierten Version.
Für auffindbare Credentials definiert WebAuthn drei Vorgaben. Die Admin Console kann diese Werte unter einer Einstellung wie Discoverable credential oder Require Discoverable Credential abbilden:
| Wert | Verhalten |
|---|---|
| required | Der Authenticator muss ein auffindbares Credential erzeugen, andernfalls schlägt die Registrierung fehl |
| preferred | Der Authenticator soll ein auffindbares Credential erzeugen, darf aber auf ein nicht auffindbares Credential ausweichen |
| discouraged | Der Authenticator soll nach Möglichkeit kein auffindbares Credential erzeugen |
Das IAM-Team hält weitere Policy-Werte im Rollout-Dokument fest:
- Die Relying Party ID und den angezeigten Namen
- Die Anforderung an die lokale Benutzerverifikation
- Den Umgang mit Attestation und möglichen AAGUID-Einschränkungen
- Die zugelassenen Authenticator-Typen und Signaturalgorithmen
Die Relying Party ID bindet Credentials an eine Domain. Nach einer Änderung können bereits registrierte Passkeys nicht mehr für die Anmeldung verwendet werden. Die festgelegten Werte bestimmen deshalb auch, welche Anmeldeoberfläche und welche Authenticatoren der Rollout unterstützt.
3. Anmeldeoberfläche und Fallback entwerfen
Conditional UI zeigt auffindbare Passkeys im Autofill-Feld des Browsers an. Dafür benötigt der Benutzer einen passenden Passkey, der Browser muss Conditional Mediation unterstützen und das Anmeldefeld muss den WebAuthn-Autofill-Token enthalten. Bei eigenen Keycloak-Themes gehört dieses HTML-Attribut in den Oberflächentest.
Ein modaler Dialog deckt USB- und NFC-Sicherheitsschlüssel sowie die geräteübergreifende Anmeldung ab. Welche Optionen erscheinen, hängt vom Browser, vom Betriebssystem und vom verfügbaren Authenticator ab. Die Geräte-Matrix prüft beide Oberflächen getrennt.
Bleibt die Passwortanmeldung während der Einführung verfügbar, bleibt auch ihr Phishing-Risiko bestehen. Fehlversuche können außerdem die in Keycloak konfigurierte Brute-Force-Erkennung auslösen. Der Fallback-Test umfasst deshalb die festgelegte Fehlversuchsschwelle, die daraus entstehende Kontosperre und den anschließenden Recovery-Ablauf.
Die Benutzeranleitung zeigt drei getrennte Wege: Autofill über Conditional UI, den modalen Dialog und die Anmeldung mit einem zweiten Gerät. Diese Oberflächen führen zu unterschiedlichen Zweigen im Authentication Flow.
4. Authentication Flow und MFA-Verhalten prüfen
WebAuthn Passwordless bezeichnet eine Anmeldung ohne Passwort. Die interne MFA-Vorgabe entscheidet getrennt davon, ob Besitz des Authenticators und lokale Benutzerverifikation die geforderten Faktoren erfüllen. Diese Entscheidung gehört in das Zugriffskonzept und darf nicht aus dem Namen einer Keycloak-Ausführung abgeleitet werden.
Für Änderungen erstellt das IAM-Team eine Kopie des integrierten Browser-Flows und bindet diese Kopie an den Realm. So bleiben die ursprünglichen Ausführungen als Vergleich erhalten. Anforderungen und Bedingungen im Flow entscheiden, ob nach einer Passkey-Anmeldung ein weiterer Authentifizierungsschritt erscheint.
- Eine erfolgreiche Passkey-Anmeldung endet im vorgesehenen Client
- Ein Abbruch führt zur freigegebenen Auswahl oder zum Fallback zurück
- Registrierungs- und Anmeldefehler erzeugen auswertbare Realm Events
- Die erste Registrierung folgt der freigegebenen Required Action
Die dokumentierten Flow-Zweige liefern die Ausgangspunkte für Recovery, Gerätewechsel und Support-Eskalation.
5. Recovery und Gerätewechsel vorbereiten
Ein zweiter Passkey auf einem anderen vertrauenswürdigen Gerät oder einem Hardware-Sicherheitsschlüssel reduziert die Abhängigkeit von einem einzelnen Authenticator. Synchronisierte Passkeys können innerhalb des jeweiligen Anbieter-Ökosystems auf einem Ersatzgerät erscheinen. Gerätegebundene Passkeys erfordern eine neue Registrierung.
Wenn der Realm Recovery-Codes verwendet, testet das IAM-Team deren Erzeugung, einmalige Nutzung, Aufbewahrung und Widerruf im gebundenen Authentication Flow. Ein administrativer Credential-Reset stützt sich nicht allein auf eine E-Mail-Adresse oder eine bekannte Telefonnummer. Die Support-Fachkraft dokumentiert die Identitätsprüfung, die Freigabe und die Änderung im Ticketsystem sowie in den verfügbaren Admin Events.
Der Support unterscheidet verlorene Geräte, fehlende synchronisierte Credentials, gesperrte Konten und Konten von Personen nach dem Austritt. Für privilegierte Zugänge umfasst das Konzept separat verwaltete Notfallkonten, hinterlegte Hardware-Schlüssel und protokollierte Break-Glass-Zugriffe.
Wenn die Account Console und die nötigen Aktionen freigegeben sind, können Benutzer registrierte Credentials verwalten. Das Team testet das Hinzufügen eines zweiten Passkeys und das Entfernen eines alten Eintrags mit einem Konto ohne Administratorrechte. Aus diesen Recovery-Fällen entsteht die Geräte- und Browser-Matrix.
6. Geräte- und Browser-Matrix aufbauen
Das Team leitet die Testkombinationen aus dem tatsächlichen Gerätebestand der Pilotgruppe ab. Jeder Lauf erfasst die Betriebssystemversion, die Browserversion, den Authenticator-Typ und die verwendete Anmeldeoberfläche. Die folgende Matrix zeigt ein Muster, das an die freigegebenen Clients angepasst wird.
| Kombination | Authenticator | Testfälle |
|---|---|---|
| Windows 11 mit Edge und Chrome | Windows Hello, USB-Sicherheitsschlüssel | Registrierung, Conditional UI, modaler Dialog, Fallback |
| macOS mit Safari und Chrome | Touch ID, synchronisierter Passkey | Anmeldung, Abbruch, Gerätewechsel |
| iOS mit Safari | Plattform-Authenticator | Anmeldung auf demselben und auf einem zweiten Gerät |
| Android mit Chrome | Plattform-Authenticator, NFC-Schlüssel | Registrierung, Recovery, Ersatzgerät |
Zu jeder Kombination gehören auch eine abgebrochene Registrierung, ein nicht verfügbarer Synchronisierungsdienst und ein zuvor entferntes Credential. Die Ergebnisse zeigen, welche Geräte sich für die Pilotgruppe eignen und wo ein Fallback erhalten bleiben muss.
7. Keycloak-Passkeys in Phasen ausrollen
Der Pilot startet mit dem IAM-Team, Keycloak-Administratoren und dem IT-Support. Diese Gruppe bearbeitet später Credential-Verluste und durchläuft deshalb vorab Registrierung, Fallback, Kontosperre und geräteübergreifende Anmeldung.
Die nächste Phase umfasst ausgewählte Fachbereiche, deren Geräte in der Matrix vertreten sind. Eine zentrale Support-Adresse, bebilderte Registrierungsanleitungen und ein dokumentierter Eskalationsweg verhindern voneinander abweichende Reset-Verfahren. Erkenntnisse aus den Tickets ändern bei Bedarf die Policy, den Recovery-Ablauf oder die Gerätefreigabe.
Die unternehmensweite Aktivierung folgt nach drei erfolgreichen Tests: Ein freigegebener Fallback funktioniert, ein zweiter Passkey lässt sich registrieren und der Verlust des primären Geräts endet im dokumentierten Recovery-Prozess. Die Schulungen zur Systemadministration behandeln Keycloak-Betrieb, Updates und Fehleranalyse. Nach der Freigabe zeigen Betriebsdaten, ob die Annahmen aus dem Pilotbetrieb stimmen.
8. Nutzung, Fehler und Support-Aufwand messen
Die Registrierungsquote teilt die Zahl der aktiven Konten mit mindestens einem Passkey durch alle aktiven Konten im betrachteten Pilotbereich. Eine separate Nutzungsquote misst erfolgreiche Passkey-Anmeldungen im Verhältnis zu allen erfolgreichen Anmeldungen derselben Clients und desselben Zeitraums.
- Registrierungsquote: aktive Konten mit mindestens einem registrierten Passkey
- Nutzungsquote: erfolgreiche Passkey-Anmeldungen im Verhältnis zu allen erfolgreichen Anmeldungen
- Fehlerrate: abgebrochene oder fehlgeschlagene Registrierungen und Anmeldungen
- Recovery-Aufwand: Anzahl und Bearbeitungszeit der zugehörigen Support-Tickets
Ein Event Listener kann Realm Events und Admin Events an ein SIEM übertragen. Das Ticketsystem erhält eine eigene Kategorie für Passkey-Fälle, damit das Team Kontosperren, Credential-Verluste und Reset-Vorgänge getrennt auswertet.
Keycloak-, Browser- und Betriebssystem-Updates können Conditional UI, Authenticator-Auswahl oder geräteübergreifende Anmeldung verändern. Das Team wiederholt die betroffenen Matrix-Tests nach solchen Updates sowie nach Änderungen an der Relying Party ID oder der WebAuthn-Policy. Diese Auslöser gehören in die Rollout-Checkliste.
9. Checkliste für den Passkey-Rollout
- Ermittle die produktive Keycloak-Version und den Stand der relevanten Sicherheitsupdates
- Dokumentiere Upgrade-, Registrierungs- und Authentifizierungstests in der Staging-Umgebung
- Lege Relying Party ID, Benutzerverifikation und Authenticator-Vorgaben fest
- Teste Conditional UI, den modalen Dialog und den Passwort-Fallback getrennt
- Registriere einen zweiten Passkey und simuliere den Verlust des primären Geräts
- Schließe die Geräte- und Browser-Matrix mit den freigegebenen Versionen ab
- Schule den IT-Support und dokumentiere den Eskalationsweg
- Definiere Kennzahlen und Auslöser für erneute Kompatibilitätstests
Beginne die abschließende Freigabe mit einem vollständigen Verlusttest. Entferne beim Pilotkonto den primären Authenticator und führe die dokumentierte Wiederherstellung durch. Der Test gilt nur als bestanden, wenn das Konto ohne undokumentierten Administratorzugriff wieder Zugang erhält und alle Änderungen im Ticketsystem sowie in den verfügbaren Ereignissen nachvollziehbar sind.