Warum ein einzelnes OTP nicht WLAN, VPN und Registry abdeckt

Single Sign-on verspricht eine Identität und weniger Abfragen, und das Versprechen bricht beim dritten Protokoll. Die Falle ist die Annahme, dass eine erfolgreiche Authentifizierung ein Token erzeugt, das jedes andere Protokoll vorlegen kann. WLAN-Zugang, VPN-Einstieg und eine Container-Registry führen jeweils einen anderen Austausch durch, mit unterschiedlichem Publikum und unterschiedlicher Laufzeit. Das Konto zu teilen ist eine Verzeichnisentscheidung; die Anmeldedaten zu teilen ist eine Protokollentscheidung, und die Protokolle sind sich selten einig.

Drei Austausche, drei Eigentümer

Unternehmens-WLAN führt eine EAP-Methode innerhalb von 802.1X aus, meist beendet von einem RADIUS-Dienst mit eigener Sicht auf Benutzer oder Gerät. Ein VPN-Gateway authentifiziert über seinen eigenen unterstützten Ablauf und hält danach eine Sitzung mit eigenem Reauthentifizierungs-Timer. Eine Registry beantwortet eine nicht authentifizierte Anfrage mit einer Challenge, die einen Token-Dienst, ein Publikum und einen Scope nennt, und der Client tauscht seine Anmeldedaten gegen ein kurzlebiges Token.

Das sind nicht drei Ansichten einer Sitzung. Jeder Austausch hat seinen eigenen Prüfer, seine eigene Laufzeit und seinen eigenen Widerrufspfad, weshalb eine Passwortänderung im Verzeichnis den einen weiterlaufen und den anderen brechen kann. Behandle sie als drei Integrationen, die zufällig ein Benutzerverzeichnis teilen.

Was Browser-SSO trägt und was nicht

Eine Browsersitzung bei einem Identitätsanbieter ist wirklich nützlich: Anwendungen, die dorthin weiterleiten, erben die Anmeldung, die der Benutzer bereits abgeschlossen hat. Das funktioniert, weil diese Anwendungen dieselben Weiterleitungs- und Token-Protokolle sprechen und dasselbe Publikum akzeptieren. Ein Supplicant, der EAP spricht, hat keine Weiterleitung zu befolgen, und ein Docker-Client, der eine Registry-Challenge erhält, fragt nicht nach einem OIDC-ID-Token. Der Identitätsanbieter kann nur für Protokolle bürgen, für die er gebaut wurde.

Der Fehler ist in den Logs leicht zu sehen, wenn man weiß, wo man schauen muss. Der Identitätsanbieter meldet eine erfolgreiche Anmeldung, während die WLAN-Assoziation weiterhin scheitert, oder die Registry gibt 401 zurück, nachdem ein Token-Austausch stattfand, den der Browser nie gesehen hat. Zwei Erfolge und ein Fehlschlag sind kein Widerspruch; es sind drei getrennte Authentifizierungen.

Wo ein Zertifikat einen wiederholten Code ersetzt

Bei verwalteten Geräten entfernt zertifikatsbasiertes EAP den menschlichen Schritt, ohne die Identität zu entfernen: Das Gerät legt ein Zertifikat vor, der RADIUS-Dienst prüft es gegen die ausstellende Autorität, und der Widerruf erfolgt bei dieser Autorität statt in einem geteilten Geheimnis. Der Preis ist Lebenszyklusarbeit, denn Zertifikate laufen ab und müssen vorher erneuert werden.

Registries haben eine äquivalente Aufteilung. Ein interaktiver Benutzer kann sich einmal anmelden und einen Anmeldedaten-Helfer das resultierende Token speichern lassen, während Automatisierung eng begrenzte Dienst-Anmeldedaten oder eine Workload-Identität nutzen sollte. Keines davon sollte der Einmalcode eines Menschen sein, der in eine Pipeline kopiert wurde. Der Helfer speichert ein Token für ein bestimmtes Registry-Publikum, sodass er sich nicht durch Bearbeiten einer Konfigurationsdatei auf das VPN-Gateway umlenken lässt.

docker login registry.example.com

Vergleiche die Wartungskosten, nicht die Zahl der Abfragen

Geteilte Anmeldedaten wirken billig, weil die Arbeit unsichtbar ist, bis sie scheitert. Zähle stattdessen, was jede Option über ein Jahr kostet: Registrierung, Erneuerung, Widerruf, den Wirkungsradius eines Lecks und die Zahl der Systeme, die berührt werden, wenn jemand das Unternehmen verlässt. Eine Zertifikatsflotte kostet mehr im Aufbau und weniger im Betrieb in großem Maßstab; ein kopierter Code kostet nichts zum Starten und alles zum Auflösen.

Wähle dann pro Strecke statt global. WLAN kann auf Zertifikate umstellen, das VPN kann sein unterstütztes SSO mit MFA behalten, und die Registry kann Tokens mit ausdrücklichen Scopes nutzen. Halte Eigentümer, Publikum, Scope, Ablauf und Widerrufspfad für jedes fest, und die Abfragen fallen dorthin, wo sie hingehören, statt überall gleichzeitig. Diese Aufzeichnung ist auch die Antwort, wenn ein Auditor fragt, welche Systeme noch einem Passwort vertrauen.