Von Spring Security zu Quarkus Security

Von Spring Security zu Quarkus Security

0:00 Security ist der Teil der Migration, bei dem ein Fehler am teuersten ist — und zugleich der, bei dem der Fehler am leisesten auftritt. Ein Endpunkt, der versehentlich offen ist, meldet sich nicht. Er funktioniert einfach. Deshalb gehen wir dieses Modul anders an als die vorigen: Wir übersetzen nicht Konfiguration in Konfiguration, sondern arbeiten zuerst heraus, was die bestehende Absicherung eigentlich zusichert.

0:25 Erst dann bauen wir sie neu — und weisen mit Tests nach, dass beides gleich ist.

Von Spring Security zu Quarkus Security

0:30 Wir nähern uns dem Ende des zweiten Tages. Nach Persistenz, Querschnittlichem, Tests und Infrastruktur bleiben die beiden Themen, die über den eigenen Dienst hinausreichen: Security und Messaging. Beide berühren fremde Systeme, beide brauchen deshalb besondere Sorgfalt — und beide profitieren davon, dass die Dev Services aus dem letzten Modul uns einen echten Identity Provider und einen echten Broker liefern.

Bestehende Spring-Security-Konfiguration analysieren

0:54 Beginnen wir mit der Analyse. Und zwar ausdrücklich nicht mit der Frage, wie die alte Konfiguration aufgebaut ist, sondern mit der Frage, was sie zusichert. Eine Filter Chain beschreibt, welcher Pfad welche Authentifizierung verlangt und welche Rolle worauf zugreifen darf. Für eine Migration ist ihr Aufbau uninteressant — entscheidend ist ihr Ergebnis.

1:15 Das Bild: Sie ziehen um und übersetzen nicht die Verkabelung Ihrer Alarmanlage, sondern die Liste, welche Türen abgeschlossen sein müssen. Diese Liste ist übertragbar, die Verkabelung nicht. Und sie hat noch einen Vorteil: Sie lässt sich überprüfen, auch von jemandem, der beide Frameworks nicht im Detail kennt. Fünf Schritte zur Prüfliste.

1:36 Der dritte ist der, der am häufigsten übersprungen wird: Method Security sitzt an Diensten, nicht nur an Endpunkten — wer nur die Controller ansieht, übersieht die Hälfte. Der vierte sammelt die Sonderfälle ein, und die haben es in sich: offene Pfade, Health-Endpunkte, interne Aufrufe. Und der fünfte macht aus der Liste ein Werkzeug: Zu jeder Zusicherung gehört ein Testfall für den erlaubten und einen für den verbotenen Zugriff.

2:00 Die Fußnote sagt, was damit gemeint ist — diese Liste ist Ihre Abnahmebedingung, nicht die alte Konfigurationsklasse. Der erste Punkt ist der Grundfehler dieses Kapitels: Zeile für Zeile übersetzen, statt das Ergebnis zu prüfen. Der zweite ist die eben genannte Lücke bei der Method Security — und sie fällt niemandem auf, weil nichts kaputtgeht; es wird nur nicht mehr geprüft.

2:22 Der dritte betrifft die Reihenfolge in der alten Konfiguration: Was dort ganz unten stand, war vielleicht bewusst offen, vielleicht auch nur vergessen. Und der vierte ist ein Detail mit großer Wirkung: Rollennamen im Token und im Code weichen ab, und niemand vergleicht sie Zeichen für Zeichen.

Quarkus Security und Jakarta-Annotationen

2:39 Sehen wir uns das Zielmodell an. Es ist schlichter als Spring Security — und diese Schlichtheit hat Vor- und Nachteile. Quarkus bringt Mechanismen für die üblichen Verfahren mit: einfache Anmeldung, Formularanmeldung, gegenseitiges TLS, dazu OpenID Connect und WebAuthn. Das zentrale Konzept heißt SecurityIdentity: Ein Identity Provider prüft die Anmeldedaten und bildet sie auf diese eine Struktur ab — Benutzername, Rollen, Attribute.

3:07 Das Bild: ein Besucherausweis, der an der Pforte ausgestellt wird. Im Haus fragt niemand mehr nach dem Ausweisdokument; alle schauen nur noch auf den Ausweis. Das vereinfacht vieles, weil es nur noch eine Quelle für Identität gibt. Die Tabelle zeigt zwei Muster nebeneinander, und die erste Zeile ist die entscheidende. In Spring stehen häufig Ausdrücke in der Annotation — mit Vergleichen, Methodenaufrufen, manchmal Fachlogik. In Quarkus gibt es eine Rollenliste, mehr nicht.

3:36 Für die Migration heißt das: Ausdrücke müssen aufgelöst werden, und dabei stellt sich oft heraus, dass darin eine fachliche Regel steckt, die nie als solche benannt war. Das ist unangenehme Arbeit — und meistens die nützlichste des ganzen Moduls, weil sie eine verdeckte Regel sichtbar macht. Vier Vorteile, die zusammenhängen. Die Zusicherung steht an der Methode und ist beim Lesen sichtbar — keine Ausdruckssprache, die man erst interpretieren muss.

4:03 Damit entfallen auch deren schwer prüfbare Sonderfälle. Es gibt eine Quelle für Identität statt mehrerer. Und pfadbasierte Regeln bleiben für alles möglich, was nicht am Code hängt — für statische Inhalte etwa oder für Endpunkte aus Extensions, an die Sie keine Annotation schreiben können. Die Kunst liegt darin, beides nicht gleichzeitig für dieselbe Sache zu benutzen.

4:25 Der erste Punkt ist die eben besprochene Fachlogik im Ausdruck. Der zweite ist ein echter Sicherheitsfehler: Die Rollenprüfung wandert an den Endpunkt, und der dahinterliegende Dienst bleibt ungeschützt — was so lange gutgeht, bis ihn ein zweiter Aufrufer benutzt. Der dritte ist der Fall, vor dem ich eben gewarnt habe: Pfadregeln und Annotationen widersprechen sich; die restriktivere gewinnt, und niemand versteht warum.

4:49 Und der vierte ist eine schlichte Auslassung: CORS und CSRF standen in Spring an anderer Stelle und werden deshalb vergessen.

OIDC, Tokens und abgesicherte Aufrufe

4:57 Kommen wir zum praktisch wichtigsten Fall: ein Dienst, der Bearer Tokens von einem Identity Provider akzeptiert. Für diesen Fall binden Sie die OIDC-Extension ein und sagen Quarkus, dass es sich um einen Dienst handelt — nicht um eine Web-Anwendung, die selbst anmeldet. Quarkus prüft dann die Signatur lokal gegen die Schlüssel des Providers oder lässt undurchsichtige Tokens beim Provider prüfen. Rollen liest es aus dem Claim, den Sie angeben.

5:23 Der Merksatz für dieses Kapitel: Ihr Dienst prüft Tokens, er stellt keine aus. Alles, was mit Anmeldung, Passwörtern und Sitzungen zu tun hat, bleibt beim Provider. Fünf Zeilen Konfiguration, und zwei davon verdienen besondere Aufmerksamkeit. Die vierte legt fest, für welchen Empfänger ein Token ausgestellt sein muss — ohne diese Prüfung akzeptiert Ihr Dienst jedes Token desselben Providers, auch eines, das für einen ganz anderen Dienst gedacht war.

5:49 Die fünfte sagt, wo im Token die Rollen stehen; der Pfad unterscheidet sich je nach Provider, und wenn er nicht stimmt, hat jeder Benutzer plötzlich gar keine Rolle mehr. Im Code selbst bleibt es dann bei einer Annotation. Vier Wege, und sie ergänzen sich. Der erste setzt Benutzer und Rollen direkt — schnell, bequem, und er umgeht den gesamten Tokenpfad.

6:10 Der zweite ergänzt Claims, wenn das Token selbst geprüft wird. Der dritte ist der ehrlichste: Der Keycloak-Dev-Service liefert echte Tokens, mit denen Sie dieselbe Kette durchlaufen wie in Produktion. Und der vierte stubbt den Provider über WireMock, wenn Sie keine Container-Laufzeit haben. Die Empfehlung: Nutzen Sie die bequeme Variante für die Breite und mindestens einen echten Tokenpfad für die Tiefe.

6:36 Die ersten beiden Punkte sind die Konfigurationsfehler von eben, und beide sind kritisch: fehlende Empfängerprüfung und ein falscher Rollen-Claim. Der dritte ist eine Testlücke mit Ansage — alle Tests setzen die Identität direkt, der echte Tokenpfad bleibt ungeprüft, und der erste Kontakt mit einem echten Token findet in der Testumgebung statt.

6:54 Und der vierte ist ein Entwurfsfehler, den man in verteilten Systemen oft sieht: Das Benutzertoken wird an den nächsten Dienst weitergereicht, obwohl dieser Aufruf eigene Rechte bräuchte.

Übung

7:05 In der Übung sichern Sie die Rücknahmestellen von Pfandkreis ab — und weisen mit Tests nach, dass sich nichts geöffnet hat. Der entscheidende Satz steht im Erfolgskriterium: Für jede Rolle brauchen Sie einen Test für einen erlaubten und einen für einen verbotenen Zugriff. Nur der zweite ist wirklich aussagekräftig — denn ein erlaubter Zugriff funktioniert auch dann, wenn gar keine Absicherung existiert.

7:28 Nutzen Sie den Keycloak-Dev-Service; er nimmt Ihnen die Einrichtung ab und liefert echte Tokens, sodass Sie den vollständigen Pfad prüfen und nicht nur eine gesetzte Identität. Und behandeln Sie die Zusicherungsliste aus dem ersten Kapitel als Abnahmekriterium: Jede Zeile darin braucht am Ende zwei Tests, sonst ist sie eine Absichtserklärung geblieben.

7:48 Der erste Schritt greift auf die Prüfliste aus Kapitel eins zurück — sie ist jetzt Ihre Abnahmeliste. Danach die Konfiguration, wobei Sie besonders auf Rollen-Claim und Empfänger achten. Dann die Annotationen, und zwar an Endpunkten und Diensten. Zum Schluss die Tests und der Vergleich beider Varianten. Die Fußnote formuliert das Bewertungskriterium unmissverständlich: Ein Zugriff, der vorher verboten war und jetzt durchgeht, ist ein Migrationsfehler.

8:16 Kein Fortschritt, keine Vereinfachung — ein Fehler. Der erste Punkt ist die häufigste Selbsttäuschung in Security-Tests: Nur der erlaubte Zugriff wird geprüft. Der zweite ist ein Umgebungsproblem — im Testprovider heißen die Rollen anders als in Produktion, und die Tests beweisen dann etwas über den Testprovider. Der dritte ist die schon bekannte Lücke bei internen Aufrufen.

8:37 Und der vierte ist der unangenehmste, weil er ohne Fehlermeldung auftritt: Ein Endpunkt bleibt ungesichert, weil er in der alten Filter Chain implizit geschützt war — durch eine Regel weiter oben, an die niemand mehr gedacht hat.