wake-up-neo.com

HTTP-Spezifikation: Proxy-Authorization- und Authorization-Header

Daher versuche ich, das folgende Szenario zu implementieren:

  • Eine Anwendung ist durch die Standardauthentifizierung geschützt. Nehmen wir an, es wird auf app.com Gehostet.
  • Ein HTTP-Proxy vor der Anwendung erfordert ebenfalls eine Authentifizierung. Es wird gehostet auf proxy.com

Der Benutzer muss daher Anmeldeinformationen sowohl für den Proxy als auch für die Anwendung in derselben Anforderung bereitstellen. Daher verfügt er über unterschiedliche Benutzer-/Kennwortpaare: Ein Paar zur Authentifizierung gegenüber der Anwendung und ein anderes Benutzer-/Kennwortpaar zur Authentifizierung gegenüber dem Proxy.

Nach dem Lesen der technischen Daten bin ich mir nicht sicher, wie ich das umsetzen soll. Was ich mir überlegt habe, ist:

  1. Der Benutzer sendet eine HTTP-Anforderung an den Proxy, ohne dass eine Authentifizierung erforderlich ist.
  2. Der Proxy antwortet mit 407 Proxy Authentication Required Und gibt einen Proxy-Authenticate - Header im Format "Proxy-Authenticate: Basic realm="proxy.com" Zurück.
    Frage: Ist dieser Proxy-Authenticate Header richtig gesetzt?
  3. Der Client wiederholt dann die Anforderung mit einem Header Proxy-Authorization, Dh der Base64-Darstellung des Proxys username:password.
  4. Diesmal authentifiziert der Proxy die Anfrage, doch dann antwortet die Anwendung mit einem 401 Unauthorized - Header. Der Benutzer wurde vom Proxy authentifiziert, jedoch nicht von der Anwendung. Die Anwendung fügt der Antwort einen WWW-Authenticate - Header wie WWW-Authenticate: Basic realm="app.com" Hinzu. Frage: dieser Header-Wert ist richtig?
  5. Der Client wiederholt die Anforderung erneut mit einem Proxy-Authorization - Header und einem Authorization -Header, der mit der Base64-Darstellung des username:password Der App bewertet wird.
  6. Zu diesem Zeitpunkt authentifiziert der Proxy die Anforderung erfolgreich und leitet sie an die Anwendung weiter, die auch den Benutzer authentifiziert. Und der Kunde bekommt endlich eine Antwort zurück.

Ist der gesamte Workflow korrekt?

42
Mark

Ja, das sieht nach einem gültigen Workflow für die von Ihnen beschriebene Situation aus, und diese Authenticate-Header scheinen das richtige Format zu haben.

Es ist interessant zu bemerken, dass es möglich, wenn auch unwahrscheinlich ist, dass eine bestimmte Verbindung mehrere Proxys umfasst, die miteinander verkettet sind, und dass jedes für sich eine Authentifizierung erfordert. In diesem Fall würde die Client-Seite jedes Intermediate-Proxys selbst ein 407 Proxy Authentication Required Nachricht und selbst wiederholen Sie die Anfrage mit der Proxy-Authorization Header; das Proxy-Authenticate und Proxy-Authorization Header sind Single-Hop-Header, die nicht von einem Server zum nächsten weitergegeben werden, sondern WWW-Authenticate und Authorization sind End-to-End-Header, die vom Client an den endgültigen Server gesendet werden und von den Intermediären wörtlich weitergegeben werden.

Da das Schema Basic das Kennwort im Klartext sendet (base64 ist eine umkehrbare Codierung), wird es am häufigsten über SSL verwendet. Dieses Szenario wird auf andere Weise implementiert, da verhindert werden soll, dass der Proxy das an den endgültigen Server gesendete Kennwort sieht:

  • der Client öffnet einen SSL-Kanal zum Proxy, um die Anforderung zu initiieren. Anstatt jedoch eine reguläre HTTP-Anforderung zu senden, wird diese gesendet eine spezielle CONNECT -Anforderung (immer noch mit einem Proxy-Authorization header), um einen TCP Tunnel zum entfernten Server zu öffnen.
  • Der Client erstellt dann einen weiteren SSL-Kanal, der im ersten verschachtelt ist, und überträgt die endgültige HTTP-Nachricht einschließlich des Headers Authorization.

In diesem Szenario kennt der Proxy nur den Host und den Port, mit dem der Client verbunden ist, und nicht, was über den inneren SSL-Kanal gesendet oder empfangen wurde. Darüber hinaus ermöglicht die Verwendung von verschachtelten Kanälen dem Client, die SSL-Zertifikate sowohl des Proxys als auch des Servers zu "sehen", wodurch die Identität beider authentifiziert werden kann.

28
Martin Atkins