Authentifizierung und Autorisierung

Authentifizierung und Autorisierung

0:00 Der letzte Baustein des Piloten ist die Sicherheit — und hier ändert sich etwas Grundsätzliches. Der Application Server hat die Identität bisher mitgeliefert: Er hat angemeldet, Rollen zugeordnet und Zugriffsregeln durchgesetzt, ohne dass der Anwendungscode viel davon mitbekam. Ab jetzt bringt der Aufrufer seine Identität selbst mit, in Form eines Tokens, und will überprüft werden.

0:21 Wir sehen uns an, wo Sicherheit heute in einer Bestandsanwendung überhaupt steckt, wie die Umstellung auf OpenID Connect aussieht, und was in der Übergangszeit zu beachten ist, wenn zwei Sicherheitsmodelle nebeneinander laufen.

Authentifizierung und Autorisierung

0:34 Damit schließen wir den zweiten Tag ab. Der Pilot hat jetzt alles beisammen: Schnittstelle, Beans, Daten, Nachrichten und Sicherheit. Was noch fehlt, ist der Nachweis, dass er sich verhält wie der Bestand — und der Weg in den Betrieb. Beides ist Thema des dritten Tages.

Bestehende Sicherheit analysieren

0:51 Beginnen wir mit einer Suche. Denn die Sicherheit einer Bestandsanwendung steckt an drei sehr unterschiedlichen Orten, und nur einer davon ist der Code. Nur einer davon ist der Code — und ausgerechnet der bleibt bei dieser Migration weitgehend unverändert. Container-Security bedeutet: Der Application Server prüft die Anmeldung gegen einen Realm, ordnet dem Aufrufer Rollen zu und setzt die Zugriffsregeln aus den Deskriptoren durch.

1:17 Der Anwendungscode sieht davon meist nur die Rollenprüfung — eine Annotation, die sagt: Diese Methode darf nur die Sachbearbeitung aufrufen. Bei einer Migration verschwindet der Realm; die Rollen bleiben. Das ist die gute Nachricht dieses Moduls, denn es bedeutet: Der Teil, der im Code steht, kann fast unverändert bleiben. Umgebaut wird alles darum herum.

1:38 Achten Sie auf die dritte Zeile — und auf die Fußzeile. Die Annotationen mit RolesAllowed bleiben unverändert, und genau deshalb kostet diese Migration weniger Code als befürchtet. Was sich ändert, sind die drei anderen Zeilen: Der Realm wird zum Identity Provider, die Security Constraints aus der web.xml wandern als Annotationen an die Methoden, und die Rollenzuordnung, die bisher jemand in der Serverkonsole gepflegt hat, steckt künftig als Anspruch im Token.

2:04 Der letzte Punkt ist übrigens auch ein organisatorischer: Ein anderes Team pflegt künftig die Rollen. Vier Fragen, und die dritte ist die, die gern übersehen wird: Sind Zugriffe zusätzlich an Daten gebunden, nicht nur an Rollen? Ein Ableser darf nicht alle Ableseaufträge sehen, sondern nur die seines Bezirks. Das ist keine Rollenprüfung mehr, sondern eine fachliche Regel — und sie steckt oft mitten in der Fachlogik, nicht in einer Annotation.

2:31 Punkt vier ist der für die Übergangszeit entscheidende: Woher bezogen Dienst-zu-Dienst-Aufrufe bisher ihre Berechtigung? Häufig lautet die ehrliche Antwort: gar nicht, sie kamen ja aus demselben Netz. Punkt eins ist ein Detail mit großer Wirkung: Die Rollen der Anwendung heißen anders als die Gruppen im Verzeichnisdienst.

2:50 Im Server gab es dafür eine Abbildung, oft in einer Konfigurationsdatei, die niemand mehr kennt. Genau diese Abbildung müssen Sie finden und neu bauen. Punkt drei ist der, den Sicherheitsprüfungen gern aufdecken: Ein technischer Benutzer trägt alle Rollen und fällt niemandem auf, weil er ja nur intern genutzt wird. Und Punkt vier ist konzeptionell wichtig: Datenbezogene Prüfungen sind keine Rollenprüfungen — sie brauchen einen eigenen Platz im Entwurf.

Token-basierte Verfahren

3:16 Jetzt zur neuen Welt. Statt einer Anmeldung, die der Server verwaltet, bringt jeder Aufruf seinen Ausweis mit. Statt einer Anmeldung, die der Server verwaltet, bringt jeder Aufruf seinen Ausweis mit. Der Dienst prüft nur noch dessen Echtheit. Stellen Sie sich den Unterschied zwischen einer Mitgliederliste am Eingang und einem Ausweis vor. Bisher hat der Server nachgeschlagen, wer Sie sind.

3:40 Jetzt zeigen Sie einen Ausweis vor, den eine vertrauenswürdige Stelle ausgestellt hat — und der Dienst prüft nur noch die Echtheit. Technisch: Die OIDC-Erweiterung prüft die Signatur des Bearer Tokens gegen die Schlüssel des Anbieters und stellt die Ansprüche des Tokens bereit. Rollen werden aus einem Anspruch gelesen und mit derselben Annotation durchgesetzt wie zuvor. Der Vorteil: Der Dienst muss keine Benutzer mehr kennen.

4:05 Vier Zeilen Konfiguration, und drei davon lohnen einen Blick. Die Anbieteradresse sagt, wem der Dienst vertraut. Der application-type auf service sagt: Dieser Dienst nimmt Token entgegen, er meldet niemanden an — für eine Schnittstelle ohne Oberfläche ist das die richtige Einstellung. Und die letzte Zeile ist die, an der die meisten Umstellungen zuerst scheitern: der Pfad zum Rollenanspruch. Wie die Fußzeile sagt, ist er anbieterabhängig.

4:31 Sehen Sie in ein echtes Token hinein und lesen Sie ab, wo die Rollen stehen — raten Sie nicht. Und hier die erfreuliche Seite der Migration: Die Rollenprüfung sieht genauso aus wie vorher. Dieselbe Annotation, derselbe Rollenname. Was sich geändert hat, liegt vollständig außerhalb dieser Methode — woher die Rolle kommt und wer sie beglaubigt.

4:52 Für den Bestandscode heißt das: Sie können die Regeln aus der web.xml eins zu eins an die Methoden schreiben und behalten die vertraute Semantik. Der Aufwand liegt nicht im Umschreiben, sondern im Finden: Jede Regel aus jedem Deskriptor muss gefunden und übertragen werden, sonst steht ein Pfad offen. Vier Unterschiede, und der erste ist der konzeptionelle: Die Identität wird nicht mehr gehalten, sondern je Aufruf mitgeliefert.

5:17 Damit entfällt die Sitzung — und damit auch eines der Zustandsprobleme aus Modul fünf. Punkt zwei verschiebt eine Zuständigkeit: Rollen stammen aus dem Identity Provider, also aus einem anderen System und oft aus einem anderen Team. Und Punkt vier hat praktische Folgen für die Oberfläche: Abgelaufene Token führen zu einem 401 statt zu einer neuen Anmeldemaske.

5:39 Wer das nicht behandelt, präsentiert dem Nutzer eine technische Fehlermeldung statt einer erneuten Anmeldung. Diese Tabelle ist eine Fehlersuchhilfe — sie ordnet Symptomen ihre Ursache zu. Und die mittlere Zeile ist, wie die Fußzeile sagt, der häufigste Fehler beim Umstieg: Der Pfad zum Rollenanspruch zeigt ins Leere, also findet der Dienst keine Rollen, also lehnt er mit 403 ab — obwohl das Token gültig ist und die Rolle enthält.

6:04 Das ist besonders verwirrend, weil alles andere funktioniert. Die dritte Zeile ist die sicherheitskritische: Wird die Zielgruppe des Tokens nicht geprüft, akzeptiert Ihr Dienst Token, die für eine ganz andere Anwendung ausgestellt wurden. Punkt drei ist einer, der in verteilten Umgebungen für schwer erklärbare Fehler sorgt: Zeitabweichungen zwischen Diensten lassen gültige Token als abgelaufen erscheinen.

6:28 Wenn zwei Rechner eine Minute auseinanderliegen, scheitern kurzlebige Token sporadisch. Prüfen Sie die Zeitsynchronisation, bevor Sie tagelang im Code suchen. Punkt vier ist eine Kleinigkeit mit großer Wirkung auf die Fehlersuche: Ohne Token muss 401 kommen, nicht 403. Das eine heißt „ich weiß nicht, wer du bist", das andere „ich weiß es, aber du darfst nicht". Wer das vertauscht, schickt jeden Fehlersuchenden in die falsche Richtung.

Dienste und Geheimnisse

6:55 Bleibt eine Frage, die in Migrationen oft zu spät gestellt wird: Wie weist sich eigentlich der Bestand aus, wenn er den neuen Dienst aufruft? Denn bisher rief die Altanwendung eine Methode im selben Prozess auf. Ab jetzt ruft sie über das Netz — und muss sich dabei ausweisen. Ruft die Altanwendung den neuen Dienst auf, braucht sie eine eigene Identität — üblicherweise ein Token, das sie sich mit ihren Zugangsdaten holt.

7:20 Das ist neu, denn bisher rief sie eine Methode im selben Prozess auf; da stellte sich die Frage nicht. Und alles, was dafür nötig ist — Zertifikate, Schlüssel, Geheimnisse —, gehört nicht ins Image, sondern in die Secret-Verwaltung der Plattform. Das ist dieselbe Regel wie in Modul fünf, nur mit höherem Einsatz: Ein durchgesickertes Datenbankpasswort ist schlimm, ein durchgesickerter technischer Zugang ist schlimmer.

7:44 Vier Punkte, und der zweite ist der, den ich besonders betonen möchte: Ein offener Zwischenweg für die Migration bleibt oft länger offen als geplant. Er entsteht mit den besten Absichten — nur für den Übergang, nur intern, nur bis der Bestand umgestellt ist. Und dann wird der Bestand nicht umgestellt, weil anderes wichtiger wird. Befristen Sie solche Wege ausdrücklich, mit Datum.

8:06 Punkt vier ist die verbreitetste Fehlannahme überhaupt: Der neue Dienst vertraut dem Bestand, weil er im selben Netz steht. Netzgrenzen sind keine Berechtigungsprüfung. Der rote Faden: Identität schaffen, Rollen abbilden, Vertrauen begrenzen, Geheimnisse ordnen, prüfen. Schritt zwei ist die Fleißarbeit, die niemand mag — die Abbildung zwischen den Rollen des alten Realms und denen des Identity Providers.

8:31 Sie muss dokumentiert werden, sonst laufen beide Seiten mit der Zeit auseinander. Und Schritt fünf ist wieder das Prinzip dieses Seminars: prüfen statt annehmen. Wie die Fußzeile sagt, gehört das als Test in die Sammlung und nicht in ein einmaliges Protokoll — denn eine Sicherheitseinstellung kann bei jeder späteren Änderung versehentlich wegfallen.

8:51 Punkt eins ist der Übergangsweg, der bleibt — der häufigste echte Sicherheitsschaden aus Migrationsprojekten. Punkt zwei ist der, den Codeprüfungen finden sollten: Zugangsdaten des technischen Benutzers in der Anwendungskonfiguration. Punkt drei ist der organisatorische mit Ankündigung: Zertifikate laufen ab, und niemand ist für die Erneuerung zuständig — das passiert typischerweise ein Jahr nach Projektende, an einem Sonntag.

9:16 Und Punkt vier fasst das Kapitel zusammen: Vertrauen wird über Netzgrenzen begründet statt über Token. Solange beide Systeme im selben Netz liefen, war das nachvollziehbar. Jetzt ist es eine Lücke.

Übung

9:29 In der Übung stellen Sie Zählwerk auf Token um — und Sie prüfen ausdrücklich auch die Fälle, die abgelehnt werden sollen. Und Sie prüfen ausdrücklich auch die Fälle, die abgelehnt werden sollen. Die Ablehnung ist die eigentliche Funktion einer Zugriffskontrolle. Sie lösen die Container-Security von Zählwerk durch OpenID Connect mit JWT ab und bilden die Rollen Ableser, Sachbearbeitung und Netzbetrieb ab.

9:52 Das Lernziel ist, eine bestehende rollenbasierte Zugriffskontrolle umzustellen, ohne die fachlichen Rollen zu verändern — die Technik wechselt, die Fachlichkeit bleibt. Erfolgreich sind Sie, wenn die Rollen wirken wie zuvor, ein Token ohne passende Rolle mit 403 abgelehnt wird und ein fehlendes Token mit 401. Für die Übung genügt der automatisch bereitgestellte Identity Provider im Entwicklungsmodus — Sie müssen also nichts installieren.

10:18 Fünf Schritte, und Schritt eins ist der, der über den Erfolg entscheidet: Rollen und Regeln aus Realm und Deskriptoren auflisten. Diese Liste ist Ihre Vollständigkeitsprüfung — ohne sie merken Sie nicht, wenn eine Regel fehlt, denn fehlende Regeln erzeugen keinen Fehler, sondern nur offenen Zugriff. Schritt vier bringt den Bestand ins Spiel, und Schritt fünf ist die Prüfung.

10:39 Wie die Fußzeile sagt: Aufrufe ohne Token, mit falscher und mit richtiger Rolle — das sind drei Tests, und sie sind der kürzeste sinnvolle Sicherheitstest, den es gibt. Punkt eins ist der gefährlichste, weil er lautlos ist: Regeln aus dem Deskriptor werden vergessen, und ein Pfad steht offen. Nichts schlägt fehl, nichts wird protokolliert — der Zugriff funktioniert einfach für jeden. Nur die Liste aus Schritt eins schützt davor.

11:04 Punkt zwei ist der praktische Rat, den ich wiederhole: Sehen Sie in ein echtes Token hinein, statt den Rollenanspruch zu raten. Punkt drei ist die Lücke in der Übergangszeit. Und Punkt vier ist der Testfehler, der in Sicherheitsfragen besonders teuer ist: Geprüft wird nur der erlaubte Fall — dabei ist die Ablehnung die eigentliche Funktion.