Zusammenfassung

  • LACNICs öffentlicher PAI-Client speichert Berechtigungsdaten für zwei Minuten. Eine vom vorgesehenen Fehlerpfad erfasste Aktualisierungsstörung kann diese Frist mit unveränderten Daten neu beginnen lassen.
  • Der mitgelieferte Test erwartet den Fortbestand des alten authentifizierten Objekts bei ungültigem JSON. Eine neue, erfolgreich gelesene Ablehnung ersetzt dagegen den alten Eintrag.
  • Die Quellcodeprüfung belegt weder produktive Nutzung noch fortbestehenden widerrufenen Zugriff. Sie zeigt, weshalb ein junger Cachezeitstempel nicht notwendig eine junge Berechtigungsentscheidung bedeutet.

Die Warnung erzählt nur einen Teil

Der Client warnt, wenn er vorübergehend einen verlängerten Cache verwendet. Dieses Detail sollte in jeder Bewertung stehen. Der Rückgriff ist im veröffentlichten Code nicht völlig lautlos, und Betreiber könnten die Meldung beobachten. Daraus folgt allerdings noch nicht, dass die Anwendung, die das Berechtigungsobjekt erhält, dessen ursprüngliches Alter kennt.

Eine Warnung sagt, dass ein bestimmter Ersatzweg genommen wurde. Ein neu gesetzter Zeitstempel sagt, wann ein gespeicherter Eintrag verlängert wurde. Keine dieser Angaben ist ohne Weiteres das Datum, an dem die zuständige Stelle die enthaltenen Rechte zuletzt bestätigt hat. Gerade bei einer Störung können diese drei Beobachtungen auseinanderfallen.

LACNICs öffentliches Repository pai-auth-ws-client macht diesen Unterschied überprüfbar. Grundlage ist der Commit b85523718bfdbd834c85add8e06c3b4a1b813e59, der am 14. September 2026 auf dem beobachteten Hauptzweig lag. Der README beschreibt einen Java-Client für Authentifizierung, Autorisierung und Sitzungsfunktionen von PAI. Er liefert keine Bestandsaufnahme produktiv installierter Clients.

Die feste Revision erlaubt es Lesern, denselben Quelltext nachzuvollziehen. Sie erlaubt nicht die Behauptung, sämtliche LACNIC-Anwendungen führten ihn aus. Veröffentlichungsstand, tatsächlich eingesetzte Version und Zeitpunkt einer Rechteänderung sind unterschiedliche Tatsachen. Ein Urteil über reale Folgen müsste diese Tatsachen erst miteinander verbinden.

Was die zwei Minuten begrenzen

In PortalWSClient liegt der Cache in einer statischen, prozesslokalen ConcurrentHashMap. Als Schlüssel dient das an die Methode übergebene Token. Jeder Eintrag enthält TokenData und einen veränderbaren Zeitstempel. CACHE_DURATION_MS legt zwei Minuten fest; die Ablaufprüfung vergleicht die aktuelle Uhrzeit mit dem gespeicherten Zeitpunkt.

Solange der Eintrag nicht abgelaufen ist, gibt die Methode dessen Daten unmittelbar zurück. Auf diesem Weg ruft sie keine neue Antwort von /authorization ab. Das ist der normale Nutzen eines Caches: weniger entfernte Aufrufe und weniger Abhängigkeit jedes Arbeitsvorgangs von einer kurzen Dienststörung. Allein daraus lässt sich keine mangelhafte Zugriffskontrolle ableiten.

Nach Ablauf entfernt die Methode den Eintrag aus der gemeinsamen Map und versucht, Ersatz abzurufen und zu lesen. In einer lokalen Variablen behält sie jedoch die Referenz auf den alten Eintrag. Aus einer Map entfernt zu sein bedeutet also nicht, dass die laufende Ausführung das alte Objekt nicht mehr zur Verfügung hat. Diese Referenz ermöglicht den späteren Rückgriff.

Wird die neue Antwort erfolgreich decodiert, entsteht ein neuer Cacheeintrag mit den neuen Daten. Auch negative Berechtigungsdaten können diesen Weg nehmen. Eine aktuelle, lesbare Ablehnung wird somit nicht grundsätzlich zugunsten einer alten Zustimmung ignoriert. Diese Gegenprobe ist wichtig: Der untersuchte Ersatzweg betrifft einen Lesefehler, nicht jeden unerwünschten Inhalt einer Antwort.

Der äußere Fehlerblock behandelt IOException. Ist der frühere Eintrag noch referenziert, ruft er cached.extend() auf, setzt dessen Zeitstempel auf die Gegenwart und legt denselben Eintrag erneut in die Map. Zurückgegeben werden die gespeicherten Daten. Eine neue, erfolgreich gelesene Berechtigungsentscheidung ist durch diese Verlängerung nicht entstanden.

Die Cachehülle hat erneut zwei Minuten erhalten. Ihr Inhalt stammt weiterhin aus dem früheren erfolgreichen Abruf. Tritt bei späteren Aktualisierungen wieder ein passender Fehler auf, kann derselbe Weg erneut durchlaufen werden. In dieser Klasse gibt es keinen separat unveränderlich bewahrten Zeitpunkt der ursprünglichen erfolgreichen Antwort, keine von ihm gemessene absolute Altersgrenze und keinen Verlängerungszähler.

Diese Aussage bleibt auf die Klasse beschränkt. Ein aufrufendes Programm kann eigene Grenzen oder zusätzliche Prüfungen besitzen. Der Quelltext beweist nicht, dass sie fehlen. Er beweist aber, dass die veränderbare Cachezeit allein keine Antwort auf die Frage gibt, wie lange die enthaltene Entscheidung bereits ohne erfolgreiches Update genutzt wird.

Ein Test zugunsten der Verfügbarkeit

Der Test testGetTokenDataReturnsCachedDataWhenRefreshFails in PortalWSClientTest beginnt mit einer simulierten positiven HTTP-Antwort. Anschließend verschiebt er den Cachezeitstempel künstlich um fünf Minuten in die Vergangenheit. Der nächste simulierte Abruf liefert fehlerhaftes JSON. Erwartet werden dasselbe authentifizierte Objekt und zwei HTTP-Ausführungen.

Die fünf Minuten wurden im Testzustand gesetzt. Sie sind keine live beobachtete Dauer und kein Beleg für Zugriff nach einem Widerruf. Für diesen Artikel wurde der Test gelesen, nicht ausgeführt. Es wurden weder produktive Autorisierungsendpunkte angesprochen noch echte Tokens verwendet. Die Aussage betrifft die dokumentierte Erwartung des Projekts.

Diese Erwartung macht die Absicht klarer als der Fehlerblock allein. Das frühere Objekt soll in diesem Szenario weiterverwendet werden. Ein vorübergehend nicht lesbarer Dienst sagt schließlich nicht, dass alle bisher legitimen Sitzungen unberechtigt geworden sind. Ein sofortiger Abbruch könnte die Wirkung einer begrenzten Abhängigkeitspanne erheblich vergrößern.

Eine Schonfrist kann deshalb sinnvoll sein. Ihre Bedingungen sollten allerdings sichtbar bleiben: Beginn, absoluter Endpunkt und zulässige Vorgänge. Das Fortsetzen einer Arbeit ist eine Entscheidung der konsumierenden Anwendung. Es sollte nicht als erneute Bestätigung der ausstellenden Berechtigungsstelle erscheinen, wenn diese Bestätigung gerade nicht gelesen werden konnte.

Das Objekt kennt seine Vorgeschichte nicht

TokenData enthält Authentifizierungsstatus, Token, Rollen, Fehler und ipAllowed. Einen Zeitpunkt der letzten erfolgreichen Antwort, eine Aktualitätsklasse oder ein Kennzeichen für den Rückgriff auf alte Daten stellt dieser Datentyp nicht bereit. Seine Felder allein erzählen dem Aufrufer nicht, welcher Weg zur Rückgabe geführt hat.

Zu unterscheiden sind die eigene Gültigkeit des Tokens, die aktuelle Cachefrist und der gegenwärtige Rollenstand beim Aussteller. Es handelt sich um drei verschiedene Behauptungen. Ein Token innerhalb seiner kryptographischen Laufzeit belegt nicht automatisch unveränderte Rollen; eine frische Cachefrist belegt nicht automatisch einen neuen Abruf. Auch der Zeitpunkt einer administrativen Rechteänderung lässt sich aus dem Cachezeitstempel nicht rekonstruieren.

Die umgebende Anwendung könnte Tokenablauf und IP-Beschränkungen prüfen, eigene Antwortzeiten speichern oder vor einer sensiblen Schreiboperation zusätzliche Autorisierung verlangen. Diese Möglichkeiten werden hier weder bestätigt noch ausgeschlossen. Ebenso wenig lässt die Rückgabe eines positiven Testobjekts den Schluss zu, eine konkrete unberechtigte Geschäftshandlung sei tatsächlich akzeptiert worden.

Zwischen Clientrückgabe und endgültiger Anwendungsentscheidung liegt eine eigene Kontrollfläche. Eine belastbare Untersuchung müsste sie prüfen. Fehlende Informationen durch vermeintlich sichere Zusatzprüfungen zu ersetzen wäre ebenso unzulässig wie sie wegzudenken, um aus dem Cacheverhalten einen produktiven Angriff zu machen.

Lesbarkeit ist nicht die ganze Vertrauensfrage

PortalHttpClient baut seinen Client mit TrustAllStrategy und NoopHostnameVerifier. In diesem Helfer sind eine HTTPS-Adresse und decodierbare Daten für sich genommen kein Nachweis kryptographisch geprüfter Ausstelleridentität durch diese Komponente. Das ist eine gesonderte, begrenzte Quellcodebeobachtung.

Sie belegt weder einen abgefangenen Datenstrom noch die TLS-Konfiguration eines tatsächlich betriebenen Dienstes. Für eine Aktualitätspolitik ist sie dennoch relevant: Wer den Zeitpunkt der letzten verlässlichen Antwort festhält, muss bestimmen, welche authentifizierte Herkunft eine Antwort dafür qualifiziert. Ein genaues Datum ersetzt keine klare Vertrauensgrenze zum Antwortgeber.

Auch die Fehlerarten dürfen nicht verallgemeinert werden. readUrlToken fängt breit Ausnahmen ab und kann null zurückgeben; der äußere Rückgriff behandelt IOException. Ungültiges JSON, ein fehlender Antwortkörper und ein Transportfehler sind nicht allein aufgrund der vorhandenen Testdatei nachgewiesenermaßen derselbe Ablauf. Diese unterschiedlichen Pfade wurden hier nicht ausgeführt.

Die Behauptung, der Client funktioniere bei jedem Ausfall weiter, würde seine belegte Widerstandsfähigkeit überzeichnen. Die Behauptung, jeder Ausfall konserviere widerrufenen Zugriff, würde das Risiko überzeichnen. Belegt ist der vorgesehene Rückgriff im beschriebenen JSON-Szenario und die Trennung von erneuerter Cachezeit und unverändertem Antwortinhalt.

Zwei Zeitangaben statt einer stillen Annahme

Ein klarerer Vertrag könnte die letzte authentifizierte, erfolgreich decodierte Berechtigungsantwort getrennt von der letzten Berührung des Cacheeintrags datieren. Eine Verlängerung änderte nur die zweite Zeit. Der Aufrufer könnte aktuelle Daten, Daten innerhalb einer Schonfrist und Nichtverfügbarkeit unterscheiden, statt jede erfolgreiche Objektrückgabe gleich zu interpretieren.

Die Schonfrist könnte absolut seit der verlässlichen Antwort laufen. Weitere Fehlschläge würden ihre Herkunft nicht nach vorn verlegen. Vorgänge könnten unterschiedliche Grenzen haben: Eine reversible Abfrage muss nicht so behandelt werden wie eine irreversible administrative Änderung. Das sind analytische Handlungsklassen, keine identifizierten LACNIC-Funktionen, deren Nutzung dieses Clients bewiesen wäre.

Ein Wiederholungstest sollte dann prüfen, ob der ursprüngliche Zeitpunkt unverändert bleibt und der absolute Endpunkt trotz mehrerer Fehlschläge greift. Eine neue lesbare Ablehnung gehört als Gegenfall dazu. Diese Verifikationsfragen wurden hier nicht praktisch getestet; sie sind redaktionelle Vorschläge und keine von LACNIC angekündigte Zusage.

Für eine Betriebsübergabe wäre die Aussage „der Cache funktioniert“ deshalb unzureichend. Das nächste Team müsste wissen, wie lange die letzte verlässliche Antwort zurückliegt, welche Vorgänge weiterlaufen dürfen und an welchem Punkt die Ausnahmeregel endet. Erst dann lässt sich eine tatsächlich wieder verfügbare Berechtigungsquelle von einer Anwendung unterscheiden, die lediglich mit früheren Daten weiterarbeitet. Der junge Cachezeitstempel allein liefert diese Unterscheidung nicht.

Nichtverfügbarkeit ist dabei keine andere Bezeichnung für entzogene Rechte. Sie beschreibt die gegenwärtige Möglichkeit zur Prüfung, während eine Ablehnung eine Entscheidung des Ausstellers beschreibt. Eine Schonfrist wiederum ist eine lokale Entscheidung über die Annahme älterer Daten. Werden diese Zustände getrennt zurückgegeben, können Verantwortliche ihre Verfügbarkeitsvorteile und ihre Grenzen bewerten, ohne eine Bestätigung zu behaupten, die gerade nicht vorliegt.

Ein solcher Vertrag muss nicht jeden kurzen Fehler an den Nutzer weiterreichen. Er kann Unterbrechungen innerhalb erklärter Grenzen vermeiden. Sein Vorteil liegt in der Verantwortlichkeit: Der folgende Entscheider weiß, ob er sich auf einen aktuellen Ausstellerbefund oder auf eine begrenzte Fortsetzungsregel stützt. Diese Transparenz ist eine vorgeschlagene Gestaltung, keine Behauptung über die untersuchten Abläufe eines produktiven LACNIC-Systems.

Warnungen könnten mit Antwortalter und erklärtem Ersatzbetrieb verknüpft werden, ohne Roh-Tokens oder vollständige Sitzungsdaten zu speichern. Eine neue verlässliche Antwort beendet die Schonfrist; eine neue Ablehnung bleibt eine Ablehnung. Der Zweck ist nicht, Caches abzuschaffen, sondern eine frisch datierte Hülle nicht mit neu erteilten Rechten zu verwechseln.

Quellen

Die fünf verlinkten Primärquellen sind README, PortalWSClient, PortalWSClientTest, TokenData und PortalHttpClient derselben Revision. Sie tragen eine Bewertung veröffentlichter Implementierung und eines simulierten Tests. Produktive Nutzung, Testausführung, Widerrufsumgehung, kompromittierte Zugangsdaten und unberechtigte Vorgänge werden damit nicht festgestellt.