Kapitel 118

Lab 07: Security mit OAuth2/OIDC und Rollenmodell

JWT Claims, Rollen, Scopes, Token Relay und fachliche Berechtigungen im Enterprise-Kontext.

SecurityOIDCJWTRoles

Fachliches Ziel

Dieses V6-Kapitel ist bewusst als Umsetzungs- und Prüfkapitel gebaut. Du sollst nicht nur lesen, sondern eine Entscheidung, ein Codeartefakt, einen Testnachweis und eine kurze Betriebsdokumentation erzeugen.

Lab 07: Security mit OAuth2/OIDC und Rollenmodell - kompakte SVG-Lern-/Umsetzungsskizze
Lab 07: Security mit OAuth2/OIDC und Rollenmodell - kompakte SVG-Lern-/Umsetzungsskizze

Arbeitsauftrag

SchrittTeilErwartetes Ergebnis
1Ausgangslage lesenAltsystem, Stakeholder, Daten und Betriebsgrenzen sichtbar machen.
2Schnitt festlegenDomain, Application, Adapter und Deployment nicht vermischen.
3Code umsetzenKleine Java-Klassen, klare Ports, keine Framework-Abhängigkeit im Kern.
4Pattern markierenIm Code kommentieren und in docs/design-patterns.md begründen.
5Nachweis erstellenTest, ADR, Runbook, Diagramm oder Checkliste hinzufügen.
6Review durchführenRisiken, Alternativen und nächste Verbesserung schriftlich festhalten.
Definition of Done: Ein V6-Ergebnis ist erst vollständig, wenn Code, Dokumentation, Testnachweis, Entwurfsmuster-Kommentar und Prüfcheckliste zusammen vorhanden sind.

Vorher/Nachher-Denken

Viele Enterprise-Probleme entstehen nicht durch eine falsche Bibliothek, sondern durch vermischte Verantwortlichkeiten. Deshalb zeigt V6 häufiger eine schlechte Ausgangslage und eine klare Zielstruktur.

Ausgangspunkt - Legacy-Geruch
// Vorher: technische Logik, Fachlogik und Betriebsdetails sind vermischt.
public void process(OrderDto dto) {
    // SQL, SOAP, Mapping, Transaktion, Event und Logging stehen in einer Methode.
    // Fehlerfolge: schwer testbar, schwer migrierbar, schwer betreibbar.
}
Zielbild - Use Case mit Ports
// Nachher: klarer Use Case mit Ports und dokumentiertem Pattern.
// Pattern: Hexagonal Architecture - Use Case kennt nur Ports, nicht Infrastruktur.
public final class PlaceOrderUseCase {
    private final OrderRepository repository;
    private final PaymentPort paymentPort;
    private final DomainEventPort eventPort;

    public Receipt place(PlaceOrderCommand command) {
        Order order = Order.create(command.customerId(), command.lines());
        paymentPort.authorize(order.total());
        repository.save(order);
        eventPort.publish(order.orderPlaced());
        return Receipt.from(order);
    }
}

Java-Skizze für das Lab

Die folgende Klasse ist bewusst frameworkfrei. Sie kann lokal mit javac --release 21 kompiliert werden und zeigt die im Code markierten Entwurfsmuster.

Lab 07: Security mit OAuth2/OIDC und Rollenmodell - prüfbare V6-Skizze
package at.aydinsude.enterprise.v6.training;

import java.time.Instant;
import java.util.List;
import java.util.UUID;

// Pattern: Command - beschreibt eine auszuführende Lern-/Projektaktion als Objekt.
// Pattern: Template Method - fixe Prüfschritte, aber variabler fachlicher Inhalt je Lab.
// Pattern: Specification - Akzeptanzkriterien werden explizit prüfbar formuliert.
public final class AccessPolicyGuard {
    public TrainingResult execute(TrainingCommand command) {
        List<String> evidence = List.of(
                "code compiles",
                "design pattern documented",
                "architecture decision recorded",
                "test or checklist created",
                "runbook note added");
        boolean accepted = command.description().length() > 20 && command.riskLevel() >= 1;
        return new TrainingResult(UUID.randomUUID(), accepted, evidence, Instant.now());
    }

    public record TrainingCommand(String description, int riskLevel) {}
    public record TrainingResult(UUID id, boolean accepted, List<String> evidence, Instant checkedAt) {}
}

Typische Fehler und Gegenmaßnahmen

Fehler: Es wird nur Code geschrieben, aber keine Architekturentscheidung festgehalten.
Gegenmaßnahme: Eine kurze ADR mit Kontext, Entscheidung, Alternativen und Konsequenzen ergänzen.
Fehler: Patterns werden genannt, aber nicht im Code sichtbar.
Gegenmaßnahme: Pattern-Kommentar direkt an der Klasse oder Methode und zusätzlich in docs/design-patterns.md.
Fehler: Das Lab endet ohne Betriebsnachweis.
Gegenmaßnahme: Runbook, Metrik, Log-Korrelation oder Checkliste als Nachweis anlegen.

Prüffragen

  • Welche fachliche Grenze wird hier geschützt?
  • Welche technische Abhängigkeit wird absichtlich isoliert?
  • Welches Entwurfsmuster ist im Code sichtbar?
  • Welche Tests würden einen Rückfall verhindern?
  • Welche Metrik oder welches Log hilft im Betrieb?
⌂ Cockpit