Meldet VPN-SSO Benutzer automatisch bei internen Apps an?

Ein VPN-Gateway, das sich über einen Identitätsanbieter authentifiziert, beweist nur eines: Der Anbieter hat für einen Benutzer gegenüber dem Gateway gebürgt. Es übergibt diesem Benutzer keine Anmeldedaten für das Intranet-Wiki, das Monitoring-Dashboard oder den Build-Server. Diese Dienste melden Personen über ihre eigene Föderation an und wenden ihre eigene Autorisierung an, und der Tunnel entscheidet nur, welche Pakete sie erreichen können.

Drei Sitzungen, drei getrennte Entscheidungen

Halten Sie die Zustände auseinander, denn jeder läuft nach seinem eigenen Zeitplan ab. Die VPN-Sitzung ist die Annahme einer Identität durch das Gateway plus der gewährte Netzwerkzugriff. Die Browser-Sitzung beim Identitätsanbieter ist das, was der Browser für diesen Anbieter noch hält und nach seiner Richtlinie wiederverwenden darf. Die Anwendungssitzung gehört zu einem Dienst, der eine an ihn adressierte Antwort validiert hat.

Wer diese Zustände verwechselt, stellt die falsche Frage, meist formuliert als: Warum meldet der Tunnel den Benutzer nicht überall an? Formulieren Sie um: Welche Anwendung hat keinen Föderationseintrag, welche weist den Benutzer ab, und welcher fehlt eine Route. Eine einzelne Anmeldeaufforderung, die die Intranet-Anwendung öffnet, kann trotzdem zum Anbieter zurückspringen, weil die zweite Weiterleitung eine neue Autorisierungsanfrage für ein anderes Publikum ist.

Verdrahten Sie das Gateway als eigene Anwendung

Registrieren Sie das VPN als genehmigte Anwendung beim Anbieter, mit eigener Kennung, Weiterleitungs-URI und Benutzerzuweisung. Legen Sie dann fest, welche Netzwerkautorisierungen diese Anmeldung gewährt, denn das ist eine VPN-Richtlinie und keine Anbieterfunktion. Benutzer, die nur das Monitoring-Subnetz erreichen sollen, erhalten eine andere Gateway-Richtlinie, kein anderes Passwort.

Die Authentifizierungsantwort des Tunnels ist keine wiederverwendbaren Anmeldedaten. OIDC-ID-Tokens tragen einen Publikumsanspruch, der den Client nennt, für den sie ausgestellt wurden, und SAML-Bearer-Assertions beschränken das Publikum auf den empfangenden Dienstanbieter. Ein zweiter Dienst, der die Antwort des ersten akzeptiert, ist falsch konfiguriert, und ein Token in eine andere App zu kopieren ist keine Integration.

Registrieren Sie jede interne App und setzen Sie dann den Browserkontext

Jeder Dienst braucht die unterstützten SAML- oder OIDC-Werte: Aussteller, Client-Kennung, Callback- oder Assertion-Consumer-URL, erforderliche Ansprüche und Zuweisung. Die Erreichbarkeit kommt obendrauf, denn Identitätsprüfungen liefern nie eine Route oder eine DNS-Antwort.

1. Legen Sie den Anwendungseintrag an und bestätigen Sie, dass die Entitäts- oder Client-ID zu dem passt, was die App sendet.
2. Registrieren Sie die exakte Callback-URL einschließlich Schema und Port; eine knappe Abweichung schlägt fehl, nachdem der Benutzer sich authentifiziert hat.
3. Weisen Sie die Benutzer oder Gruppen zu und bestätigen Sie dann, dass die erforderlichen Ansprüche ausgegeben werden.
4. Erlauben Sie die Endpunkte des Identitätsanbieters ebenso wie die private App, sonst kann die Weiterleitung nicht abschließen.

Der Browserkontext entscheidet, ob eine bestehende Anbietersitzung wiederverwendet wird. Ein nativer Client, der den Systembrowser öffnet, kann diesen Zustand teilen, während eine eingebettete Ansicht mit eigenem Cookie-Speicher das meist nicht kann. Neuer Browser, private Fenster und ein zweites Profil starten bei null, was zu erwarten ist und keine kaputte SSO-Konfiguration.

Führen Sie den Ablauf aus und lesen Sie, wo er stoppt

Reproduzieren Sie mit dem Netzwerkpanel des Browsers und beobachten Sie die Weiterleitungskette. Ein nützlicher Durchlauf folgt jeweils einem Sprung: Gateway zum Anbieter, Anbieter zurück zur App mit Code oder Assertion, App zum Token-Endpunkt des Anbieters, App-Sitzung ausgestellt. Der Sprung, an dem die Kette stoppt, benennt die zu reparierende Komponente.

Zwei Kommandozeilenprüfungen klären die üblichen Zweifel, und beide lassen sich gefahrlos von einem Admin-Host ausführen:

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

Wenn die Metadaten Endpunkte auflisten, die Sie nie registriert haben, zeigt die App auf einen anderen Mandanten oder Aussteller. Wenn die erste Anfrage an die App mit 302 auf einen unerwarteten Host antwortet, ist die Föderationskonfiguration der Anwendung die Stelle zum Nachsehen, nicht das VPN-Profil.

Beheben Sie Aufforderungen, indem Sie finden, wer gefragt hat

Eine zweite Passwortaufforderung ist nicht automatisch ein Defekt. Die Anwendung kann ein höheres Vertrauensniveau anfordern, oder der Anbieter kann ein Höchstalter der Sitzung und eine neue Herausforderung erzwingen. Diese Anforderungen zu entfernen, damit der Ablauf ruhiger wird, schwächt eine bewusste Kontrolle, also stellen Sie erst fest, welche Komponente gefragt hat, bevor Sie die Richtlinie ändern.

Entscheiden Sie dann, was Sie verbessern. Kommt die Aufforderung von der App, reparieren Sie ihren Föderationseintrag. Kommt sie vom Anbieter per Richtlinie, dokumentieren Sie die Anforderung. Ist die App nach erfolgreicher Anmeldung nicht erreichbar, steht das Tunnel-Routing im Verdacht, denn Identität und Paketzustellung scheitern an verschiedenen Stellen und sehen vom Platz des Benutzers aus ähnlich aus.