Identity ist selten ein eigenes Projekt. Es wird meistens dann zum Thema, wenn eine dritte Anwendung dazukommt und niemand mehr sagen kann, wo Benutzerkonten eigentlich herkommen.
Typische Ausgangslagen
- Mehrere Anwendungen verwalten ihre Benutzer jeweils selbst.
- Ein Verzeichnisdienst existiert, wird aber nur teilweise als führende Quelle genutzt.
- Eine bestehende SAML-Anbindung soll auf OpenID Connect umgestellt werden, ohne den Betrieb zu unterbrechen.
- Der Identity-Dienst ist zentral geworden, war aber nie für Ausfallsicherheit ausgelegt.
Technische Aufgaben
- Keycloak einrichten, betreiben und in bestehende Landschaften einbinden
- Realms, Clients, Rollenmodelle und Token-Laufzeiten festlegen
- LDAP als führende Quelle für Benutzer und Gruppen anbinden
- Migrationen von SAML zu OIDC planen und schrittweise durchführen
- Bereitstellung und Entfernung von Konten über SCIM automatisieren
- Ausfallverhalten und Betriebsgrenzen dokumentieren, bevor sie geprüft werden
Vorgehen
Vor der Konfiguration steht das Rollenmodell. Wer darf was, und wer entscheidet darüber? Ein technisch sauber aufgesetzter Identity-Dienst mit einem unklaren Rollenmodell verlagert das Problem nur.
Bei Migrationen wird ein Parallelbetrieb eingeplant. Ein Stichtagswechsel für alle Anwendungen gleichzeitig ist selten notwendig und fast immer riskanter als nötig.
Systemkontext
Hochverfügbarkeit ist bei Identity-Diensten keine Konfigurationsoption, sondern eine Architekturentscheidung – insbesondere in Bezug auf Sitzungshaltung und Datenbank. Der Beitrag Keycloak hochverfügbar betreiben beschreibt die Entscheidungen, die dabei anstehen.