Java-Unterstützung für Proxies und HTTP-Authentifizierung

Das HTTP-Protokoll unterstützt den Schutz von Ressourcen, so dass man nur mit entsprechender Autorisierung Zugang zu ihnen erlangt. Wird ein Request an eine solche Ressource geschickt, antwortet der Web-Server mit dem HTTP-Statuscode 401 „Unauthorized“ (siehe RFC2616). In diesem Fall beinhaltet die Antwort einen WWW-Authenticate-Header, der Schema und Bereich (Realm) spezifiziert.

Das Schema definiert die zur Bereitstellung der Autorisierung anzuwendende Methode. Zurzeit sind zwei Methoden definiert: Basic und Digest (siehe RFC2617). Dieser Artikel geht hauptsächlich auf die Basic-Methode ein, da diese geläufiger und einfacher anzuwenden ist, wenn auch die Digest-Methode besser ist und ein größeres Maß an Sicherheit bietet.

Der Realm
Der Realm ist eine willkürliche Zeichenfolge, die einen Schutzbereich (eine Reihe geschützter Ressourcen) innerhalb des gleichen Hosts definiert. Ein einzelner Host can mehrere Realms haben, und alle Ressourcen innerhalb eines Realm nutzen die gleichen Autorisierungen. D.h., eine Autorisierung, die während eines Requests nach einer bestimmten Ressource gültig ist, muss auch für alle nachfolgenden Requests nach anderen Ressourcen innerhalb dieses Realms gültig sein.

Versucht man z.B., auf eine geschützte Ressource innerhalb des Realms „Geschütztes Gebiet“ auf irgendeinem Webserver zuzugreifen, erscheint der folgende Header in der Antwort (vorausgesetzt, der Webserver benutzt die Authentifizierungsmethode Basic):


WWW-Authenticate: Basic realm="Geschütztes Gebiet"

Der Request muss wieder gesendet werden, diesmal unter Einschluss des Authorization-Header und Angabe eines gültigen Benutzernamens und Passworts. Die Art der Abfrage von Benutzername und Passwort wird von der jeweiligen Anwendung bestimmt. Normalerweise zeigen z.B. Browser ein Dialogfeld mit dem Host und dem Realm an und verlangen die Eingabe des Benutzernamens und des Passworts.

Im Authorization-Header müssen die angewandte Authentifizierungsmethode und Benutzername bzw. Passwort wie folgt angegeben sein: <username>:<password>, als eine mit Base64 kodierte Zeichenfolge (siehe RFC2045). Wenn also „Aladdin“ der Benutzername und „open sesame“ das Passwort ist, würde der zu sendende Header so aussehen:


Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Das Gleiche gilt auch für Proxies, nur dass Proxies mit dem HTTP-Statuscode 407 „Proxy Authentication Required“ und dem Proxy-Authenticate-Header auf einen Request ohne entsprechende Autorisierung antworten. Die Autorisierung muss über den Proxy-Authorization-Header im Request bereitgestellt werden.

Wie Proxies sind auch Benutzername und Passwort durch die entsprechende Konfiguration innerhalb der Anwendung spezifiziert. Dadurch ist es nicht mehr nötig, dass die Anwendung den Statuscode 407 abwartet, um die erforderlichen Informationen abzufragen und den Request erneut zu senden.

Page: 1 2 3 4

ZDNet.de Redaktion

Recent Posts

Lags beim Online-Gaming? DSL-Vergleich und andere Tipps schaffen Abhilfe

Beim Online-Gaming kommt es nicht nur auf das eigene Können an. Auch die technischen Voraussetzungen…

2 Tagen ago

GenKI-Fortbildung immer noch Mangelware

Fast jedes zweite Unternehmen bietet keinerlei Schulungen an. In den übrigen Betrieben profitieren oft nur…

2 Tagen ago

Netzwerk-Portfolio für das KI-Zeitalter

Huawei stellt auf der Connect Europe 2024 in Paris mit Xinghe Intelligent Network eine erweiterte…

2 Tagen ago

Internet-Tempo in Deutschland: Viel Luft nach oben

Höchste Zeit für eine schnelle Kupfer-Glas-Migration. Bis 2030 soll in Deutschland Glasfaser flächendeckend ausgerollt sein.

2 Tagen ago

Erste Entwickler-Preview von Android 16 verfügbar

Schon im April 2025 soll Android 16 den Status Plattformstabilität erreichen. Entwicklern gibt Google danach…

2 Tagen ago

Kaspersky warnt vor Cyberangriff auf PyPI-Lieferkette

Die Hintermänner setzen KI-Chatbot-Tools als Köder ein. Opfer fangen sich den Infostealer JarkaStealer ein.

2 Tagen ago