In vielen modernen Anwendungen nutzen wir Keycloak zur Authentifizierung für den Zugriff auf Spring Boot Anwendungen. Dabei werden Benutzer und ihre Rollen in Keycloak gespeichert bzw. von Keycloak bereitgestellt. In einer Spring-Anwendung möchten wir diese Rollen nun nutzen, um den Zugriff auf Ressourcen zu autorisieren.

Standardmäßig extrahiert Spring Security automatisch Authorities aus dem OAuth2 Scope Claim. Die vergebenen Rollen werden durch Keycloak in einem separaten Claim bereitgestellt und stehen damit nicht automatisch für die Nutzung zur Autorisierung zur Verfügung. Nachfolgend ist kurz beschrieben, wie wir die Keycloak-Rollen als Spring Security Authorities verfügbar machen.

Fullstack in modern - von Offlinefähigkeit bis hin zu Echtzeitanwendungen. Gemeinsam mit dem Java Magazin haben wir einen Artikelschwerpunkt entwickelt, in dem wir im Rahmen einer Beispielanwendung einige der Technologien vorstellen, mit denen wir auch in Kundenprojekten Architekturanforderungen umsetzen.

Dabei nutzen wir für die Beispielanwendung MQTT als Messagingsystem um Events bis in das browserbasierte Frontend auf Basis von Angular als ein Kommunikationsweg nutzen.

Als Sonderdruck ist der Schwerpunkt im PDF Format als Download am Ende von diesem Beitrag zu finden.

Mit Spring Security können unter anderem Webanwendungen (Spring WebMVC) auf einfache und flexible Weise abgesichert werden. Dabei ist der typische Weg über Security-Filter-Chains die Webschicht von Spring WebMVC mit Spring Security abzusichern. Doch reicht das aus?
Diese rhetorische Frage lässt sich mit vielleicht beantworten: Gibt es keine Programmierfehler oder Logikfehler, so kann das bereits ausreichen. Denn erreicht kein Request unberechtigt die Controller-Schicht, dann kann nichts passieren.

Doch in Zeiten zunehmender Cyberbedrohungen sollte keine Anwendung lediglich durch eine Schicht gesichert werden. Verteidigung in der Tiefe kann dank Spring Security leichtgewichtig mit Method Security umsetzen. Eine deutliche Verbesserung.

In unserem letzten Spring Security Training kam die Frage auf, wie sich dies mit periodischen Aufgaben innerhalb der Spring Anwendung kombinieren lässt. Das soll als Anlass dienen, sowohl periodische als auch asynchrone Ausführung, z.B. durch Message-Queue Nachrichten in Kombination mit Method Security darzustellen.

Die JAX 2024 steht vor der Tür und das Team von trion ist bereits in den Startlöchern, um Wissen und Erfahrung zu teilen. Mit einer breiten Palette von Vorträgen und einem interaktiven Night-Session-Format bietet trion Teilnehmern die Möglichkeit, sowohl in Bezug auf Technologie als auch Architektur in spannende Bereiche einzutauchen und tiefgehende Diskussionen zu führen.

Drools ist eine Rule-Engine, also ein Baustein für Expertensysteme und zur Flexibilisierung von Entscheidungen. Dabei ist Drools flexibel in bestehende JavaEE, Spring Boot und andere Frameworks integrierbar.
Dieser Beitrag beschäftigt sich mit folgender Fragestellung: Wie könnte eine Cloud-native Umsetzung von Drools im Gegensatz zu dem klassischen Modell einer Einbettung aussehen?

Cassandra ist eine noSQL Datenbank, die insbesondere im Kontext großer Datenmengen bei sehr hoher Verfügbarkeit eingesetzt wird. Dabei ist bei Cassandra entscheidend, dass das Schema passend zu den jeweils zu unterstützenden Anwendungsfällen konzipiert ist: Nur so wird die hohe Geschwindigkeit von Cassandra und die Verfügbarkeit sicher gestellt.

Doch Anforderungen können sich ändern, und damit muss auch die Anwendung angepasst werden. Das kann sich auch auf die Datenstrukturen in Cassandra auswirken.
Ein Weg, damit umzugehen, sind Cassandra Materialized Views oder ein kompletter Datenexport als CSV und Re-Import. Bei den für Cassandra typischen großen Datenmengen ist das selten praktikabel.

Unabhängig davon, um man sehr kleine Datenmengen in Cassandra vorhält, zum Beispiel zur Entwicklungszeit, oder eine spezielle Migrationsanwendung für den produktiven Einsatz mit Cassandra erstellt: Die Migrationen sollten sich einfach verwalten und in der Versionskontrolle ablegen lassen.

Cassandra 4 ist ein lang erwartetes Release der Cassandra Datenbank. Dabei hat sich nicht nur einiges in der Datenbank selbst geändert, sondern auch die Java Libraries für den Zugriff haben einige API Änderungen erfahren.
In dem Zuge sind viele andere Projekte aktuell noch nicht soweit, gute Unterstützung für Cassandra 4 zu bieten. Spring Boot bzw. Spring Data Cassandra ist jedoch bereits soweit, dass aktuelle Treiber genutzt werden. Dort stellt sich die Frage, wie das Thema Unit Test bzw. Integrationstest mit Cassandra 4 umgesetzt werden kann.

Dank der Java GraalVM in Kombination mit dem Werkzeug native-image lassen sich Java Anwendungen in nativ kompilierte Binaries überführen, die sogar statisch gelinkt sein können. Damit entfällt die Initialisierung der HotSpot VM sowie das Laden und Initialisiern von Klassen.
Eine derartig gebaute Java Anwendung lässt sich in sehr kurzer Zeit starten. Selbst mit umfangreichen Abhängigkeiten wie Thymeleaf und Spring Security kann man hier im Bereich von einer Sekunde den vollständigen Anwendungsstart erwarten.

Dazu kommt ein gut vorhersagbarer Speicherverbrauch zur Laufzeit, der zudem auch geringer ausfällt, als bei der sehr dynamischen HotSpot VM. Der Tradeoff von GraalVM-Native-Anwendungen ist, dass die Peakperformance im Vergleich zu HotSpot geringer ausfällt und Oracle zudem bestimmte Performanceoptimierungen nur in einer kommerziellen Variante anbietet.

Wie verhält sich Spring Boot mit Spring native - derzeit in Version 0.11.1 als beta - in Bezug auf den produktiven Einsatz? Worauf gilt es zu achten und was funktioniert nicht, wie man es erwartet?
Diese Aspekte werden im folgenden betrachtet.

Dank Spring Boot ist die Erstellung von Java basierten Anwendungen und Microservices extrem leicht geworden: Mit Spring Initializr ( https://start.spring.io ) ist eine API Anwendung schnell erstellt. Sinnvolle Standardeinstellungen und eine gute Entwicklerproduktivität machen Spring Boot auch im weiteren Verlauf eines Softwareprojekts zu einer beliebten Plattform.

Doch was ist, wenn man von den vorgegebenen Pfaden abweichen will?
Spring Boot zeigt sich hier flexibel: Am Beispiel von YAML als Datenformat für unsere Anwendung schauen wir uns das einmal genauer an.

OpenID Connect und OAuth2 sind vielleicht etwas moderner und hipper als das bereits etwas in die Jahre gekommene SAML 2 Protokoll. Soll jedoch im Enterpriseumfeld eine Anwendung in bestehende Landschaften integriert werden, führt selten ein Weg an SAML 2 vorbei. Das gilt um so stärker, wenn es sich um eine Branche mit hohem Sicherheitsbedarf wie Luftfahrt, Banken oder Versicherungen handelt.

Keycloak hat sich als zuverlässige und gleichzeitig sehr leicht zugängliche Plattform zur Umsetzung von OpenID Connect oder SAML erwiesen. Dabei kann Keycloak sowohl produktiv eingesetzt werden, als auch sehr komfortabel als lokale Testumgebung für Entwicklung und Test verwendet werden. Zur Integration von Keycloak in Spring Boot existieren neben einem Keycloak Modul auch Spring-Security-SAML bzw. OAuth2 Client und Resourceserver.

Gerade wenn es um das Thema Security geht, bringen automatisierte Tests ein wichtiges Sicherheitsnetz für die Software. Wir wollen Keycloak als SAML 2 IdP verwenden und mit einer Spring Boot Anwendung Authentifizierung mit SAML 2 als Beispielanwendung für automatisierte Integrationstests verwenden. Ein - relativ einfacher - Weg wäre, Keycloak als Docker Container im Rahmen der CI-Pipeline mit Jenkins, Bamboo oder GitLab-CI bereitzustellen, so dass die zu testende Software darauf zugreifen kann. Allerding verliert man damit die Möglichkeit, die Tests lokal genauso zu entwickeln und zu validieren, wie sie nachher in der Buildserver Umgebung laufen.

Eine Alternative stellen Testcontainers dar. Die allgemeine Verwendung von Testcontainers wurde bereits in Testcontainers mit JUnit 5 erläutert. Nun schauen wir uns an, wie Keycloak, Testcontainers und Spring Boot SAML 2 zusammen eingesetzt werden kann.

Regelmäßig kommt in unseren Docker Schulungen Verwunderung auf, wenn wir Beispiele zum Einsatz von Containern im Entwicklungsprozess aufzeigen. Denn Container bzw. Docker bringt gerade da auch immense Vorteile: Neben einer möglichen Parität zwischen Produktionsumgebung und Entwicklersystem ist es gerade die sehr einfache Möglichkeit, Umsysteme als Container bereitzustellen.

Das kann für einen Frontendentwickler das Backend sein, für einen Backendentwickler kann es die richtige Datenbank, Message-Queue oder ein anderer (Micro-)Service sein.
Verfügen aktuelle IDEs in der Regel über Docker-Integration oder wird docker-compose eingesetzt, stellt sich die Frage, wie in CI-Umgebungen Container für Integrationstests am besten eingesetzt werden können. Hier hat das Projekt Testcontainers eine Lösung ins Rennen geschickt: Durch eine gelungene Abstraktion lassen sich Container sehr leicht in Tests verwalten und zusammen mit den Tests orchestrieren. Container-Typen und Versionen werden gemeinsam mit dem Testcode versioniert, was die Wartung und Refactoring erleichtert. Auch ein häufiges Problem, nämlich auf den erfolgreichen Start eines Containers bzw. des damit bereitgestellten Dienstes zu warten, wird gut gelöst.

Testcontainers gibt es für verschiedene Programmiersprachen bzw. Plattformen. Wir schauen uns im folgenden einmal die Umsetzung für Java speziell im Kontext von JUnit 5 genauer an.

Bei der PHP Usergroup Münster stellte Thomas Kruse vor, welche Optionen gRPC für die Entwicklung und Integration von Microservices bietet.