Files

T

stefan f9927066a2 refactor(infra-auth): Relocate auth models and add JWT tests

This commit resolves the build failures caused by the refactoring of the `core` module and significantly improves the quality of the `auth-client` module.

### Architectural Refinements

- **Relocated Auth Enums:** The `RolleE` and `BerechtigungE` enums have been moved from the `core` module to their correct logical home within `:infrastructure:auth:auth-client`. The `auth-client` is now the single source of truth for authorization models, making it a self-contained and more coherent module.
- **Improved Type Safety:** The `AuthenticationService` interface and its DTOs now use the type-safe `BerechtigungE` enum instead of raw `List<String>`, improving consistency and reducing the risk of runtime errors.
- The `JwtService` now uses `kotlin.time.Duration` for token expiration, aligning it with project-wide best practices.

### Testing Enhancements

- **Added JWT Service Tests:** Introduced a comprehensive `JwtServiceTest` suite.
- The tests cover token generation, validation (including successful, invalid secret, and expired token scenarios), and the correct extraction of claims like user ID and permissions.
- This ensures the reliability and security of our core authentication mechanism.

2025-08-09 19:35:53 +02:00

3.2 KiB

Raw Blame History

Infrastructure/Auth Module

Überblick

Das Auth-Modul ist die zentrale Komponente für die gesamte Authentifizierung und Autorisierung innerhalb der Meldestelle-Systemlandschaft. Es ist verantwortlich für die Absicherung von APIs, die Validierung von Benutzeridentitäten und die Verwaltung von Berechtigungen.

Als Identity Provider wird Keycloak verwendet. Dieses Modul kapselt die gesamte Interaktion mit Keycloak und stellt dem Rest des Systems eine einheitliche und vereinfachte Sicherheitsschicht zur Verfügung.

Architektur

Das Auth-Modul ist in zwei spezialisierte Komponenten aufgeteilt, um eine klare Trennung der Verantwortlichkeiten zu gewährleisten:

infrastructure/auth/ ├── auth-client/ # Wiederverwendbare Bibliothek für die JWT-Validierung └── auth-server/ # Eigenständiger Service für Benutzerverwaltung & Token-Austausch

`auth-client`

Dieses Modul ist eine wiederverwendbare Bibliothek und kein eigenständiger Service. Es enthält die gesamte Logik, die andere Microservices (wie masterdata-service, members-service etc.) benötigen, um ihre Endpunkte abzusichern.

Hauptaufgaben:

JWT-Management: Stellt einen JwtService zur Erstellung und Validierung von JSON Web Tokens bereit.
Modell-Definition: Definiert die Quelle der Wahrheit für sicherheitsrelevante Konzepte wie RolleE und BerechtigungE als typsichere Kotlin-Enums. Dies stellt sicher, dass alle Services dieselbe "Sprache" für Berechtigungen sprechen.
Schnittstellen: Bietet saubere Schnittstellen wie AuthenticationService an, die von der konkreten Implementierung (z.B. Keycloak) abstrahieren.

Jeder Microservice, der geschützte Endpunkte anbietet, bindet dieses Modul als Abhängigkeit ein.

`auth-server`

Dies ist ein eigenständiger Spring Boot Microservice, der als Brücke zwischen dem Meldestelle-System und Keycloak agiert.

Hauptaufgaben:

Benutzer-API: Stellt eine REST-API zur Verfügung, um Benutzer zu verwalten (z.B. Registrierung). Diese API kommuniziert im Hintergrund über den keycloak-admin-client mit Keycloak.
Token-Endpunkte: Ist verantwortlich für das Ausstellen von Tokens nach einer erfolgreichen Authentifizierung.
Implementierung der AuthenticationService-Schnittstelle: Enthält die konkrete Logik, die gegen Keycloak prüft, ob ein Benutzername und ein Passwort korrekt sind.

Zusammenspiel im System

Ein Benutzer meldet sich über eine Client-Anwendung am auth-server an.
Der auth-server validiert die Anmeldedaten gegen Keycloak.
Bei Erfolg erstellt der auth-server mit dem JwtService aus dem auth-client ein JWT, das die Berechtigungen des Benutzers enthält, und sendet es an den Client zurück.
Der Client sendet eine Anfrage an einen anderen Microservice (z.B. members-service) und fügt das JWT als Bearer-Token in den Header ein.
Der members-service, der ebenfalls den auth-client als Abhängigkeit hat, nutzt den JwtService, um das Token zu validieren und die Berechtigungen typsicher auszulesen.

Diese Architektur entkoppelt die Fach-Services von der Komplexität der Identitätsverwaltung und schafft eine robuste, zentrale Sicherheitsinfrastruktur.

Letzte Aktualisierung: 9. August 2025

3.2 KiB Raw Blame History