Spring Archive | INOTEQ GmbH

Automatisches Front-End-Testing einer OAuth 2.0 Spring-Boot Anwendungen

Alexander Kusmin — Thu, 08 Feb 2024 15:09:39 +0000

Automatisches Front-End-Testing einer OAuth 2.0 Spring-Boot Anwendungen

Dieser Beitrag vertieft die Thematik des automatischen Front-End-Testings einer OAuth 2.0 Spring Boot-Anwendung. Er fungiert als komplementäre Erweiterung zu unserem vorangegangenen Beitrag über Spring Boot mit OAuth 2.0 und Keycloak. Im Fokus stehen die Integration von Keycloak als zentraler OAuth 2.0 Dienst und die Rolle von Spring Boot als fundamentale Anwendungsplattform.

Ein kurzer Rückblick auf die wesentlichen Konzepte von OAuth 2.0 sowie die spezifische Bedeutung von Keycloak bietet einen soliden Ausgangspunkt. In unserem vorherigen Beitrag haben wir bereits die Integration von Spring Boot und Keycloak beleuchtet, um eine sichere OAuth 2.0-Authentifizierung zu gewährleisten. Falls Sie diesen Beitrag bisher nicht verfolgt haben, empfiehlt es sich, einen Blick darauf zu werfen, da der vorliegende Beitrag nahtlos auf den dort behandelten Grundlagen aufbaut.

Die Analyse konzentriert sich auf fortgeschrittene Aspekte des automatischen Front-End-Testings. Insbesondere wird die Erstellung einer GitLab Pipeline für automatische Tests auf bewährten Prinzipien von Keycloak und Spring Boot basierend erkundet. Das Ziel ist es, Ihnen Einblicke in die strategischen Schritte zu geben, um eine effiziente und zuverlässige Testumgebung zu schaffen, die sich nahtlos in Ihre Entwicklungsprozesse integrieren lässt.

Keycloak für die Testumgebung

Zum Testen der Spring Boot Anwendung ist eine Keycloak Konfiguration für die Testumgebung erforderlich. Später wird mithilfe von Testcontainers eine Keycloak-Instanz mit der gegebenen Konfiguration geladen, um die Authentifizierung in den Tests zu übernehmen. Zu diesem Zweck wird eine Import-Datei im JSON-Format benötigt. Ein einfacher Export der Konfiguration ist über die Keycloak-Benutzeroberfläche zwar möglich, allerdings werden aus Sicherheitsgründen die angelegten Benutzer nicht mit exportiert. Die Testumgebung wäre dann zwar in der Lage, sich mit dem OAuth 2.0 Server zu verbinden und normal zu starten, es stehen anschließend jedoch keine Benutzer für die Authentifizierung zur Verfügung.

Realm-Export mit Benutzern

Im Folgenden wird erklärt, wie man einen bereits vollständig konfigurierten Realm mit allen Benutzern exportiert, während der Keycloak-Server in einer Docker-Umgebung läuft. Im Repository zum letzten Beitrag findet sich bereits eine aus dem vorkonfigurierten Demo-Realm exportierte realm.json Datei, die hier wieder verwendet wird.

Folgender Befehl wird im Terminal des Systems ausgeführt:

docker exec -it keycloak-demo bash

Darüber gelangen wir in das Terminal innerhalb des Containers, auf dem der Keycloak-Server läuft. Dabei wird hier der Container keycloak-demo gewählt. Innerhalb des Containers wird dann folgender Befehl ausgeführt:

./opt/keycloak/bin/kc.sh export --dir /tmp/export --realm demo-realm --users realm_file

Damit exportieren wir die Realm-Konfiguration mit allen Benutzerdaten als demo-realm-realm.json in das Verzeichnis /tmp/export innerhalb des Containers. Mit dem Befehl exit gelangt man wieder in das Terminal des eigenen Systems zurück. Zuletzt wird die exportierte Datei mit dem folgendem Befehl aus dem Container herauskopiert.

docker cp keycloak-demo:/tmp/export/demo-realm-realm.json ~/Desktop/realm.json

In diesem Beispiel wird es einfach auf den Desktop kopiert und gleichzeitig in realm.json umbenannt, später wird diese aber im Spring Boot-Projekt gebraucht.

Sensible Daten Die exportierte Realm-Konfiguration kann sensible Daten wie Passwort-Hashes oder E-Mails enthalten. Aus diesem Grund sollte diese Variante ausschließlich für Entwicklungszwecke oder mit Testsysteme mit Testdaten verwendet werden.

Playwright Frontend Tests

Um die Benutzeroberfläche der Anwendung zu testen, wird das Testframework Playwright verwendet.

Im Vergleich zu dem bekannteren Selenium bietet Playwright einige Vorteile, wie zum Beispiel eine bessere Performance und weniger erforderlichen Boilerplate-Code beim Schreiben der Tests. Playwright bietet eine verbesserte Browser-Automation und unterstützt mehrere Browser. Außerdem gibt es eine native Unterstützung für den Headless-Modus, bessere Möglichkeiten zur Manipulation von Webseiten und eine einfache Verwendung mit Pipelines für automatische Tests.

Konfiguration

Für die Verwendung von Playwright für Tests muss die build.gradle angepasst werden. Zunächst sollte sichergestellt werden, dass es eine Test-Task für Gradle existiert und die benötigten Abhängigkeiten für Spring Boot Starter Tests als auch Playwright für die Testimplementierung angegeben sind, als auch die Abhängigkeiten für die Verwendung von OAuth 2.0 selbst.

build.gradle

dependencies {
    ...
    testImplementation 'org.springframework.boot:spring-boot-starter-test:3.2.2'
    testImplementation 'com.microsoft.playwright:playwright:1.41.1'
}

...

tasks.named('test') {
    useJUnitPlatform()
}

Eine Testklasse wird erstellt und für die Spring Boot Anwendung sowie für Playwright konfiguriert. Zunächst wird Playwright so konfiguriert, dass der automatische Testprozess beobachtet werden kann, um mögliche Fehler zu sichten. Später sollte diese Option wieder ausgestellt werden, da die Tests so wesentlich schneller laufen.

src/test/kotlin/DemoTest.kt

import ...

@SpringBootTest(
    classes = [DemoApplication::class],
    webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT
)
class DemoTest {
    companion object {
        // Playwright setup
        private var playwright: Playwright? = null
        private var browser: Browser? = null
        private var context: BrowserContext? = null
        private var page: Page? = null

        @JvmStatic
        @BeforeAll
        fun launchBrowser() {
            playwright = Playwright.create()
            
            browser = playwright?.chromium()?.launch(
                // Run playwright in headed mode with slow motion to see what's happening
                BrowserType.LaunchOptions().setHeadless(false).setSlowMo(100.0)
            )
        }

        @JvmStatic
        @AfterAll
        fun closeBrowser() {
            playwright?.close()
        }
    }

    @BeforeEach
    fun createContextAndPage() {
        context = browser?.newContext()
        page = context?.newPage()
    }

    @AfterEach
    fun closeContext() {
        context?.close()
    }
}

Damit kann Playwright nun für Tests verwendet werden.

Beispieltests

Wir halten uns bei diesem Beispiel an das Demo-Projekt aus dem letzten Beitrag und wollen die beiden Endpunkte /public und /private testen. Der /public Endpunkt ist immer aufrufbar, aber der /private Endpunkt ist erst aufrufbar, nachdem sich der Benutzer erfolgreich authentifiziert hat. Dafür müssen wir Playwright mitteilen, dass er nach dem Aufruf von /private auf eine Weiterleitung zum OAuth 2.0 Server warten soll, dort dann Benutzername und Passwort eingibt, bestätigt und zu guter Letzt wieder auf dem erwarteten Endpunkt /private landet.

src/test/kotlin/DemoTest.kt

@Test
fun publicEndpointTest() {
    page?.navigate("http://localhost:8080/public")
    assertThat(page?.locator("body")).hasText("Hello from a public endpoint!")
}

@Test
fun privateEndpointTest() {
    // Unable to access private endpoint without logging in and redirects to login page
    page?.navigate("http://localhost:8080/private")

    // Login with example user 'John Doe' by filling the login form and submitting it
    page?.fill("#username", "john.doe")
    page?.fill("#password", "password")
    page?.locator("input[type=submit]")?.click()
    // Wait for redirect to previously requested private endpoint
    page?.waitForURL("http://localhost:8080/private?continue")

    // Check for expected content on private endpoint
    assertThat(page?.locator("body")).hasText("Hello from a private endpoint!")
}

Um sicherzustellen, dass unsere Tests korrekt funktionieren, lassen wir den OAuth 2.0 Keycloak-Container im Hintergrund laufen und führen die Tests aus. Dabei wird ein neuer Chromium-Browser geöffnet, den Playwright manipuliert. Für einen kurzen Moment ist auch zu sehen, wie Playwright sich am OAuth 2.0 Server anmeldet.

Um die Auswirkungen von fehlendem OAuth 2.0 Zugriff zu zeigen, wird der Keycloak-Container gestoppt und die Tests erneut ausgeführt. Dadurch sollten die Tests fehlschlagen. Im nächsten Schritt wird der Zugriff wieder ermöglicht, indem bei den Tests ein Keycloak-Container erstellt und gestartet wird.

Keycloak Testcontainer

Zunächst benötigen wir die richtige Abhängigkeit, um einen Keycloak-Container für Tests zu starten. Dafür gibt es den Keycloak Testcontainer, eine spezielle Variante des Testcontainers, der für Keycloak angepasst wurde. Dazu wird die folgende Zeile in build.gradle eingefügt:

testImplementation 'com.github.dasniko:testcontainers-keycloak:3.2.0'

Wichtig ist, dass Docker auf Ihrem System läuft.

Die Testklasse wird so angepasst, dass unser gewünschter OAuth 2.0 Service wieder erreichbar ist, ohne dass wir den Container dafür erstellen und starten müssen. Dazu wird der Code wie folgt ergänzt:

src/test/kotlin/DemoTest.kt

companion object {
    // Start a Keycloak instance with an import file for the demo realm
    @JvmStatic
    private val keycloakContainer = KeycloakContainer().apply {
        withRealmImportFile("realm.json")
        portBindings = listOf("8081:8080")
        start()
    }

    // Register the Keycloak issuer URL as a dynamic property for the Spring Boot application
    @JvmStatic
    @DynamicPropertySource
    private fun registerResourceServerIssuerProperty(registry: DynamicPropertyRegistry) {
        registry.add("spring.security.oauth2.client.provider.demo-provider.issuer-uri") {
            "${keycloakContainer.authServerUrl}/realms/demo-realm"
        }
    }

    ...

    @JvmStatic
    @BeforeAll
    fun launchBrowser() {
        playwright = Playwright.create()
        browser = playwright?.chromium()?.launch() // Use headless mode
    }

   ...
}

Es wird ein Keycloak-Container definiert, der die zuvor exportierte realm.json importiert. Diese Datei muss sich dazu im Verzeichnis src/test/resources befinden. Zudem wird vor dem Start die Portbindung definiert.

Testcontainer werden immer mit einem zufälligen Port gestartet. Die Anwendung benötigt jedoch diesen Port, um den OAuth 2.0 Dienst richtig zu konfigurieren. Für diesen Zweck wird im Code die dynamische Eigenschaft für den OAuth 2.0-Dienst angepasst, indem wir die URL des Testcontainers einschließlich des Ports vor dem verwendeten Realm angeben.

Die Tests sind jetzt unabhängig von der lokalen Umgebung ausführbar. Während des Testprozesses wird ein neuer Container in Docker erstellt und nach Abschluss der Tests wieder gelöscht.

Es empfiehlt sich, Playwright wieder headless zu benutzen, da dadurch eine wesentlich bessere Performance erreicht wird. Das ist vor allem im nächsten Schritt wichtig.

GitLab Pipeline

Das Ziel war bisher, die Tests zu automatisieren und für eine GitLab-Pipeline ausführbar zu machen. Dafür ist es wichtig, dass der GitLab-Runner Docker-Container ausführen kann.

Playwright bietet ein Image an, das für die Zwecke dieses Projekts geeignet ist. Auf der Playwright-Website gibt es genauere Details zur kontinuierlichen Integration, einschließlich GitHub und anderen Plattformen. Auch für Testcontainers werden ausführliche Beispiele gezeict, wie man z.B. eine GitLab Pipeline mit Testcontainers konfiguriert. In unserem Fall orientieren wir uns an der Variante, die Docker-in-Docker verwendet.

Sobald die benötigten Anpassungen vorgenommen wurden, lassen sich mittels ./gradlew test die Tests ausführen.

gitlab-ci.yml

image: mcr.microsoft.com/playwright/java:v1.41.0-jammy

services:
  - name: docker:dind
    command: [ "--tls=false" ]

variables:
  DOCKER_HOST: "tcp://docker:2375"
  DOCKER_TLS_CERTDIR: ""
  DOCKER_DRIVER: overlay2

before_script:
  - GRADLE_USER_HOME="$(pwd)/.gradle"
  - export GRADLE_USER_HOME

stages:
  - test

tests:
  stage: test
  script:
    - ./gradlew test

Wie man nun sehen kann, läuft die Pipeline erfolgreich durch. Allerdings ist es erwähnenswert, dass sie einige Zeit dafür benötigt. Mit einer größeren Anzahl an Tests steigt auch die Zeit, die die Pipeline benötigt, um diese auszuführen. Dabei sei gesagt, dass die meiste Zeit für die Vorbereitung der Pipeline benötigt wird, einschließlich der größeren Abhängigkeiten wie dem Playwright Browser.

GitLab Runner

Running with gitlab-runner 14.7.0 (98daeee0)
  on gitlab-runner-01 y7AkGoZD
Preparing the "docker" executor 00:34
...
Preparing environment 00:00
...
Getting source from Git repository 00:02
...
Executing "step_script" stage of the job script 03:52
Using docker image sha256:df9599e540016f99fbcd1d862224ae9d1cf30df17fa5d367c969ee37cc060afb for mcr.microsoft.com/playwright/java:v1.41.0-jammy with digest mcr.microsoft.com/playwright/java@sha256:390fdf6801be59dd7bc6a3fad6344ae9d795b6585d102af293b57d61076d0824 ...
$ GRADLE_USER_HOME="$(pwd)/.gradle"
$ export GRADLE_USER_HOME
$ ./gradlew test
Downloading https://services.gradle.org/distributions/gradle-8.5-bin.zip
............10%.............20%............30%.............40%.............50%............60%.............70%.............80%............90%.............100%
Welcome to Gradle 8.5!
Here are the highlights of this release:
 - Support for running on Java 21
 - Faster first use with Kotlin DSL
 - Improved error and warning messages
For more details see https://docs.gradle.org/8.5/release-notes.html
Starting a Gradle Daemon (subsequent builds will be faster)
> Task :checkKotlinGradlePluginConfigurationErrors
> Task :processResources
> Task :processTestResources
> Task :compileKotlin
> Task :compileJava NO-SOURCE
> Task :classes
> Task :compileTestKotlin
> Task :compileTestJava NO-SOURCE
> Task :testClasses
> Task :test
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
For more on this, please refer to https://docs.gradle.org/8.5/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.
BUILD SUCCESSFUL in 3m 50s
6 actionable tasks: 6 executed
Cleaning up project directory and file based variables 00:01
Job succeeded

Fazit

Die vorgestellten Tests zeichnen sich durch ihre hohe Realitätsnähe aus, da sie auf einer dynamischen Keycloak-Testumgebung basieren. Dies vereinfacht die Entwicklung und trägt zur Sicherstellung einer zuverlässigen Authentifizierung bei. Jedoch ist es wichtig zu beachten, dass die GitLab Pipeline, aufgrund ihrer umfassenden Abhängigkeiten wie dem Playwright Browser, eine längere Ausführungszeit aufweisen kann. Trotz dieser potenziellen Einschränkung bieten die realitätsnahen Tests einen unschätzbaren Wert für die Entwicklung von sicheren und zuverlässigen OAuth 2.0 Spring Boot-Anwendungen.

Für weitere Details steht das GitHub Repository zur Verfügung, das alle im Artikel beschriebenen Schritte und Konfigurationen enthält.

Referenzierte Artikel

Integration von OAuth 2.0 in Spring Boot mit Keycloak

Alexander Kusmin 30. November 2023

Dieser Leitfaden beschreibt die Integration von OAuth 2.0 in eine Spring Boot Anwendung mit Keycloak. Nach einer kurzen Einführung in die Spring Boot Plattform liegt der Schwerpunkt auf der genauen Konfiguration von Keycloak als vertrauenswürdigen OAuth 2.0 Server und der Absicherung bestimmter Endpunkte in der Anwendung mit Anmeldedaten. Der Beitrag ist dabei so strukturiert, dass Entwickler Schritt für Schritt eine sichere Authentifizierung in einer Spring Boot-Anwendung implementieren können. Inhaltsverzeichnis Spring

Integration von OAuth 2.0 in Spring Boot mit Keycloak

Alexander Kusmin 30. November 2023

Integration von OAuth 2.0 in Spring Boot mit Keycloak

Alexander Kusmin 30. November 2023

Der Beitrag Automatisches Front-End-Testing einer OAuth 2.0 Spring-Boot Anwendungen erschien zuerst auf INOTEQ GmbH.

Kotlin vs. Java im Praxischeck: Ein Spring Boot Erfahrungsbericht

Alexander Kusmin — Thu, 01 Feb 2024 14:16:59 +0000

Kotlin vs. Java im Praxischeck: Ein Spring Boot Erfahrungsbericht

Kürzlich habe ich für einen Kunden ein Fullstack Spring Boot Projekt entwickelt, bei dem ich eine gewisse Freiheit bei der Wahl der Technologie und der Programmiersprache hatte. Es stellte sich rasch die Frage, ob ich Java oder Kotlin verwenden sollte. Ich habe mich bewusst für Kotlin als Programmiersprache entschieden, wobei die Entscheidung nicht nur auf technologischer Neugier basierte, sondern auch darauf, die Vor- und Nachteile von Kotlin im Vergleich zu Java in einem realen Projekt zu entdecken. In diesem Beitrag teile ich meine Erfahrungen und Erkenntnisse, während ich einen Blick auf die Unterschiede beider Sprachen werfe.

Grundlegende Unterschiede

Java und Kotlin werden beide in der Java Virtual Machine (JVM) ausgeführt, unterscheiden sich jedoch in Syntax, Semantik und Programmierparadigmen. Java wurde 1995 veröffentlicht und ist eine der bekanntesten und etabliertesten Programmiersprachen und folgt dem imperativen, objektorientierten Paradigma. Kotlin hingegen wurde 2011 gezielt entwickelt, um einige der Schwächen von Java zu beheben. 

Die Syntax ist klarer, kompakter und fördert eine höhere Lesbarkeit des Codes. Ein wichtiger Aspekt ist die Reduzierung von Boilerplate-Code, damit sich Entwickler stärker auf die logischen Aspekte ihrer Anwendung konzentrieren können. 

Ein Beispiel für die Vereinfachung der Syntax in Kotlin ist die Deklaration von Datenklassen. In Java müssen Entwickler viel Code für Getter, Setter, Equals, HashCode und ToString schreiben. In Kotlin kann dies mit nur einer Zeile erledigt werden, was zu einer saubereren und wartungsfreundlicheren Codebasis führt. In Java existieren mittlerweile ähnliche Lösungen, wie beispielsweise Java Records.

Hier ein Beispiel für den Unterschied von normalen Java-Klassen und Kotlin Daten-Klassen, orientiert nach dem Beispiel von Baeldung.

Java

public class Task {
    private int id;
    private String description;
    private int priority;

    public Task(int id, String description, int priority) {
        this.id = id;
        this.description = description;
        this.priority = priority;
    }

    public void setId(int id) {
        this.id = id;
    }

    public int getId() {
        return id;
    }

    public void setDescription(String description) {
        this.description = description;
    }

    public String getDescription() {
        return description;
    }

    public void setPriority(int priority) {
        this.priority = priority;
    }

    public float getPriority() {
        return priority;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = Integer.hashCode(this.id) * prime;
        result = prime * result + Integer.hashCode(this.priority);
        result = prime * result + ((this.description == null) ? 0 : this.description.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object var1) {
        if (this != var1) {
            if (var1 instanceof Task) {
                Task var2 = (Task) var1;
                if (this.id == var2.id
                  && Intrinsics.areEqual(this.description, var2.description)
                  && this.priority == var2.priority) {
                    return true;
                }
            }
            return false;
        } else {
            return true;
        }
    }

    @Override
    public String toString() {
        return "Task [id=" + id + ", description=" + description + ", priority=" + priority + "]";
    }
}

Kotlin

data class Task(
    var id: Int,
    var description: String,
    var priority: Int
)

Die Syntax von Kotlin ist in einigen Punkten einfacher und intuitiver. Beispielsweise werden Lambda-Ausdrücke als normale Funktionen definiert, während sie in Java als anonyme Klassen definiert werden.

Java

public final String[] listOfNames = new String[]{"Alice", "Bob", "Mallory"}
listOfNames.forEach { name -> println(name) }

Kotlin

val listOfNames = listOf("Alice", "Bob", "Mallory")
listOfNames.forEach { println(it) }

Die Semantik von Kotlin ist in einigen Punkten strenger als die von Java. Ein entscheidender Unterschied hier ist die Integration von Null-Sicherheit. Im Gegensatz zu Java, das das Arbeiten mit Null-Werten ohne explizite Behandlung erlaubt und häufig zu NullPointerExceptions führt, integriert Kotlin von Haus aus Null-Sicherheit, wodurch unerwünschte Null-Referenzen reduziert werden.

Java

public final String name = null
System.out.println(name.length) // NullPointerException

Kotlin

val name: String? = null
println(name?.length) // null

Kotlin bietet eine umfangreiche Sammlung von Funktionen, die in Java nicht verfügbar sind. Zum Beispiel gibt es die Möglichkeit für Inline-Funktionen oder Erweiterungen von fremden Klassen mit eigenen Methoden. Auf weitere Unterschiede möchte ich hier nicht näher eingehen, diese können auf der offiziellen Kotlin-Website eingesehen werden.

Kotlin in der Industrie und Community

Kotlin ist äußerst relevant und hat in den letzten Jahren erheblich an Bedeutung gewonnen, insbesondere in der Android-Entwicklung. Gründe hierfür sind:

Offizielle Google-Unterstützung
Google hat Kotlin als offizielle Programmiersprache für die Android-Entwicklung anerkannt. Seit 2017 ist Kotlin eine offizielle Sprache für die Entwicklung von Android-Apps und hat seitdem breite Akzeptanz gefunden.
Interoperabilität mit Java
Kotlin wurde entwickelt, um nahtlos mit Java zu interagieren. Dadurch können Entwickler bestehenden Java-Code in Kotlin integrieren und umgekehrt.
Moderne Sprachfunktionen
Kotlin bietet moderne Funktionen wie Null-Sicherheit, Erweiterungsfunktionen, Datenklassen und eine klare Syntax, die die Produktivität von Entwicklern verbessern. Daher ist Kotlin eine attraktive Alternative zu anderen JVM-Sprachen.
Community-Unterstützung
Die Kotlin-Community wächst kontinuierlich. Es gibt zahlreiche Ressourcen, Bibliotheken und Frameworks, die speziell für Kotlin entwickelt wurden. Die aktive Beteiligung der Entwicklergemeinschaft trägt zur Weiterentwicklung und Verbesserung der Sprache bei.
Branchenakzeptanz
Viele namhafte Unternehmen wie Google, Netflix, Uber und JetBrains setzen Kotlin erfolgreich in ihren Projekten ein. Dies zeigt, dass Kotlin nicht nur in der Entwicklergemeinschaft, sondern auch in der Industrie an Bedeutung gewinnt.
Plattformunabhängigkeit und -kompatibilität
Das Kotlin Multiplatform Project ermöglicht es, Code auf mehreren Plattformen zu kompilieren, z. B. auf Android, iOS, Web und Desktop.

Insgesamt ist Kotlin eine leistungsfähige Sprache, die für verschiedene Anwendungsbereiche geeignet ist.

Kotlin in der Praxis

Die Entscheidung, welche Sprache in einem Projekt verwendet werden soll, hängt wesentlich von den Vorlieben des Entwicklers ab. In meinem Fullstack Spring Boot-Projekt mit Kotlin konnte ich diese Unterschiede aus erster Hand erleben und beurteilen, wie sie sich auf die Entwicklungsdynamik und Codequalität auswirken. 

Um Kotlin zu verstehen, ist es hilfreich, die Herausforderungen zu betrachten, denen Entwickler in der Java-Entwicklung täglich gegenüberstanden. Kotlin ist keine Alternative zu Java, sondern eine moderne Ergänzung, die auf die Schwächen von Java eingeht und neue Ansätze für die Softwareentwicklung bietet. 

Kotlin unterbricht nicht die Verbindung zur etablierten JVM-Welt. Die Zielgruppe für Kotlin umfasst verschiedene Entwicklerprofile und -situationen.

Entwickler, die die Vorteile moderner Sprachen suchen
Kotlin bietet Funktionen wie Typinferenz, Erweiterungsfunktionen und Datenklassen, die die Entwicklung erleichtern und den Code kompakter und lesbarer machen. Entwickler, die moderne Programmierkonzepte bevorzugen, finden in Kotlin eine zeitgemäße Lösung.
Android Entwickler
Die offizielle Unterstützung von Kotlin durch Google hat dazu geführt, dass viele Android-Entwickler auf Kotlin umgestiegen sind. Die Sprache integriert sich nahtlos in die Android-Plattform und verbessert die Lesbarkeit und Produktivität.
Unternehmen, die Java-Code weiterentwickeln wollen
Kotlin ist so konzipiert, dass es mit vorhandenem Java-Code interoperabel ist. Dadurch können Unternehmen schrittweise von Java zu Kotlin wechseln, ohne ihre bestehende Codebase vollständig zu überarbeiten. Kotlin ist somit eine attraktive Option für Organisationen, die ihre Java-Anwendungen modernisieren möchten.

Die Vielseitigkeit von Kotlin macht es zu einer interessanten Wahl für verschiedene Entwicklungsszenarien, sodass ich mich für Kotlin entschied.

Gemeinsamkeiten und Interoperabilität

Obwohl Kotlin und Java sich in Syntax und Designphilosophie unterscheiden, teilen sie einige grundlegende Gemeinsamkeiten, die ihre Interoperabilität und Integration ermöglichen.

Lauffähigkeit auf der Java Virtual Machine (JVM)
Beide Sprachen werden in Bytecode übersetzt und sind daher auf der JVM ausführbar. Diese Kompatibilität ermöglicht es Entwicklern, Kotlin- und Java-Code in derselben Anwendung zu verwenden, was einen schrittweisen Übergang oder die gemeinsame Nutzung von Bibliotheken ermöglicht.
Interoperabilität
Kotlin ist so konzipiert, dass es nahtlos mit Java interagiert. Das bedeutet, dass bestehende Java-Bibliotheken ohne Probleme in Kotlin-Projekten verwendet werden können und umgekehrt. Dies erleichtert den Übergang von Java zu Kotlin und unterstützt eine schrittweise Migration.
Verwendung des gleichen Bytecodes
Da beide Sprachen denselben Bytecode erzeugen, können Entwickler von den Vorteilen beider Sprachen profitieren, ohne sich auf eine einzige festlegen zu müssen.
Entwicklungsumgebung und Build-Tools
Kotlin und Java können mit denselben Entwicklungsumgebungen und Build-Tools verwendet werden. Dies erleichtert die Integration von Kotlin in bestehende Entwicklungsworkflows.

Diese Gemeinsamkeiten erleichtern die Entscheidung für oder gegen Kotlin, insbesondere bei einer schrittweisen Einführung oder Integration in bestehende Java-Projekte.

Nachteile von Kotlin

Trotz der vielen Vorteile von Kotlin gibt es auch einige Nachteile, insbesondere im Kontext von Spring Boot. 

Kotlin ist trotz seiner 13 Jahre eine noch relativ neue Sprache, was bedeutet, dass sie noch nicht so weit verbreitet ist wie Java. Es ist wichtig, dass Entwickler, die mit Kotlin arbeiten, Erfahrung mit der Sprache haben oder bereit sind, sie zu erlernen. Dies liegt daran, dass es in Kotlin einige Unterschiede zu Java gibt, die verstanden werden müssen. Zudem kann es zu Problemen bei der Suche nach Dokumentation, Bibliotheken und Unterstützung kommen. Beispielsweise gibt es für Java eine große Auswahl an Bibliotheken, die von einer großen Community von Entwicklern unterstützt werden. 

Die Dokumentation von Kotlin erwies sich gelegentlich als weniger hilfreich, insbesondere bei komplexeren Themen oder spezifischen Spring-Anforderungen. Dies führte dazu, dass ich auf eine Kombination aus Trial-and-Error und der Suche nach alternativen Lösungen angewiesen war. Bei einigen Abhängigkeiten, wie zum Beispiel Lombok oder Mockito für Tests, traten Probleme auf, die nicht unmittelbar gelöst werden konnten. Die Anpassung an alternative Bibliotheken, wie Mockk oder andere, wurde notwendig, um reibungslose Testläufe zu gewährleisten. 

Eine der Hürden war die begrenzte Verfügbarkeit von Online-Ressourcen. Oftmals waren die vorhandenen Informationen veraltet oder bezogen sich auf veraltete Versionen, da Kotlin regelmäßig Updates erhält, welche die Sprache auch oft stark verändert. Dies erschwerte die Suche nach aktuellen Lösungen für spezifische Probleme im Spring-Ökosystem. 

Kotlin-Code kann in einigen Fällen auch schwieriger zu debuggen sein als Java-Code. Beispielsweise kann ein NullPointerException in Kotlin schwieriger zu finden sein als in Java. Dies liegt daran, dass Kotlin eine Null-safe Sprache ist und daher NullPointerExceptions wesentlich seltener auftreten und im Code daher schwieriger zu finden sind.

Vorteile von Kotlin

Trotz der genannten Herausforderungen bietet Kotlin zahlreiche Vorteile, die die Entscheidung für diese Sprache rechtfertigen. Ein herausragendes Merkmal von Kotlin ist die Möglichkeit, denselben Funktionalitätsgrad wie in Java mit weniger Code auszudrücken. Dadurch wird der Code lesbarer und wartbarer. 

Die klare und prägnante Syntax, die Integration von Null-Sicherheit, sowie Erweiterungsfunktionen und Datenklassen ermöglichen eine effiziente und wartungsfreundliche Codebasis. Kotlin fördert eine moderne Herangehensweise an die Softwareentwicklung und verbessert die Lesbarkeit des Codes erheblich. 

Die breite Akzeptanz und Unterstützung in der Entwicklergemeinschaft, insbesondere im Android-Bereich, unterstreichen die Relevanz und Zukunftsfähigkeit von Kotlin als Programmiersprache.

Kotlin im Spring Boot Projekt: Eine strategische Entscheidung

Die Entscheidung, Kotlin für ein Spring Boot-Projekt zu wählen, basierte auf überzeugenden Faktoren, die zu einer verbesserten Entwicklungsqualität und Effizienz beitrugen. Die klare und prägnante Syntax von Kotlin trug erheblich zur Lesbarkeit des Codes bei. Durch den Einsatz von Kotlin konnten komplexe Java-Konstruktionen in einfachere und lesbarere Ausdrücke übersetzt werden. 

Dank der statischen Typisierung von Kotlin kann der Compiler viele Fehler bereits während der Entwicklungszeit erkennen. Die Typinferenz von Kotlin ermöglicht es Entwicklern, sichereren Code zu schreiben, indem sie in vielen Fällen auf explizite Typdeklarationen verzichten können.

Die nahtlose Integration von Kotlin und Java ermöglicht einen schrittweisen Übergang und die Nutzung von bestehendem Java-Code. Besonders in einem Spring-Projekt, in dem viele Bibliotheken und Frameworks in Java geschrieben sind, ist dies von großer Bedeutung. Die Interoperabilität erleichtert die Migration zu Kotlin, ohne dass vorhandene Ressourcen verloren gehen.

Kotlin bietet außerdem Erweiterungsfunktionen, mit denen Entwickler bestehende Klassen um neue Funktionen erweitern können, ohne den Originalcode zu ändern. Dies trägt zur Modularität des Codes bei und kann auch die Performance optimieren, indem spezifische Funktionen effizienter implementiert werden.

Bei der Entscheidung sollten vor allem die individuellen Anforderungen berücksichtigt werden. Kotlin kann zum Beispiel eine gute Wahl sein für Anwendungen mit kurzen Entwicklungszeiten und -kosten, Anwendungen, die von Entwicklern mit Erfahrung in anderen objektorientierten Sprachen entwickelt werden, oder Anwendungen, die auf mehreren Plattformen ausgeführt werden sollen.

Insgesamt trugen diese Aspekte dazu bei, dass die Verwendung von Kotlin in einem Spring-Projekt zu einer angenehmeren und produktiveren Entwicklungszeit führte. Die Entscheidung für Kotlin war eine strategische Wahl, die die Vorteile moderner Sprachen mit der bewährten Stabilität von Spring kombinierte.

Fazit und persönliche Meinung

Kotlin hat sich in meinem Fullstack Spring Boot-Projekt als überzeugende Alternative zu Java erwiesen. Die klare Syntax, die Reduzierung von Boilerplate-Code, die Integration von Null-Sicherheit und die nahtlose Interoperabilität mit Java trugen dazu bei, die Entwicklungszeit zu optimieren und die Codequalität zu verbessern.

Die Entscheidung für Kotlin war nicht nur technologisch, sondern auch strategisch. Kotlin ist aufgrund seiner Vielseitigkeit und modernen Sprachfunktionen eine attraktive Option für verschiedene Entwicklungszenarien. Obwohl Java nach wie vor eine robuste Sprache ist, bietet Kotlin eine zeitgemäße Alternative, insbesondere für Entwickler, die effizienter arbeiten und die Vorteile moderner Programmierkonzepte nutzen möchten.

In der dynamischen Landschaft der Softwareentwicklung bleibt die Entscheidung zwischen Java und Kotlin letztlich eine Frage der spezifischen Anforderungen und Präferenzen. Kotlin hat sich jedoch als eine Sprache etabliert, die nicht nur die Schwächen von Java adressiert, sondern auch neue Maßstäbe in Bezug auf Effizienz und Lesbarkeit setzt.

Aus meiner persönlichen Perspektive war die Entscheidung, Kotlin für das Projekt zu wählen, durchweg positiv. Trotz des potenziellen Mangels an Online-Ressourcen und der anfänglichen Lernkurve empfand ich die Vorteile von Kotlin als überzeugend. Die moderne Sprachfunktionalität, die Reduzierung von Boilerplate-Code und die nahtlose Integration mit Java machten den Umstieg lohnenswert. Die Entscheidung, sich auf neue Erfahrungen einzulassen und die Vorteile von Kotlin zu nutzen, trug nicht nur zur erfolgreichen Umsetzung des Projekts bei, sondern erweiterte auch meinen persönlichen Horizont in Bezug auf moderne Programmiersprachen.

Der Beitrag Kotlin vs. Java im Praxischeck: Ein Spring Boot Erfahrungsbericht erschien zuerst auf INOTEQ GmbH.

Entwicklung einer Spring Boot-Anwendung mit Thymeleaf und Tailwind CSS

Alexander Kusmin — Fri, 15 Dec 2023 09:47:55 +0000

Entwicklung einer Spring Boot-Anwendung mit Thymeleaf und Tailwind CSS

Moderne Webentwicklung erfordert nicht nur eine robuste Backend-Infrastruktur, sondern auch leistungsstarke Werkzeuge für die Gestaltung ansprechender Benutzeroberflächen. Dieser Beitrag enthält eine Schritt-für-Schritt-Anleitung zur Entwicklung einer Web-Anwendung mit Spring Boot mit Thymeleaf und Tailwind CSS via Gradle-Node-Plugin. Diese Kombination ermöglicht die Implementierung dynamischer Inhalte sowie die Erstellung responsiver und modernen Benutzeroberflächen.

Setup von Spring Boot

Es wird eine Spring Boot Anwendung mit folgender Konfiguration benötigt:

Spring Boot Version 3.2.0
Kotlin als Programmiersprache für Spring
Kotlin (Groovy) für das Build-Tool
Abhängigkeit Spring Web v3.2.0

Diese Konfiguration kann hier über den Spring Initializr direkt heruntergeladen werden. Mit dem Befehl ./gradlew bootRun wird die Anwendung gestartet und anschließend unter der Adresse http://localhost:8080 erreichbar.

Integration von Thymeleaf

Thymeleaf ist eine leistungsfähige Template-Engine für die Webentwicklung und ermöglicht die Integration dynamischer Inhalte in Seiten. In der Datei build.gradle wird die Thymeleaf-Abhängigkeit eingebunden:

./build.gradle

...
dependencies {
    ...

    implementation 'org.springframework.boot:spring-boot-starter-thymeleaf:3.2.0'
}
...

Thymeleaf-Templates

Zu Beginn wird im Ressourcenverzeichnis ein neues Thymeleaf-Template src/main/resources/templates/index.html erstellt. Dieses Template zeigt einen Text als Überschrift an, der mithilfe von Thymeleaf aus den Ressourcen geladen wird. Dazu legen wir im Ressourcenverzeichnis eine Datei src/main/resources/messages.properties an, in der die Texte definiert werden. An sich mag dies für unser Beispiel etwas umständlich sein, jedoch ermöglicht dieser Ansatz später eine einfachere Übersetzung der Anwendung, indem der Inhalt der messages.properties pro Sprache vorliegt.

index.html

messages.properties

index.html




    
    Index


ignored

messages.properties

myIndexText=This is index!

Mit th: werden Thymeleaf-Anweisungen eingeleitet. In diesem Fall wird Thymeleaf angewiesen, den Text-Inhalt für das Element zu definieren. Mit #{...} werden Ressourcen über einen eindeutigen Schlüssel angefordert, hier der Text This is index mit dem Schlüssel myIndexText aus der zuvor definierten messages.properties. Auf der offiziellen Seite von Thymeleaf sind alle Funktionen ausführlich und mit vielen Beispielen dokumentiert.

Spring Boot Controller

Damit die Spring Boot Anwendung auch die Seite anzeigt, muss ein Controller erstellt werden, welcher das Template für den Endpunkt rendert.

./src/main/.../DemoController.kt

package com.example.demo

import org.springframework.stereotype.Controller
import org.springframework.ui.Model
import org.springframework.web.bind.annotation.GetMapping
import org.springframework.web.bind.annotation.RequestMapping

@Controller
@RequestMapping
class DemoController {
    @GetMapping("/")
    fun myIndexEndpoint(model: Model): String {
        return "index"
    }
}

Erweiterung des Beispiels mit weiteren Thymeleaf Funktionen

Die Seite unter http://localhost:8080 wird nun wie folgt erweitert:

Dem Template wird eine Liste von Strings übergeben. Diese Strings stellen weitere Endpunkte namens /foo, /bar und /baz dar.
Der bisherige Controller wird für die weiteren Endpunkte entsprechend erweitert.
Die Endpunkte zeigen wie zuvor die Index-Seite nur einen Text an. Es werden dafür Templates erstellt.
Das aktuelle Index-Template verweist auf diese Endpunkte mit einer Navigation.

DemoController.kt

messages.properties

index.html

foo.html

bar.html

baz.html

DemoController.kt

...
@Controller
@RequestMapping
class DemoController {
    @GetMapping("/")
    fun myIndexEndpoint(model: Model): String {
        model.addAttribute("myEndpoints", listOf("foo", "bar", "baz"))
        return "index"
    }

    @GetMapping("/foo")
    fun fooEndpoint(): String = "foo"

    @GetMapping("/bar")
    fun barEndpoint(): String = "bar"

    @GetMapping("/baz")
    fun bazEndpoint(): String = "baz"
}

messages.properties

myIndexText=This is index!
myNavigateText=Navigate to {0}
myFooText=This is foo!
myBarText=This is bar!
myBazText=This is baz!

index.html

...

...

    ignored


...

foo.html




    
    Foo


ignored

bar.html




    
    Bar


ignored

baz.html




    
    Baz


ignored

Unsere Anwendung sieht nun folgendermaßen aus:

Styling mittels Tailwind CSS

Die Integration von Tailwind CSS in die Spring Boot Anwendung bietet eine flexible und leistungsstarke Styling-Option für das Frontend. Dieses Kapitel beschreibt die Integration und Verwendung von Tailwind CSS.

Verwendung des Gradle Plugin für Node und Konfiguration von Tailwind CSS

Für die Integration von Tailwind CSS in die Spring Boot Anwendung wird das Gradle Node Plugin verwendet. Dies ermöglicht eine Verwaltung der Node.js-Abhängigkeiten wie z.B. Tailwind CSS direkt aus Gradle heraus. Um das Plugin in das Projekt einzubinden, muss die Gradle-Konfiguration folgendermaßen angepasst werden:

Wir fügen das Plugin gradle-node-plugin hinzu.
Es wird ein neuer Gradle-Task registriert, die den Tailwind CSS zur Generierung der output.css ausführt.
Die Gradle-Task npmInstall wird so angepasst, dass npm die benötigten Pakete selbständig installiert.
Die Gradle-Task für die Kompilierung mit Kotlin wird so angepasst, dass Tailwind CSS immer vor der Kompilierung ausgeführt wird.

Zusätzlich müssen die beiden Dateien tailwind.config.js und package.json entsprechend angelegt werden.

build.gradle

tailwind.config.js

package.json

build.gradle

...
plugins {
    ...
    // Gradle plugin for Node
    id 'com.github.node-gradle.node' version '7.0.1'
}
...
// Necessary for node-gradle plugin
node {
    download = true
}

// This task will run `tailwindcss` command and generate the output.css file from styles.css
tasks.register('tailwind', NpxTask) {
    command = 'tailwindcss'
    args = ['-i', './src/main/resources/static/styles.css', '-o', './src/main/resources/static/output.css']

    // This task depends on npmInstall task
    dependsOn(tasks.npmInstall)
}

// Make npmInstall task depend on npmSetup task and adds package.json as input
tasks.npmInstall {
    inputs.file('package.json')
    dependsOn(tasks.npmSetup)
}

tasks.withType(KotlinCompile).configureEach {
    ...
    // Update the output.css file every time after compiling Kotlin code
    dependsOn(tasks.tailwind)
}
...

tailwind.config.js

/** @type {import('tailwindcss').Config} */
module.exports = {
    content: ["./src/**/*.{html,js}"],
}

package.json

{
  "devDependencies": {
    "@tailwindcss/forms": "^0.5.7",
    "tailwindcss": "^3.3.6"
  }
}

Der Gradle-Befehl ./gradlew tailwind ist nun ausführbar und sollte bei korrekter Konfiguration folgende Ausgabe erzeugen:

Verwendung von Tailwind CSS

Unser Beispiel wird nun mit Hilfe von Tailwind CSS erweitert. Dazu können die Tailwind CSS Klassen direkt im Template verwendet oder in der styles.css unter src/main/resources/static gesammelt werden. Die dort enthaltenen Klassen werden dann von Tailwind CSS in output.css gebündelt. Für dieses Beispiel wird auch die einfache Unterstützung von Responsive Design durch Tailwind CSS genutzt. So soll die Index-Seite auf einem kleineren Bildschirm die Menüpunkte zeilenweise auflisten, ansonsten spaltenweise. Wichtig ist, dass die output.css in den Thymeleaf-Templates korrekt verlinkt wird.

styles.css

index.html

styles.css

@tailwind base;
@tailwind components;
@tailwind utilities;

body {
    @apply bg-gray-200 w-full p-4 flex flex-col gap-4 items-center justify-center;
}

.headline {
    @apply text-4xl font-extrabold leading-none tracking-tight;
}

.headline-white {
    @apply text-white;
}

.btn {
    @apply font-bold py-2 px-4 rounded;
}
.btn-blue {
    @apply bg-blue-500 text-white;
}
.btn-blue:hover {
    @apply bg-blue-700;
}

index.html




    
    Index
    


ignored

    ignored

foo.html




    
    Foo
    


ignored

bar.html




    
    Bar
    


ignored

baz.html




    
    Baz
    


ignored

Schlusswort

Es ist wichtig anzumerken, dass dieser Ansatz, wie jeder andere auch, Vor- und Nachteile hat. Thymeleaf ermöglicht eine nahtlose Integration von Backend- und Frontend-Logik, könnte aber bei komplexeren Frontend-Anforderungen an seine Grenzen stoßen. Tailwind CSS bietet eine unübertroffene Flexibilität beim Styling, aber die umfangreichen Klassen können zu überladenem HTML-Code führen.

Für weitere Details steht das GitHub Repository zur Verfügung, das alle im Artikel beschriebenen Schritte und Konfigurationen enthält.

Der Beitrag Entwicklung einer Spring Boot-Anwendung mit Thymeleaf und Tailwind CSS erschien zuerst auf INOTEQ GmbH.

Integration von OAuth 2.0 in Spring Boot mit Keycloak

Alexander Kusmin — Thu, 30 Nov 2023 07:00:00 +0000

Integration von OAuth 2.0 in Spring Boot mit Keycloak

Der Beitrag ist dabei so strukturiert, dass Entwickler Schritt für Schritt eine sichere Authentifizierung in einer Spring Boot-Anwendung implementieren können.

Spring Boot: Setup und Grundkonfiguration

Konfiguration

Die Vorbereitung der Spring Boot Anwendung für die Integration von OAuth 2.0 beginnt mit der Einrichtung des Projektes.

Für diesen Leitfaden wurde folgende Konfiguration gewählt:

Spring Boot v3.2.0
Kotlin als Programmiersprache für Spring
Gradle (Groovy) für das Build-Tool

Als Vorbereitung für die spätere Integration von OAuth 2.0 werden zudem noch folgende Abhängigkeiten benötigt:

Diese Konfiguration bildet die Grundlage für die Entwicklung der Webanwendung mit integriertem OAuth 2.0 als Sicherheitsmechanismus. Die spezifische Konfiguration kann als neues leeres Projekt hier über den Spring Initializr direkt geladen werden.

Anwendung für OAuth 2.0 vorbereiten

Bevor die Anwendung erstmalig gestartet wird, sollten noch die folgenden Anpassungen vorgenommen werden. Durch die Einbindung der Spring Security Abhängigkeit, ist bereits die gesamte Anwendung mit allen Endpunkten standardmäßig mit einer simplen User/Passwort-Authentifizierung abgesichert. Da OAuth 2.0 später nur für bestimmte Endpunkte verwendet werden soll, ist eine entsprechende Konfiguration von Spring Security erforderlich, bei der diese grundlegende Authentifizierung durch eine Annotation in der Datei DemoApplication.kt vorerst deaktiviert wird. Zu Testzwecken wird ein Endpunkt in einem neuen Controller DemoController.kt definiert. Der Endpunkt und die Deaktivierung der Authentifizierung werden zu einem späteren Zeitpunkt wieder entfernt, wenn OAuth 2.0 konfiguriert wird.

src/main/kotlin/.../DemoApplication.kt

src/main/kotlin/.../DemoController.kt

src/main/kotlin/.../DemoApplication.kt

package com.example.demo

import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.autoconfigure.security.servlet.SecurityAutoConfiguration
import org.springframework.boot.runApplication

// Deaktivierung der default Authentifizierung von Spring Security
@SpringBootApplication(exclude = [SecurityAutoConfiguration::class])
class DemoApplication

fun main(args: Array) {
    runApplication(*args)
}

src/main/kotlin/.../DemoController.kt

package com.example.demo

import org.springframework.web.bind.annotation.RequestMapping
import org.springframework.web.bind.annotation.RestController

@RestController
class DemoController {
    @RequestMapping("/")
    fun helloWorld() = "Hello World!"
}

Mit dem Befehl ./gradlew bootRun wird die Anwendung über das Terminal gestartet und ist anschließend unter der Adresse http://localhost:8080 erreichbar.

Als Vorbereitung für die spätere Integration von OAuth 2.0 werden zwei weitere Endpunkte implementiert — ein öffentlicher Endpunkt /public und ein privater Endpunkt /private, welcher später nur für authentifizierte Benutzer aufrufbar sein soll. Unser „Hello World!“ Endpunkt wird wieder entfernt:

./src/main/kotlin/.../DemoController.kt

package com.example.demo

import org.springframework.web.bind.annotation.RequestMapping
import org.springframework.web.bind.annotation.RestController

@RestController
class DemoController {
    @RequestMapping("/", "/public")
    fun publicEndpoint() = "Hello from a public endpoint!"

    @RequestMapping("/private")
    fun privateEndpoint() = "Hello from a private endpoint!"
}

Im Folgenden wollen wir mit OAuth 2.0 den Endpunkt /private absichern, der in diesem Zustand noch ohne Authentifizierung erreichbar ist.

Mögliche Herrausforderungen Bei der Integration von Spring Security und OAuth 2.0 können Herausforderungen wie Konfigurationskonflikte und unerwartetes Verhalten auftreten. Es ist ratsam sicherzustellen, dass die Versionen der verwendeten Abhängigkeiten konsistent sind. Eine Überprüfung der Logdateien auf mögliche Fehlermeldungen ist ratsam.

Installation & Konfiguration von Keycloak

Keycloak ist eine Open-Source-Identitäts- und Zugriffsmanagementlösung. Es fungiert als OAuth 2.0 Server und ermöglicht die Authentifizierung von Benutzern, die Verwaltung von Anwendungs-Berechtigungen und die Bereitstellung von Single Sign-On für Anwendungen.

Einrichtung mit Docker

Die Verwendung von Docker ermöglicht den Betrieb einer konsistente und isolierte Umgebung für Keycloak. Zusätzlich wird die Einrichtung erleichtert und sichergestellt, dass alle erforderlichen Abhängigkeiten vorhanden sind und reibungslos funktionieren. Da bereits eine ausführliche Anleitung auf der offiziellen Keycloak-Seite zu finden ist, wird im Folgenden nur noch auf die relevanten Punkte eingegangen. Bevor Keycloak in einem Docker-Container gestartet werden kann, sollten sichergestellt werden, dass Docker auf dem System installiert und einsatzbereit ist. Dies kann mit dem Befehl docker −−version getestet werden, wobei Die Ausgabe die Installierte Docker-Version anzeigen muss. Eine Installationsanleitung für Docker selbst kann der offziellen Seite entnommen werden. Zur eigentlichen Installation und Starten von Keycloak verwenden wir folgenden Befehl:

docker run -p 8081:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak start-dev

Der Befehl setzt sich dabei folgendermaßen zusammen:

docker run Anweisung an Docker den Container mit den Parametern zu starten
-p 8081:8080 Portmapping von 8081 (Container außen) zu 8080 (Container innen)
-e KEYCLOAK_ADMIN=admin Benutzername für das Keycloak Webinterface
-e KEYCLOAK_ADMIN_PASSWORD=admin Passwort für das Keycloak Webinterface
quay.io/keycloak/keycloak URL auf das Docker-Image für Keycloak
start-dev Startet Keycloak innerhalb des Docker-Containers

Ausgabe von Docker für Keycloak

Sofern lokal noch kein Keycloak Docker-Image existiert, wird dieses automatisch heruntergeladen. Wenn der Befehl ausgeführt wird, startet ein neuer Keycloak-Container, welcher über http://localhost:8081 erreichbar ist. In der Administrationskonsole unter http://localhost:8081/admin kann sich mit den definierten Benutzerdaten angemeldet werden, um Keycloak für den OAuth 2.0 Server zu konfigurieren.

OAuth 2.0 Server Konfiguration

In der Administrationskonsole wird zuerst neuer Realm für die Anwendung erstellt. Bei einem Realm in Keycloak handelt es sich um eine isolierte Sicherheitsdomäne, die Benutzer, Ressourcen und Einstellungen in einem OAuth 2.0 Server organisiert. Auf diese Weise ist eine flexible Verwaltung verschiedener Anwendungen in ein und derselben Keycloak-Instanz möglich. Standardmäßig ist der build-in Realm master ausgewählt. Der Reiter wird angeklickt und über die Schaltfläche Create realm wird ein neuer Realm erstellt. Beim Anlegen wird ein Name vergeben demo-realm vergeben , und sichergestellt, dass dieser aktiv ist.

Nun müssen wir für die Anwendung ein Mandant anlegen. Ein Mandant in Keycloak repräsentiert eine Anwendung, die OAuth 2.0 oder OpenID Connect zur Authentifizierung und Autorisierung verwendet. Jeder Mandant hat eine eindeutige Identität und Konfiguration und kann Ressourcen in einem bestimmten Realm schützen. Beispiele für Mandanten sind Webanwendungen, mobile Anwendungen oder Dienste, die Zugriff auf geschützte Ressourcen benötigen. Zur Erstellung eines neuen Mandanten kann im Menüpunkt Clients der Button Create client angeklickt werden, worauf ein Formular erscheint, das in drei Schritte gegliedert ist:

Schritt: Für den Client wird der Typ OpenID Connect ausgewählt und die Client-ID demo-client vergeben .
Schritt: In diesem Schritt muss sichergestellt werden, dass unter „Authentication flow“ die Option Standard flow aktiviert ist. Die Aktivierung der Option „Standard flow“ in Keycloak ist entscheidend, um die Sicherheit zu erhöhen, indem der Authentifizierungsprozess in zwei Schritte aufgeteilt wird: Der Benutzer authentifiziert sich am Autorisierungsserver und tauscht sicher einen temporären Autorisierungscode gegen Zugriffstoken aus. Dies minimiert das Risiko, sensible Informationen am Frontend preiszugeben, insbesondere bei serverseitigen Anwendungen wie Spring Boot.
Schritt: Hier wird im Feld Valid redirect URIs die URL http://localhost:8080/* eingetragen und alle Eingaben mit einem Klick auf Save bestätigt. Dieser Eintrag ist erforderlich, damit Keycloak nach der Benutzerauthentifizierung die korrekte Rücksendeadresse für den Authorisierungscode erhält. Der Stern ermöglicht die Annahme gültiger Redirect-URIs für alle Pfade unter http://localhost:8080/. Dies bietet Flexibilität für verschiedene Endpunkte und unterstützt die sichere Rückgabe von Authentifizierungsantworten.

Damit wäre Keycloak bereits als OAuth 2.0 Server für die Anwendung konfiguriert.

Schritt 1 - Erstellung eines Mandanten in Keycloak

Schritt 2 - Erstellung eines Mandanten in Keycloak

Schritt 3 - Erstellung eines Mandanten in Keycloak

Rollenverwaltung

Die Benutzer müssen mit einem Rollenattribut versehen werden, welches über den Token an die Anwendung weitergegeben werden muss. Zu diesem Zweck muss der Mandant noch weiter konfiguriert werden.

Um eine neue Rolle anzulegen, wird über den Menüpunkt Clients in den angelegten Mandanten demo-client navigiert. Hier wird über den Reiter Roles und den Button Create role eine neue Rolle angelegt. Für die neue Rolle wird der Rollenname demo-role gewählt und anschließend mit dem Button Save bestätigt. Der Mandant muss nun so konfiguriert werden, dass diese Rolle im Token enthalten ist. Nach erfolgreicher Authentifizierung generiert Keycloak das Token, welches Informationen über den Benutzer sowie gewährte Berechtigungen enthält. Die Anwendung nutzt das Token zur Identifikation des Benutzers und für entsprechende Aktionen basierend auf den Tokeninformationen. Dazu wird im Reiter „Client scopes“ zu „demo-client-dedicated“ navigiert und dort mit „Add predifined mapper“ ein neuer Token-Mapper für client roles definiert. Das Ganze wird mit „Add“ bestätigt. Ein Klick auf den neu angelegten Eintrag „client roles“ öffnet weitere Einstellungen. Hier wird für „Token Claim Name“ ein Wert festgelegt, z.B. roles , die Option „Add to ID token“ aktiviert und die Änderungen mit „Save“ bestätigt. Nun enthält das Token in der Anwendung über ein Attribut mit dem Schlüssel „roles“ alle Rollen des Benutzers.

Navigation zum Mandanten-Geltungsbereich

Ansicht zu Hinzufügen eines neuen Token-Mappers

Ausgewählter Token-Mapper für Mandanten-Rollen

Konfiguration des Token-Mappers

Benutzerverwaltung

Um sich später in der Spring Boot Anwendung anmelden zu können, muss ein Benutzer definiert werden. Dazu wird ein neuer Benutzer im Realm angelegt. Das Formular zur Eingabe der Benutzerdaten wird über den Menüpunkt Users und den Button Add user aufgerufen. Im Rahmen dieses Leitfadens wird ein Benutzer mit dem Benutzernamen john.doe , dem Vor- und Nachnamen John Doe und der E-Mail-Adresse john.doe@example.com angelegt. Es ist nicht erforderlich, weitere Einstellungen zu ändern.

Für den neu angelegten Benutzer muss noch ein Passwort festgelegt werden. Dazu reicht es zunächst aus, im Benutzer unter dem Reiter Credentials und dem Button Set password ein neues, nicht temporäres Passwort zu setzen, z.B. password . Unter dem Reiter Role mapping wird dem Benutzer die zuvor angelegte Gruppe zugewiesen. Dazu wird auf Assign role geklickt und der Filter so eingestellt, dass die Mandantenrollen angezeigt werden. Anschließend wird die Rolle (demo-client) demo-role ausgewählt und mit Assign bestätigt.

Unter „http://localhost:8081/realms/demo-realm/account“ kann durch Anmelden mit dem angelegten Benutzer überprüft werden, ob dieser korrekt angelegt und konfiguriert wurde.

OAuth 2.0 Konfiguration in Spring Boot

Anpassen der Anwendungseigenschaften

Der erste Schritt bei der Konfiguration von OAuth 2.0 in der Anwendung ist die Anpassung der Datei application.yml. Dabei wird ein Provider demo-provider definiert, der auf den Realm verweist, und ein Client demo-client registriert:

./application.yml

spring:
  security:
    oauth2:
      client:
        provider:
          # provider name used for registration
          demo-provider:
            # Keycloak realm URL: "{keycloak-url}/realms/{realm-name}"
            issuer-uri: http://localhost:8081/realms/demo-realm
        registration:
          # client-id from Keycloak client configuration
          demo-client:
            # provider from above
            provider: demo-provider
            # client-id from Keycloak client configuration
            client-id: demo-client
            scope: openid
            # default redirect URI: "{baseUrl}/login/oauth2/code/{registrationId}"
            redirect-uri: http://localhost:8080/login/oauth2/code/demo-client

Spring Security Konfiguration

Zusätzlich muss noch eine Konfiguration für Spring Security erstellt werden. Dazu wird eine neue Klasse SecurityConfiguration.kt erstellt, in der die Filterkette so konfiguriert wird, dass für den Endpunkt /private ein Benutzer mit OAuth 2.0 erfolgreich angemeldet sein muss. Mit der Syntax /private/** werden alle Endpunkte gesichert. Es müssen nicht alle einzeln angegeben werden.

./src/main/kotlin/.../SecurityConfiguration.kt

package com.example.demo

import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.springframework.security.config.Customizer
import org.springframework.security.config.annotation.web.builders.HttpSecurity
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity
import org.springframework.security.web.SecurityFilterChain

@Configuration
@EnableWebSecurity
class SecurityConfiguration {
    @Bean
    fun securityFilterChain(http: HttpSecurity): SecurityFilterChain =
        http
            .authorizeHttpRequests {
                it
                    // Only allow authenticated users here
                    .requestMatchers("/private/**")
                    .fullyAuthenticated()
                    // Allow all other requests
                    .anyRequest()
                    .permitAll()
            }
            // Use OAuth 2.0 Login to handle authentication
            .oauth2Login(Customizer.withDefaults())
            .build()
}

Wurde die automatische Konfiguration von Spring Security per Annotation deaktiviert, wie wir es anfangs zu Testzwecken gemacht haben, muss sichergestellt werden, dass sie wieder aktiviert wird. Um dies zu erreichen, muss der Parameter aus der @SpringBootApplication() Annotation in der Datei DemoApplication.kt entfernt werden. Die Annotation selbst muss bestehen bleiben. Die Anwendung kann nun gestartet werden. Unter dem Endpunkt /public sollte keine Authentifizierung abgefragt werden und es wird lediglich „Hello from a public endpoint!“ angezeigt. Wird zum Endpunkt /private navigiert, so navigiert die Anwendung zunächst zum OAuth 2.0 Server. Hier kann eine Anmeldung mit dem Benutzer john.doe und dem Passwort password erfolgen. Anschließend sollte eine automatische Weiterleitung zurück zur urpsürnglichen Seite erfolgen. Nun wird der Text „Hello from a private endpoint!“ angezeigt.

Ausgabe auf http://localhost:8080/ bzw. http://localhost:8080/public

Anmeldung beim Versuch den privaten Endpunkt aufzurufen

Ausgabe auf http://localhost:8080/private, wenn sich erfolgreich angemeldet wurde

Ausgabe der Informationen vom Token

Sobald ein Benutzer die Anwendung aufruft, wird in der Anwendung ein Benutzerobjekt erzeugt. Wenn der Benutzer sich nicht authentifiziert hat, z.B. am öffentlichen Endpunkt, wird der Benutzer als anonym behandelt. Sobald jedoch eine erfolgreiche Anmeldung über OAuth 2.0 erfolgt ist, wird ein entsprechendes Objekt mit dem erhaltenen Token erzeugt. Aus diesem Objekt können die Benutzerinformationen ausgelesen und für die Anwendung verwendet werden.

Ein wird nun ein weiterer Endpunkt zur Ausgabe dieser Daten hinzugefügt. Da alle Endpunkte bereits unter /private abgesichert sind, wird der neue Endpunkt unter „http://localhost:8080/private/user“ abgelegt. Die Benutzerinformationen können über den Kontext geladen werden. Dabei ist zu beachten, dass eine Konvertierung in einen OAuth2User vorgenommen wird. Die Umwandlung eines Principal-Objekts in ein OAuth2User-Objekt in Spring Boot ist sinnvoll, wenn erweiterte Benutzerinformationen aus dem OAuth 2.0-Token benötigt werden. Das OAuth2User-Objekt stellt standardisierte Methoden für den Zugriff auf diese Informationen bereit und erleichtert somit eine einheitliche Verarbeitung von OAuth 2.0-basierten Benutzerdaten in Spring-Boot-Anwendungen. Nach der Umwandlung kann auf die Attribute des Benutzers zugegriffen werden. In diesem Fall werden Name, E-Mail-Adresse und alle zugehörigen Rollen ausgegeben.

./src/main/kotlin/.../DemoController.kt

...
@RequestMapping("/private/user")
    fun userEndpoint(): String {
        val user = SecurityContextHolder.getContext().authentication.principal as OAuth2User
        return "Name: ${user.attributes["name"]}, " +
            "Email: ${user.attributes["email"]}, " +
            "Roles: ${user.attributes["roles"]}"
    }
...

Die Anwendung kann neu gestartet und der neue Endpunkt getestet werden. Wird zum Endpunkt /private/user navigiert, findet eine erneute Authentifizierung statt. Möglicherweise geschieht dies automatisch, da das Cookie vom OAuth-Server noch gespeichert ist. Auf der Seite wird dann folgendes angezeigt:

Entwicklungsperspektiven

Die Integration von Keycloak in Spring Boot ermöglicht eine effiziente und sichere Authentifizierung. Entwickler profitieren vom externen Authentifizierungsmanagement, können sich auf Kernfunktionen konzentrieren und Sicherheitsaspekte einfach implementieren. Die Flexibilität durch die Konfigurierbarkeit von Keycloak erlaubt die Anpassung an spezifische Anforderungen. Die Basis von Keycloak legt zudem den Grundstein für zukünftige Erweiterungen, ohne die Anwendungslogik stark verändern zu müssen. Die Flexibilität von Spring Boot ermöglicht es, auch andere OAuth 2.0 Server wie Azure, ADFS und mehr zu integrieren. Dadurch können Entwickler die Authentifizierungslösung an die spezifischen Anforderungen ihrer Anwendung anpassen.

Für weitere Details steht das GitHub Repository zur Verfügung, das alle im Artikel beschriebenen Schritte und Konfigurationen enthält, einschließlich eines vorkonfigurierten Keycloak Containers mit Docker.

Eine detaillierte Beschreibung der Funktionsweise von OAuth 2.0 und dem Zusammenspiel der verschiedenen Komponenten findet sich in dem verlinkten Artikel.

Sichern einer Spring Boot WebApp mit OAuth 2.0

Aymen Khalki 6. Mai 2021

Authentifizierung ist der erste Schritt in jedem Sicherheitssystem. Es ist der Prozess mit dem die Identität eines Clients verifiziert wird. Ob der Client Zugriff auf bestimmte Ressourcen erhält, wird allerdings durch den Autorisierungsprozess festgestellt. In diesem Artikel werden wir eine API mit Spring Boot erstellen und das OAuth 2.0 Authentifizierungsprotokoll verwenden, um diese API abzusichern. Table of Contents Eingehende Erläuterungen und Definitionen OAuth 2.0 OAuth 2.0 (Open Authentication) ist ein

Sichern einer Spring Boot WebApp mit OAuth 2.0

Aymen Khalki 6. Mai 2021

Sichern einer Spring Boot WebApp mit OAuth 2.0

Aymen Khalki 6. Mai 2021

Der Beitrag Integration von OAuth 2.0 in Spring Boot mit Keycloak erschien zuerst auf INOTEQ GmbH.