Sie sind überall. Im Kaffeeautomat. Im Kühlschrank. Am Schlüsselbund. Sie haben viele Größen und Formen. Sie steuern und regeln (fast) alles.

Die Illuminaten? Nein! Mikrocontroller

Als Informatiker pflegt man deren Existenz meist weg zu abstrahieren...

Die W-JAX 2024 findet vom 4. bis 8. November 2024 in München statt. Das trion-Team ist vor Ort und bietet eine Vielzahl von Vorträgen sowie eine interaktive Night-Session an. Diese Formate ermöglichen es den Teilnehmenden, tief in technologische und architektonische Themen einzutauchen und anregende Diskussionen zu führen.

In einem vorherigen Artikel haben wir uns damit befasst, wie man Keycloak Rollen als Spring Security Authorities verfügbar macht, wenn Spring Boot als Resource Server agiert. In diesem Folgebeitrag betrachten wir nun den Fall, in dem unsere Spring Boot Anwendung die Rolle eines OAuth 2.0 Client einnimmt und einen OAuth 2.0 Login mit Keycloak implementiert. Auch hier wollen wir die Rollen aus Keycloak korrekt mappen.

Spring Framework 6.2 bzw. Spring Boot 3.4 bringt eine interessante Neuerung für Entwickler, die ihre Unit- und Integrationstests mit AssertJ schreiben: MockMvc Tests können nun auch mit AssertJ formuliert werden (GitHub Issue). Bisher musste für Controller-Tests mit MockMvc auf die Hamcrest-Syntax zurückgegriffen werden, was zu uneinheitlichen Test-Code führen konnte. Mit dem Release von Spring Boot 3.4 im November 2024 kann die vertraute AssertJ assertThat() API auch in Verbindung mit MockMvc verwendet werden, was das Testen von Web-Controllern eleganter und konsistenter macht. In diesem Artikel zeigen wir, welche Anpassungen am Code notwendig sind, um diese neue Möglichkeit nutzen zu können.

Um Anwendungen sicher und verlässlich (weiter-)entwickeln zu können, ist es etablierte Praxis, Tests zu schreiben, die das Verhalten der Anwendung sicher nachstellen und überprüfen. Unterschieden wird dabei gerne zwischen feiner-granularen,...

Supply Chain Security spielt auch im Container Umfeld eine immer wichtigere Rolle. Es gilt dabei die Sicherheit im Sinne von Echtheit und Integrität der (Docker) Images abzusichern.
Typische Supply Chain Angriffsszenarien bei Kubernetes, Docker...

Dokumentation ist ein Thema, dass gerne hinten angestellt wird.
Quasi "wenn noch Zeit ist". Vergleichbar mit Tests wird Dokumentation von manchen Personen als schlecht investierte Zeit angesehen. Erschwerend kommt hinzu, dass die Pflege aufwendig ist: Wird die Software weiterentwickelt, so müssen oft auch Tests und Dokumentation nachgezogen werden.

Wir haben gute Erfahrungen damit gemacht, Dokumentation - wo möglich - zu generieren. Dabei kann sowohl der Java Quellcode als Quelle dienen, als auch Ergebnisse von automatisiert ausgeführten Tests.
Auf diese Weise kann die Dokumentation nah am Quellcode mitgepflegt werden, die Wahrscheinlichkeit sinkt, dass dies nicht bedacht oder vergessen wird.

In diesem Beitrag geht es darum, auch die Dokumentation der verwendeten Datenbankschemata zu dokumentieren. Dazu werden die Werkzeuge Testcontainers, Schemacrawler und JUnit miteinander verknüpft.

Gerade für die Entwicklung und zum Testen bietet es sich im Kontext von Kubernetes an, auch eine lokale Umgebung zur Verfügung zu haben. Seit Docker Desktop für Firmen lizenzpflichtig geworden ist, ist diese Option weniger oft anzutreffen. Dabei sind nicht unbedingt die Kosten der entscheidende Faktor, sondern die mit der Beschaffung verbundene Komplexität und Aufwände.

Stattdessen bietet sich als Alternative an, mit der WSL zu arbeiten. Mit Ubuntu kommt auch eine leicht einzurichtende Kubernetest Distribution von Canonical mit: Microk8s. Microk8s bietet vergleichbar mit Minikube auch die Integration von verschiedene Addons um zum Beispiel einen Ingress einfach bereitzustellen.

Da Microk8s innerhalb der WSL läuft, ist die Integration nicht ganz so nahtlos, wie dies bei Docker Desktop gelungen ist. Wir werfen im folgenden einen Blick darauf, welche Optionen es gibt, auf den Microk8s bzw. Dienste zuzugreifen. Im Fokus steht dabei vor allem der Ingress, wird dieser schließlich auch sonst typischerweise für den Zugriff auf HTTP Dienste und Webanwendungen genutzt.

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. In einem weiteren Blogpost betrachten wir Fall in dem unsere Anwendung als OAuth 2.0 Client agiert und einen OAuth 2.0 Login implementiert.