Refactoring eines Storage Layers am Beispiel von Keycloak

Keycloak ist eine Open Source Lösung für Identity und Access Management, die seit vielen Jahren weltweit in großen und kleinen Installationen eingesetzt wird.Von Anfang an unterstütze es relationalen Datenbanken via JPA/Hibernate. Über die Zeit kamen weitere Speichermöglichkeiten für Caching und ein In-Memory-Grid dazu, außerdem wurden Directory-Dienste wie LDAP integriert. Mit der Zeit verwoben sich die verschiedenen Bereiche, so dass neue Funktionen schwieriger umzusetzen waren.Dieser Vortrag zeichnet die Aktivitäten auf der Architektur- und Technik-Ebene nach, mit denen die Bereiche entflochten und eine neue, flexible Storage-Struktur erstellt wurde. Diese ermöglicht unter anderem Zero-Downtime-Upgrades und skalierbare Installationen.

Transcript

1. Refactoring eines Storage Layers am Beispiel von Keycloak Software Architecture Alliance | 2022-10-11 Alexander Schwartz | Principal Software Engineer @ Red Hat
2. Keycloak ist ein erweiterbares Customer Identity Access Management basierend auf OIDC und SAML.
3. Anmeldung eines Nutzers via Keycloak
4. Externes Verzeichnis speichert nicht alle Daten
5. Session-Daten nur In-Memory halten, aber…
6. Caching von Realm- und User-Daten In-Memory
7. Mehrere Keycloak-Server in einem Datacenter
8. Keycloak-Server in mehreren Datacentern
9. Herausforderung: Uneinheitlichkeit und Komplexität • Daten verteilt auf Datenbank, externe Verzeichnisse und Infinispan • Daten als Kopie in der Datenbank oder als Cache in Infinispan • Zugriff auf User-Daten über users(), userLocalStorage(), userCache(), userStorageManager() und userFederatedStorage() • Setup von Keycloak benötigt immer Infinispan, da bestimmte Daten nur dort gespeichert werden • Keycloak-Upgrades erfordern eine Downtime, Rollback nur mit Datenbank-Restore
10. Keycloak mit neuem Storage fit machen für Erweiterbarkeit, Skalierung und Zero-Downtime.
11. Zero-Downtime • Schema-Migrationen ohne Stillstand • Zwei benachbarte Keycloak-Versionen können auf den gleichen Daten laufen, dadurch Test und Rollback möglich KC Version A: Schreibt Version N, liest Storage Version 1…N+1 KC Version B: schreibt Version N+1, liest Storage Version 1…N+2
12. Datenbankformat für Zero-Downtime in JPA Primary Key UUID JPA Optimistic Locking Daten als JSONB PostgreSQL Generated Columns
13. *Resource *Model *Provider Map* Map*Adapter Map*Provider Branch by Abstraction Jpa*Map* HotRod* LdapMap* CHM*
14. Implementieren eines neuen Providers Class Responsibilities Collaborators JpaMapStorageProviderFactory Stellt Verbindung zu Datenbank her über die JPA EntityManagerFactory JpaMapStorageProvider Eine Instanz pro Keycloak Session/Transaktion JpaMapStorageProviderFactory Jpa*MapKeycloakTransaction Eine Instanz pro Entity-Type in einer Session Map*Provider JpaModelCriteriaBuilder Mapping einer abstrakten Abfrage auf JPQL Jpa*MapKeycloakTransaction
15. Bewertung des Ansatzes Vorteile: • Die Felder einer Entity sind dem MapStore erst einmal egal • Interface für eine *Transaction ist überschaubar (create / read / delete) • Fachlichkeit wird in *Model abgebildet Herausforderungen: • Felder nach denen gesucht wird müssen bekannt sein • Abfragen lassen sich je nach Store ggf. nur unvollständig abbilden • Nicht alles lässt sich auf das Interface abbilden, z. B. Authentifikaiton für Kerberos
16. Testen eines neuen Providers • Testsuite mit Aufrufen auf der *Model-Ebene • Prüfen ob Abfragen funktionieren und Daten richtig gespeichert werden • Lasttests
17. Zukunft: Tree Store • Manche Stores (z. B. LDAP) können nicht alle Attribute speichern (partial store) • Fehlende Attribute werden in in einem anderen Store (native store, z. B. JPA) abgelegt, andere Attribute werden dort ggf. als Cache abgelegt
18. Status der Umsetzung
19. Erfahrungen • Keycloak 19 enthält MapStore für JPA/PostgreSQL, HotRod und ConcurrentHashMap • Keycloak 20* soll voraussichtlich JPA/CockroachDB, Tree Store und File Store unterstützen • Keycloak 21* soll voraussichtlich LDAP und Garbage Collection unterstützen * https://www.keycloak.org/2022/07/storage-map.html
20. Architekturänderung • Alter Code setzt einen Cache voraus, dadurch sehr viele Zugriff auf den Store => Caching innerhalb einer Session implementieren • Viele Entitäten in der JPA Session machen den Zugriff langsam => Read-Only Entitäten in der Session, weniger Entitäten in der Session
21. Erste Schemaänderung: Nutzername Beim Nutzernamen soll die Groß-/Kleinschreibung beachtet werden • Wie speichere ich die Daten und brauche ich eine Schema-Änderung? • Was passiert, wenn die neue Version alte Daten liest? • Was passiert, wenn die alte Version neue Daten liest und im alten Format schreibt?
22. Zwischenfazit • Interface für den Physical Store erleichtert neue Store-Implementierungen • Stores für verschiedene Entitäten frei kombinierbar • Neue suchbare Felder im logischen Modell erfordern Änderungen an jedem physischen Store • Zero-Downtime ist eine optionale Eigenschaft des Physical Stores • Testsuite und Beispiele existieren • Dokumentation existiert zur Zeit nur als Javadoc und in Form der ursprünglichen Konzepte
23. Fragen & Antworten
24. • Keycloak X - Storage - High-level architecture https://github.com/keycloak/keycloak- community/blob/main/design/keycloak.x/storage-architecture.md • Keycloak X - Storage / Persistence layer https://github.com/keycloak/keycloak- community/blob/main/design/keycloak.x/storage-persistence.md • „New storage for Keycloak” @ DevConf.cz https://devconfcz2022.sched.com/event/siGK/new-storage-for-keycloak Links
25. Alexander Schwartz Principal Software Engineer @ Red Hat aschwart@redhat.com https://www.ahus1.de @ahus1de