meldestelle/docs/99_Journal/2026-03-09_Session_Log_Keycloak_Haertung.md

Journal - 2026-03-09

📝 Zusammenfassung

Keycloak-Härtung der Realm-Konfiguration (meldestelle-realm.json). Aufbauend auf dem Infrastruktur-Fix vom 2026-03-06 (korrektes start --optimized, Healthcheck) wurden nun die Client-Konfigurationen und Sicherheitseinstellungen auf einen produktionsreifen Stand gebracht.

🛠️ Änderungen

1. config/docker/keycloak/meldestelle-realm.json

Wildcard aus webOrigins entfernt

• Vorher: api-gateway und web-app hatten "*" in webOrigins (CORS-Sicherheitslücke).
• Nachher: Nur explizit erlaubte Origins (localhost:*, app.meldestelle.at).

Neuer Client: frontend-client (KMP Desktop & Mobile)

• Public Client mit PKCE S256 (kein Client-Secret nötig, sicher für native Apps).
• Redirect URIs: meldestelle://callback (Custom URI Scheme für Desktop), http://localhost:* (Dev), https://app.meldestelle.at/* (Prod).
• Kein directAccessGrantsEnabled — verhindert Password-Grant-Flow (unsicher für native Apps).

Password-Policy gestärkt

• Vorher: length(8) — zu schwach.
• Nachher: length(10) and digits(1) and upperCase(1) and specialChars(1) and notUsername(undefined).

post.logout.redirect.uris konfiguriert

• Alle relevanten Clients (api-gateway, web-app, frontend-client) haben nun korrekte Logout-Redirect-URIs gemäß OIDC Back-Channel Logout Standard.

📚 Gelerntes / Entscheidungen

• meldestelle://callback als Custom URI Scheme: Für KMP Compose Desktop ist ein eigenes URI-Schema der sichere Standard (kein offener HTTP-Port nötig). Muss im OS registriert werden.
• PKCE S256 ist Pflicht für Public Clients: Verhindert Authorization Code Interception Attacks. Keycloak 26.x unterstützt dies nativ.
• frontend-client vs. web-app: Klare Trennung: web-app für Browser-basierte Web-App, frontend-client für native KMP Desktop/Mobile-App.

✅ Micrometer Upgrade (2026-03-09, gleiche Session)

Verifiziert: micrometer = "1.16.1" und micrometerTracing = "1.6.1" waren bereits korrekt in gradle/libs.versions.toml gesetzt — kein Code-Change erforderlich. Archiv-Roadmaps entsprechend abgehakt.

✅ Zipkin Integration (2026-03-09, gleiche Session)

Analyse ergab: Infrastruktur war bereits zu ~90% korrekt aufgebaut. Einzige Lücke war eine falsche Propagation-Konfiguration im Gateway.

Befund

• dc-infra.yaml: Zipkin-Container (openzipkin/zipkin:3, Port 9411) bereits vorhanden.
• monitoring-client-Bundle: enthält micrometer-tracing-bridge-brave, zipkin-reporter-brave, zipkin-sender-okhttp3 — von allen Services eingebunden.
• monitoring-defaults.properties: setzt management.zipkin.tracing.endpoint=http://localhost:9411/api/v2/spans als Default, überschreibbar via MANAGEMENT_ZIPKIN_TRACING_ENDPOINT.
• dc-backend.yaml: setzt MANAGEMENT_ZIPKIN_TRACING_ENDPOINT=http://zipkin:9411/api/v2/spans für alle Services inkl. Gateway.

Fix: Gateway application.yaml

• management.tracing.propagation.type: w3c → b3 (B3 ist das native Format von Brave/Zipkin; W3C wäre für OpenTelemetry — Mismatch hätte Trace-Korrelation zwischen Gateway und Services gebrochen).
• management.zipkin.tracing.endpoint: Explizit mit lokalem Default + ENV-Override ergänzt.
• TRACING_SAMPLING_PROBABILITY: Konsistent mit Services via ENV-Variable.

Fix: Gateway build.gradle.kts

• Redundante direkte micrometer-tracing-bridge-brave-Dependency entfernt (bereits transitiv via monitoring-client vorhanden).

🔜 Nächste Schritte

• OIDC Client im Frontend — Login-Flow mit ktor-client-auth und frontend-client implementieren.
• TLS/HTTPS — Langfristig: KC_HOSTNAME_STRICT_HTTPS=true setzen, sobald TLS eingerichtet ist.