Spezifikation / SPISecurity3.1 / 3.0
Jakarta Authentication und Authorization
Authentication und Authorization sind tieferliegende Container-SPIs für Authentifizierungsmechanismen und Autorisierungsentscheidungen.
Einordnung
Spezifikation / SPI
Enterprise-Rolle
Sie sind eher für Runtime-/Container-Integration relevant als für normalen Fachcode.
Fachliches Verständnis
Sie sind eher für Runtime-/Container-Integration relevant als für normalen Fachcode. In der Praxis ist wichtig, die Spezifikation nicht mit der konkreten Runtime zu verwechseln. Der Standard beschreibt die portablen APIs, die Implementierung entscheidet über Konfiguration, Performance, Betrieb und Support.
Kernkonzepte
- ServerAuthModule / Authentication SPI.
- Policy-Konzept und Autorisierungsmodul.
- Integration in Container Security.
Typische Einsatzfälle
- Eigene Auth-Mechanismen für Container.
- Migration alter JAAS/JASPIC-Integrationen.
Technisches Beispiel
java
public class CustomIdentityStore implements IdentityStore {
@Override
public CredentialValidationResult validate(UsernamePasswordCredential credential) {
if ("demo".equals(credential.getCaller())) {
return new CredentialValidationResult("demo", Set.of("USER"));
}
return INVALID_RESULT;
}
}
Architekturregel: Jakarta APIs gehören an Systemgrenzen und Infrastrukturpunkte. Fachentscheidungen bleiben in Application Services und Domain-Modellen testbar und möglichst unabhängig vom Container.
Enterprise-Fallen
- SPI im Anwendungscode statt hoher Security-API verwenden.
- Containerabhängigkeiten ungetestet lassen.
Legacy-Modernisierung
Alte Server-Login-Module werden oft besser durch moderne Identity Provider ersetzt; eigene SPIs nur bei echten Integrationsanforderungen.
Vertiefung: Review-Fragen für Senior-Entwickler
- Welche Spezifikation ist hier wirklich nötig?
- Welche Runtime-Funktion wird genutzt und ist sie portabel?
- Wo liegt die Transaktionsgrenze?
- Sind API-Verträge, DTOs und Domain-Modelle getrennt?
- Ist der Code ohne Application Server testbar?