Übungsaufgaben zu Change Request und Keycloak: Zugriffsregeln, Tests mit Tokens und Fehlersuche für die Mitfahrgesuche

Übungsaufgaben zu Change Request und Keycloak: Zugriffsregeln, Tests mit Tokens und Fehlersuche für die Mitfahrgesuche

https://bildung.social/@oerinformatik/

https://oer-informatik.de/flurmonitor-change-request-keycloak-uebungsaufgaben

Change Request, Auswirkungsanalyse, OAuth 2.0, OpenID Connect, Keycloak, JWT, Resource Server, oauth2Login, SecurityFilterChain, Mitfahrgesuche, Übungsaufgaben, Prüfungsvorbereitung

tl/dr; (Bearbeitungszeit insgesamt 57 min, mehrere Aufgaben): Die Mitfahrgesuche bekommen nach dem Umbau auf Keycloak eigene Zugriffsregeln. In diesen Übungen legst Du Rollen und Regeln für Monitor, REST-API und Verwaltung fest, schreibst Integrationstests mit oidcLogin() und stellst die Anwendung auf einen anderen Keycloak um, findest die Ursachen von 401 und 403 anhand von Symptomen und analysierst die Auswirkungen eines weiteren Change Requests [AI-Assisted]. (Zuletzt geändert am 11.11.2026)

Dieser Artikel ist Teil einer Artikelreihe über den Flurmonitor mit Thymeleaf: Projektübersicht / Scrum-Projektstart / Thymeleaf einbinden / Templates / Ansichtsmodell / Integrationstest der Web-Schicht / Konfiguration und Formatierung / Aktualisierung / Hinweise mit Formularen / Robustheit und Betrieb / GUI-Test mit Selenium / Akzeptanztest / Change Request Keycloak

Diese Übungsaufgaben gehören zum Artikel Change Request Keycloak: Flurmonitor und REST-API mit OAuth 2.0 und OpenID Connect absichern. Alle Aufgaben spielen im Projektteam der Mitfahr-App Mitfahrlabor und setzen den Übungsstrang zu den Mitfahrgesuchen fort. Ausgangspunkt ist das Projekt im Ordner src/a12-change-request-keycloak des Backend-Repositorys mit Keycloak-Realm, den beiden Filterketten und dem Startcode der Gesuche im Unterordner uebung-mitfahrgesuche (Klassen GesuchService, MitfahrgesucheController und Seite flurmonitor-gesuche.html; kopiere sie in den Ordner mitfahrlabor).

Hinweise zur Bearbeitung: Als FIA, FIDP oder FIDV musst Du zur Teil-2-Prüfung Aufgaben auf Kernkompetenz-Ebene lösen können, das sind Aufgabe 2.1 und Aufgabe 2.2. Von FIA wird zusätzlich erwartet, dass ihnen Aufgaben auf Profilkompetenz-Ebene (Aufgabe 3.1 und Aufgabe 3.2) keine Probleme bereiten. Notiere Deine Antworten zuerst vollständig, bevor Du die Beispiellösung aufklappst. Code-Aufgaben prüfst Du am besten im Projekt: ./gradlew test führt die Komponenten- und Integrationstests aus, ohne dass Keycloak laufen muss. Für Versuche mit echten Tokens startest Du Keycloak wie im Artikel beschrieben auf Port 8180. Bei Begründungen, Bezeichnern und Tabelleninhalten sind andere fachlich richtige Lösungen ebenso richtig.

Du möchtest eigene Aufgaben zum Üben von einem KI-Sprachmodell generieren lassen? Prompt ein-/ausblenden

Erstelle neue Übungsaufgaben zum Thema „Change Request und Keycloak:
Zugriffsregeln, Tests mit Tokens und Fehlersuche für die
Mitfahrgesuche“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/flurmonitor-change-request-keycloak
- https://oer-informatik.de/szenario-mitfahrlabor
- Stilbeispiel: https://oer-informatik.de/flurmonitor-change-request-keycloak-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Change Request
- Auswirkungsanalyse
- OAuth 2.0
- OpenID Connect
- Keycloak
- JWT
- Resource Server
- oauth2Login
- SecurityFilterChain
- Mitfahrgesuche

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Aufgabe 2.1: Zugriffsregeln für die Mitfahrgesuche (Kernkompetenz)

(ca. 15 min Bearbeitungszeit)

Im Refinement nach Sprint 4 beschreibt das Folgeteam, wie die Mitfahrgesuche künftig genutzt werden sollen. Auszubildende geben über die App Gesuche auf und ziehen eigene Gesuche wieder zurück; die Schulverwaltung (Rolle ORGA) kann in der Verwaltung jedes Gesuch mit Begründung zurückziehen, etwa wenn es doppelt ist; die Monitore zeigen die Gesuche ohne Anmeldung. Die folgenden Anfragen sind geplant:

1. Ergänze die Tabelle mit Hilfe der SicherheitsKonfiguration aus dem Code-Stand a12: In welche Filterkette fällt die Anfrage, welche Regel soll gelten (öffentlich, angemeldet, Rolle …), und wie antwortet die Anwendung, wenn niemand angemeldet ist? (10 Punkte)

2. Ergänze in der Methode sicherheitsfilter die nötigen requestMatchers-Zeilen und gib an, an welcher Stelle sie stehen müssen. (4 Punkte)

.requestMatchers(HttpMethod.POST, "/v1/angebote", "/v1/angebote/*/buchungen").hasRole("NUTZER")
// MON-13g: Gesuche aufgeben nur NUTZER, zurückziehen NUTZER (eigene) oder ORGA
.requestMatchers(HttpMethod.POST, "/v1/gesuche").hasRole("NUTZER")
.requestMatchers(HttpMethod.DELETE, "/v1/gesuche/*").hasAnyRole("NUTZER", "ORGA")

3. Ben (Funkenflug) und Lina (Rotkehlchen) haben beide die Rolle NUTZER. Begründe, warum die Filterkette nicht verhindern kann, dass Ben Linas Gesuch löscht, und wo diese Prüfung hingehört. (2 Punkte)

Aufgabe 2.2: Tests mit oidcLogin und ein anderer Keycloak (Kernkompetenz)

(ca. 11 min Bearbeitungszeit)

Für das Zurückziehen in der Verwaltung hat das Team einen ersten Controller geschrieben:

package de.dbh.mitfahrlabor.web.verwaltung;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestParam;

import de.dbh.mitfahrlabor.service.GesuchService;

/** MON-13g (Entwurf): Die Schulverwaltung zieht ein unpassendes Gesuch zurück (Formular mit Grund). */
@Controller
public class GesuchVerwaltungController {

    private final GesuchService gesuchService;

    public GesuchVerwaltungController(GesuchService gesuchService) {
        this.gesuchService = gesuchService;
    }

    @PostMapping("/verwaltung/gesuche/{nummer}/zurueckziehen")
    public String zurueckziehen(@PathVariable int nummer, @RequestParam String grund) {
        gesuchService.zurueckziehen(nummer, grund);
        return "redirect:/verwaltung/gesuche";
    }
}

1. Schreibe die Testklasse GesuchVerwaltungSicherheitTest als @WebMvcTest mit der SicherheitsKonfiguration und vier Tests für POST /verwaltung/gesuche/1/zurueckziehen mit dem Grund „doppelt“: ohne Anmeldung (Weiterleitung zu Keycloak), angemeldet mit Rolle NUTZER (403), angemeldet mit Rolle ORGA, aber ohne CSRF-Token (403), angemeldet mit Rolle ORGA und CSRF-Token (Weiterleitung auf /verwaltung/gesuche, Service aufgerufen). Nutze für die Anmeldung oidcLogin(). (8 Punkte)

package de.dbh.mitfahrlabor.web.verwaltung;

import static org.assertj.core.api.Assertions.assertThat;
import static org.mockito.ArgumentMatchers.anyInt;
import static org.mockito.ArgumentMatchers.anyString;
import static org.mockito.Mockito.never;
import static org.mockito.Mockito.verify;
import static org.springframework.security.test.web.servlet.request.SecurityMockMvcRequestPostProcessors.csrf;
import static org.springframework.security.test.web.servlet.request.SecurityMockMvcRequestPostProcessors.oidcLogin;

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.webmvc.test.autoconfigure.WebMvcTest;
import org.springframework.context.annotation.Import;
import org.springframework.http.HttpStatus;
import org.springframework.security.core.authority.SimpleGrantedAuthority;
import org.springframework.test.context.bean.override.mockito.MockitoBean;
import org.springframework.test.web.servlet.assertj.MockMvcTester;

import de.dbh.mitfahrlabor.service.GesuchService;
import de.dbh.mitfahrlabor.web.SicherheitsKonfiguration;

@WebMvcTest(GesuchVerwaltungController.class)
@Import(SicherheitsKonfiguration.class)
class GesuchVerwaltungSicherheitTest {

    private static final String ADRESSE = "/verwaltung/gesuche/1/zurueckziehen";

    @Autowired
    private MockMvcTester mvc;

    @MockitoBean
    private GesuchService gesuchService;

    @Test
    void ohneAnmeldungGehtEsZuKeycloak() {
        assertThat(mvc.post().uri(ADRESSE).param("grund", "doppelt").with(csrf()))
                .hasStatus(HttpStatus.FOUND)
                .redirectedUrl().endsWith("/oauth2/authorization/keycloak");
        verify(gesuchService, never()).zurueckziehen(anyInt(), anyString());
    }

    @Test
    void nutzerDuerfenNicht() {
        assertThat(mvc.post().uri(ADRESSE).param("grund", "doppelt").with(csrf())
                .with(oidcLogin().authorities(new SimpleGrantedAuthority("ROLE_NUTZER"))))
                .hasStatus(HttpStatus.FORBIDDEN);
        verify(gesuchService, never()).zurueckziehen(anyInt(), anyString());
    }

    @Test
    void ohneCsrfTokenAuchOrgaNicht() {
        assertThat(mvc.post().uri(ADRESSE).param("grund", "doppelt")
                .with(oidcLogin().authorities(new SimpleGrantedAuthority("ROLE_ORGA"))))
                .hasStatus(HttpStatus.FORBIDDEN);
        verify(gesuchService, never()).zurueckziehen(anyInt(), anyString());
    }

    @Test
    void orgaZiehtZurueckUndWirdUmgeleitet() {
        assertThat(mvc.post().uri(ADRESSE).param("grund", "doppelt").with(csrf())
                .with(oidcLogin().idToken(token -> token.claim("pseudonym", "Sekretariat-HB"))
                        .authorities(new SimpleGrantedAuthority("ROLE_ORGA"))))
                .hasStatus(HttpStatus.FOUND)
                .redirectedUrl().isEqualTo("/verwaltung/gesuche");
        verify(gesuchService).zurueckziehen(1, "doppelt");
    }
}

2. Die Schul-IT betreibt Keycloak im Schulnetz unter https://anmeldung.dbh-berufskolleg.example, das Mitfahrlabor läuft unter https://mitfahrlabor.dbh-berufskolleg.example. Gib an, welche Umgebungsvariablen beim Start gesetzt werden müssen, damit der Code-Stand a12 ohne Änderung an Code oder application.properties mit diesem Keycloak arbeitet, und welche Adressen die Schul-IT im Client flurmonitor-verwaltung eintragen muss. (4 Punkte)

Aufgabe 3.1: 401 oder 403? Fehlersuche nach dem Umbau (Profilkompetenz)

(ca. 18 min Bearbeitungszeit)

In der ersten Woche nach dem Umbau gehen beim Team fünf Meldungen ein:

1. Lina hat sich in einem Skript ein Token mit http://127.0.0.1:8180/realms/mitfahrlabor/protocol/openid-connect/token geholt. Ihre Anfrage GET /v1/angebote mit diesem Token ergibt 401 mit WWW-Authenticate: Bearer error="invalid_token", error_description="An error occurred while attempting to decode the Jwt: The iss claim is not valid".
2. Ein Teammitglied hat im Realm beim Mapper realm-rollen-im-id-token den Schalter „Add to ID token“ ausgeschaltet, weil das ID Token „zu groß“ war. Seitdem meldet sich Heike Brinkmann bei Keycloak erfolgreich an, landet danach aber auf einer Fehlerseite mit Status 403. Anfragen an die REST-API mit ihrem Access Token funktionieren.
3. Für die Verwaltung der Gesuche gibt es eine neue Seite. Das Formular steht dort als <form action="/verwaltung/gesuche/2/zurueckziehen" method="post">. Die Seite lädt, nach dem Absenden kommt 403.
4. Für die neuen Gesuche-Endpunkte hat jemand .requestMatchers(HttpMethod.POST, "/v1/gesuche").hasAuthority("NUTZER") geschrieben. Ben bekommt mit gültigem Token 403.
5. Andrea Wolf (Admin-AW, Rolle ORGA) meldet: POST /v1/angebote/4/buchungen mit ihrem Token ergibt 403 mit dem Titel „Keine Berechtigung“.

1. Bestimme für jede Meldung, ob die Anmeldung oder die Berechtigung scheitert, und nenne die Ursache. (10 Punkte)

2. Gib für jede Meldung die Abhilfe an. (5 Punkte)

3. Nenne für die Meldungen 2, 3 und 4 die niedrigste Testebene, auf der ein automatischer Test den Fehler hätte finden können, und begründe für Meldung 2, warum dort ein @WebMvcTest mit oidcLogin() nicht ausreicht. (4 Punkte)

Aufgabe 3.2: Auswirkungsanalyse für einen weiteren Change Request (Profilkompetenz)

(ca. 13 min Bearbeitungszeit)

Kurz nach Projektende geht CR-03 ein: Die neue Web-App mit Vue soll Auszubildenden erlauben, Gesuche aufzugeben und zurückzuziehen. Sie läuft vollständig im Browser (in der Entwicklung unter http://localhost:5173), meldet sich über den Realm mitfahrlabor an und ruft die REST-API des Mitfahrlabors direkt mit dem Access Token auf. Die Endpunkte /v1/gesuche aus Aufgabe 2.1 sollen dafür gebaut werden.

1. Stelle eine Auswirkungsanalyse für CR-03 als Tabelle mit den Spalten Bereich, Auswirkung und Aufwand (keiner, gering, mittel, hoch) auf. Berücksichtige mindestens Keycloak, Sicherheitskonfiguration, Fachlogik und Datenbank, Vertrag openapi.yaml, Tests und Datenschutz. (8 Punkte)

2. Erkläre, warum der neue Client im Gegensatz zu flurmonitor-verwaltung kein Client-Geheimnis bekommt und was ihn trotzdem schützt. (3 Punkte)

3. Das Folgeteam schätzt CR-03 auf 13 Story Points, MON-16 hatte 8. Nimm Stellung, ob CR-03 als ein Eintrag in den nächsten Sprint gehört oder geschnitten werden sollte, und schlage gegebenenfalls einen Schnitt vor. (3 Punkte)

Links und weitere Informationen

• zum Lehrartikel: Change Request Keycloak: Flurmonitor und REST-API mit OAuth 2.0 und OpenID Connect absichern

• zum Szenario: Szenario Mitfahrlabor mit Personas und Flurmonitoren

• als Nachschlagewerk: Spring Security: Testing OAuth 2.0 und Keycloak Server Administration Guide

• zum Weiterlesen: RFC 7636 PKCE und OAuth 2.0 for Browser-Based Applications

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Übungsaufgaben zu Change Request und Keycloak: Zugriffsregeln, Tests mit Tokens und Fehlersuche für die Mitfahrgesuche” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/flurmonitor-change-request-keycloak-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/java-springboot/Backend. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 11.11.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]