HTTP-Spezifikation: Proxy-Autorisierungs- und Autorisierungsheader

So, ich bin versucht zu implementieren, das folgende Szenario:

  • Eine Anwendung ist geschützt durch eine Basis-Authentifizierung. Lassen Sie uns sagen, es ist gehostet auf app.com
  • Einen HTTP-proxy, vor der Anwendung, die eine Authentifizierung erfordert, als gut. Es ist gehostet auf proxy.com

Muss der Benutzer daher bieten Anmeldeinformationen für die proxy-und die Anwendung in der gleichen Wunsch, so hat er verschiedene Benutzernamen/Passwort-Paare: ein paar zum authentifizieren sich gegen den Antrag, und ein Benutzername/Passwort paar zum authentifizieren sich gegen den proxy.

Nach dem Lesen der specs, ich bin mir nicht wirklich sicher, wie ich das umsetzen sollte. Das, was ich dachte zu tun ist:

  1. Der Benutzer eine HTTP-Anforderung an den proxy-ohne irgendeine Art der Authentifizierung.
  2. Der proxy Antworten 407 Proxy Authentication Required und gibt einen Proxy-Authenticate header im format: "Proxy-Authenticate: Basic realm="proxy.com".
    Frage: Ist das Proxy-Authenticate header korrekt gesetzt?
  3. Der client dann wiederholt die Anfrage mit einer Proxy-Authorization header, das ist die Base64-Darstellung der proxy -username:password.
  4. Dieses mal der proxy die Anforderung authentifiziert, aber dann die Applikation antwortet mit einem 401 Unauthorized header. Wurde der Benutzer authentifiziert den proxy-Server, aber nicht von der Anwendung. Die Anwendung fügt eine WWW-Authenticate - header die Antwort-wie WWW-Authenticate: Basic realm="app.com". Frage: diesen header-Wert ist das richtige?
  5. Der client wiederholt wieder die Anforderung, dass mit einem Proxy-Authorization - header, und ein Authorization header geschätzt, mit der die Base64-Darstellung der app ist username:password.
  6. An dieser Stelle ist, dass der proxy erfolgreich authentifiziert die Anforderung, leitet die Anfrage an die Anwendung authentifiziert den Benutzer. Und der Kunde bekommt endlich eine Antwort zurück.

Ist der gesamte workflow richtig?

InformationsquelleAutor der Frage Mark | 2012-04-05

  1. 26

    Ja, das sieht aus wie eine gültige workflow für die situation, die Sie beschrieben, und diejenigen, die Authenticate-Header zu sein scheinen in das richtige format.

    Es ist interessant zu beachten, dass es möglich, wenn auch unwahrscheinlich, für eine bestimmte Verbindung, um mit mehreren Proxys, die miteinander verkettet, und jeder kann sich selbst die eine Authentifizierung erfordern. In diesem Fall werden die client-Seite von jedem zwischengeschalteten proxy würde sich wieder eine 407 Proxy Authentication Required Nachricht und sich selbst wiederholen Sie die Anforderung mit den Proxy-Authorization header; die Proxy-Authenticate und Proxy-Authorization Header sind single-hop-Header, die nicht übergeben bekommen, von einem server zum nächsten, aber WWW-Authenticate und Authorization sind Ende-zu-Ende-Header betrachtet werden, die vom client an den final-server, übergeben durch wortwörtlich durch die Vermittler.

    Da die Basic Regelung sendet das Passwort im Klartext (base64 ist eine reversible Kodierung) es wird am häufigsten über SSL. Dieses Szenario ist umgesetzt in verschiedener Weise, weil es wünschenswert ist, zu verhindern, dass der proxy aus zu sehen, die das Kennwort geschickt, um den endgültigen server:

    • öffnet der client einen SSL-Kanal an den proxy, um die Anforderung zu initiieren, aber anstelle der Einreichung eine normale HTTP-Anfrage, es würde reichen ein besonderes CONNECT - Anfrage (immer noch mit einem Proxy-Authorization Kopfzeile) öffnet ein TCP-tunnel auf dem remote-server.
    • Der Kunde geht dann zu erstellen anderen SSL-Kanal verschachtelte innerhalb der ersten, über die er überträgt die Letzte HTTP-Nachricht einschließlich der Authorization header.

    In diesem Szenario der proxy weiß nur der host und port der client verbunden ist, nicht das, was gesendet oder empfangen über die interne SSL-Kanal. Weiter, die Verwendung von verschachtelten Kanäle, die es dem client ermöglicht, zu "sehen" die SSL-Zertifikate von sowohl dem proxy und dem server, so dass die Identität authentifiziert werden.

    InformationsquelleAutor der Antwort Martin Atkins

Schreibe einen Kommentar