Vorbemerkungen

Im Normalfall erfolgt die HTTP-Authentifizierung wie unter https://de.wikipedia.org/wiki/HTTP-Authentifizierung bzw. https://tools.ietf.org/html/rfc2617 beschrieben. Im Fall einer Basic Authentication ist der Ablauf folgendermaßen.

• Der Client sendet einen Request ohne Login und Passwort.

• Der Server erkennt, dass für die angeforderte URL ein Login erforderlich ist und sendet deshalb den HTTP-Status 401 an den Client zurück.

• Wenn der Server Basic Authentication erwartet, sendet er einen Response Header. WWW-Authenticate: Basic realm="RealmName"

• Der Client entscheidet, ob er für diese URL aus einem kürzlich erfolgten Request einen Benutzernamen und Passwort kennt.

• Wenn der Client keine Login-Daten hat, fordert er üblicherweise vom Anwender die Eingabe in den Login-Dialog.

• Der Client sendet den Request erneut und liefert den HTTP Header mit. Authorization: Basic d2lraTpwZWRpYQ==

• Der Wert d2lraTpwZWRpYQ== ist hier nur eine beispielhafte Base64-Kodierung des Wertes wiki:pedia (also dem Benutzernamen wiki und dem Passwort pedia). Details zur Base64-Kodierung finden Sie in der Dokumentation der Admin-Konsole des Integration Servers.

• Der Server prüft die Login-Information. Wenn er sie akzeptiert, gewährt er den Zugang.

• Wenn er das Login nicht akzeptiert, sendet der Server entweder Status 403 oder wieder Status 401.

• Status 403 bedeutet, dass der Client einen Authorization Header gesendet hat, aber der User nicht berechtigt ist oder dass die geforderte Operation für alle User verboten ist.

Der Zugriff besteht also aus zwei Requests, wovon der erste ohne Login und erst der zweite mit Login-Daten erfolgt (nach Herausforderung durch den Server mit Status 401). Bei einem POST-Request ist das sehr ineffizient, weil eventuell mehrere Kilobytes Nutzdaten, die per POST hochgeladen werden sollen, beim ersten Request ohne Nutzen übertragen werden.

Ablauf der Preemptive Authentication

In diesem Fall spart der Client den ersten Request ohne Login-Daten einfach ein und sendet gleich den HTTP-Header Authorization beim ersten Request. Speziell wenn per POST an einen Webservice Daten hochgeladen werden, spart das die Hälfte des Upload-Volumens und der Zeit. Ein HTTP-/HTTPS-Server, der Basic Authentication erlaubt, wird üblicherweise auch die preemptive Variante akzeptieren. Bei anderen Authentifizierungs-Methoden, z. B. NTLM, ist der erste Request nicht verzichtbar, weil der Server erst in seiner ersten Response einen Schlüssel/Hash/Code sendet, die der Client dann auf irgendeine Art zur aktuellen Bildung des zweiten Requests verwenden muss.

Wenn der Server nur Preemptive Authentication unterstützt

Wenn der Server voraussetzt, dass der Client bereits beim ersten Request den HTTP Header Authorization sendet, wird eine Kommunikation nicht zustande kommen, wenn der Client nicht so konfiguriert ist. Der Client wird dann den ersten Request ohne Login senden, aber der Server sendet keinen Status 401 zurück, sondern gleich 403. Da der Client aber keine Herausforderung durch Status 401 empfängt, wird er auch bei einer Wiederholung des Requests keinen HTTP-Header Authorization mitsenden. Eine erfolgreiche Kommunikation kommt so nicht zustande.

Server, die nur preemptive Login erlauben, sind sicher die absolute Ausnahme. Wenn ein solches Fehlerbild (Status 403) beim Zugriff auf einen HTTP-Server auftritt, muss man aber die Möglichkeit in Betracht ziehen, dass ein präemptives Login erwartet wird. Das ist aber nicht die einzige mögliche Ursache für einen Response-Status 403. Siehe https://en.wikipedia.org/wiki/HTTP_403.

Unterstützt Lobster_data Preemptive Authentication?

Relevant ist diese Frage vor allem, wenn Lobster_data als Client handelt. HTTP-Header im HTTP-Antwortweg oder einem zeitgesteuerten Eingangsagenten des Typs HTTP werden folgendermaßen eingefügt. Der BASE64-Wert (d2lraTpwZWRpYQ==) muss vorher aus <Benutzername>:<Passwort> erzeugt werden (also hier aus wiki:pedia, siehe Vorbemerkungen oben). Danach wird er, wie oben im Screenshot gezeigt, im Dialog eingefügt.

Die Eingabe von Benutzername und Passwort in die üblichen Felder der Antwortweg- oder Cron-Maske ist dadurch irrelevant, da sie niemals verwendet wird.