Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Refactoring eines Storage Layers am Beispiel von Keycloak

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.

Alexander Schwartz

October 11, 2022
Tweet

More Decks by Alexander Schwartz

Other Decks in Technology

Transcript

  1. Refactoring eines Storage Layers
    am Beispiel von Keycloak
    Software Architecture Alliance | 2022-10-11
    Alexander Schwartz | Principal Software Engineer @ Red Hat

    View full-size slide

  2. Keycloak ist ein erweiterbares
    Customer Identity Access Management
    basierend auf OIDC und SAML.

    View full-size slide

  3. Anmeldung eines Nutzers via Keycloak

    View full-size slide

  4. Externes Verzeichnis speichert nicht alle Daten

    View full-size slide

  5. Session-Daten nur In-Memory halten, aber…

    View full-size slide

  6. Caching von Realm- und User-Daten In-Memory

    View full-size slide

  7. Mehrere Keycloak-Server in einem Datacenter

    View full-size slide

  8. Keycloak-Server in mehreren Datacentern

    View full-size slide

  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

    View full-size slide

  10. Keycloak mit neuem Storage fit machen
    für Erweiterbarkeit, Skalierung und
    Zero-Downtime.

    View full-size slide

  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

    View full-size slide

  12. Datenbankformat für Zero-Downtime in JPA
    Primary Key
    UUID
    JPA Optimistic
    Locking
    Daten als JSONB
    PostgreSQL Generated Columns

    View full-size slide

  13. *Resource
    *Model
    *Provider
    Map*
    Map*Adapter
    Map*Provider
    Branch by Abstraction
    Jpa*Map*
    HotRod*
    LdapMap*
    CHM*

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  16. Testen eines neuen Providers
    ● Testsuite mit Aufrufen auf der *Model-Ebene
    ● Prüfen ob Abfragen funktionieren und Daten richtig gespeichert werden
    ● Lasttests

    View full-size slide

  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

    View full-size slide

  18. Status der Umsetzung

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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?

    View full-size slide

  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

    View full-size slide

  23. Fragen & Antworten

    View full-size slide

  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

    View full-size slide

  25. Alexander Schwartz
    Principal Software Engineer @ Red Hat
    [email protected]
    https://www.ahus1.de
    @ahus1de

    View full-size slide