Learning Friday Projekt - Hogarama
  • Hogarama
  • Learning Friday

Simplify Hogarama - Security

Hogarama – ein ewiger Quell für neue Ideen, was wir nicht noch alles ausprobieren können. WildFly, Keycloak, Kafka, ActiveMQ, MongoDB, PostgreSQL, Couchbase, Prometheus, Grafana und das alles auf OpenShift mit Raspberry Pi Clients.

Um das Entwickeln wieder etwas angenehmer zu machen, haben wir uns für dieses Projekt vorgenommen, die Architektur von Hogarama zu vereinfachen.

Hogarama – ein ewiger Quell für neue Ideen, was wir nicht noch alles ausprobieren können. WildFly, Keycloak, Kafka, ActiveMQ, MongoDB, PostgreSQL, Couchbase, Prometheus, Grafana und das alles auf OpenShift mit Raspberry Pi Clients.

“Ist das nicht etwas overengineered?”

“Ja, und?”

“Warum?”

“Weil wirs können!”

Das ist für ein Learning-Friday Projekt OK und macht Spaß, allerdings hat es auch Nachteile. Einsteiger, aber auch fortgeschrittene Entwickler haben zunehmend Probleme das ganze System lokal zum Laufen zu bringen. Um neue Features zu entwickeln, muss man einen wachsenden Berg an Vergangenheit überwinden. (Klingt wie dein Projekt?)

Um das Entwickeln wieder etwas angenehmer zu machen, haben wir uns für dieses Projekt vorgenommen, die Architektur von Hogarama zu vereinfachen. Als gebranntes Kind diesmal in kleinen Schritten (siehe Hogarama und „The Second System Effect“)

Modularisierung

Ziel ist es, eine Art Onion-Architektur zu implementieren. Das bedeutet, unsere Core-Applikation soll keine Abhängigkeit zu anderen Teilen von Hogarama haben. Durch “Inversion of Control” sind andere Teilmodule von Hogarama dafür verantwortlich, ein in der Core-Applikation definiertes Interface zu implementieren. In diesem Learning-Friday Projekt haben wir uns den Security/Authentifizierung-Teil von Hogarama vorgenommen.

Die Grundidee: Lokales Entwickeln bzw. Testen von Hogarama (z.B. Integration- oder E2E-Tests) soll möglich sein, ohne dass sich die Applikation wie bisher mit einem externen Keycloak verbinden muss.  Um dies zu ermöglichen, haben wir einen modularen Ansatz gewählt. Die bisherige Implementierung, die den Keycloak verwendet, wird in ein eigenes Modul verschoben. Weiters gibt es ein “Dummy-Modul”, welches nur Java (JEE) Methoden verwendet und für das lokale Entwickeln bzw. Testen vorgesehen ist.

Die Compile-Dependencies liegen daher immer bei den Modulen und nicht bei der Core-Applikation. In der folgenden Grafik ist dies dargestellt.

Simplify Hogarama Sec

Welche der beiden Security Module verwendet werden soll, wird derzeit zur Build-Zeit mit Hilfe von Maven Build-Profilen gesteuert. Nur eines der beiden optionalen Security Module wird im WAR-File hinzugefügt.

Dummy

Das Dummy Security-Modul sorgt dafür, dass auch ohne JWT immer ein gültiges Benutzerobjekt im Code zur Verfügung steht. Sowohl am Client als auch bei REST-Aufrufen kann man den Benutzer mitgeben. Das hilft bei Tests mit unterschiedlichen Berechtigungen.

Fazit

  • Durch die Modularisierung können wir einfach zwischen JWT und Dummy-Implementation wechseln.
  • Dies ermöglicht auch eine einfachere Integration bei tatsächlichem Deployment.
  • Das Security-System ist nun nicht mehr mit Hogarama verbunden, sondern in einem eigenen Modul.
  • Das Dummy-Modul reduziert den Aufwand beim lokalen Entwickeln und ermöglicht einen einfacheren Test.

 

Abschließende Worte

“Ein Fork ist auch keine Lösung”. (frei nach OpenAI)

geschrieben von:
Christian, Erhard, Egor, Mattias
WordPress Cookie Plugin von Real Cookie Banner