Phase 1, Eventgesteuerter Eingangsagent HTTP

Ein externer HTTP-Client sendet einen Request an den Lobster Integration Server. Die Daten werden an ein passendes Profil weitergegeben, das in Phase 1 einen eventgesteuerten Eingangsagenten vom Typ HTTP verwendet. Die Response an den HTTP-Client erfolgt entweder als fester Wert oder wird aus den Zielstrukturdaten des Profils erzeugt.

Phase 1, Zeitgesteuerter Eingangsagent, beliebige Datenquelle, Trigger/Externer Aufruf

Ein externer HTTP-Client sendet einen Request an den Lobster Integration Server. Das startet ein passendes Profil, das einen Eingangsagenten des Typs Cron Job mit beliebiger Datenquelle und der Option Trigger/Externer Aufruf verwendet. Dieser Eingangsagent sammelt seine Eingangsdaten über die Datenquelle unabhängig vom HTTP-Request selbst, z. B. aus einer Datenbank. Aus dem Client-Request kann das Profil nur Request-Parameter als Variablenwerte übernehmen. Die Variablenwerte können im Profil verwendet werden oder auch um den Cron Job zu parametrisieren, z. B. bei einem Datenbank-SELECT in der WHERE-Klausel.

Phase 1, Zeitgesteuerter Eingangsagent, Datenquelle HTTP

Ein Profil verwendet in Phase 1 einen zeitgesteuerten Eingangsagenten des Typs HTTP. Dieser sendet einen Request an einen externen HTTP-Server. Die Response des Servers mit den Daten wird vom Profil als Eingangsdaten entgegengenommen.

Phase 3, Funktionen

Ein Profil verwendet in Phase 3 eine der folgenden Funktionen. Die Funktion sendet einen Request an einen externen HTTP-Server. Die Response des Servers kann in der Zielstruktur verarbeitet werden.

• http(a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p)

• http json-lookup(a,b,c,d,e,f,g,h,i,j,k,l,m)

Phase 6, Antwortweg HTTP

Ein Profil sendet in Phase 6 in einem Antwortweg des Typs Antwortweg des Typs HTTP einen Request an einen externen HTTP-Server. Die Response des Servers kann an ein zweites Profil weitergegeben und dort verarbeitet werden.

Suchen der Keystore-Datei

Im Verzeichnis ./etc/certs wird nach einer Datei gesucht, die den Namen des Hosts aus der URL der Serveradresse trägt. So wird z. B. für die URL https://www.java.com nach einer Datei mit dem Namen www.java.com gesucht.

Wird eine solche Datei gefunden, dann wird der Inhalt der Datei als Java-Keystore gelesen. In dem Keystore müssen sich die Schlüssel (auch der private) und alle Zertifikate der Zertifikatskette befinden. Der Keystore darf nur ein Schlüsselpaar enthalten und das Key-Passwort muss mit dem Keystore-Passwort übereinstimmen. In der Konfigurationsdatei ./etc/startup.xml muss dieses Passwort mit dem Parameter keystorePassword definiert werden.

Das Passwort kann im Klartext angegeben werden oder besser obfuscated. Der Keystore kann entweder mit dem Dienstprogramm keytool erzeugt und bearbeitet werden oder - viel komfortabler - mit Portecle (http://sourceforge.net/projects/portecle/).

Keine passende Keystore-Datei gefunden

Wird keine passende Keystore-Datei gefunden, greift der nachfolgende Mechanismus.

Ist die System-Variable VAR_AUTH_CERT_ID definiert und wurde ihr ein nichtleerer Wert zugewiesen, dann wird der Wert dieser Variablen als ID (Seriennummer) eines eigenen Zertifikates in der Partnerverwaltung interpretiert. Wird ein Zertifikat mit dieser ID gefunden, dann wird dieses an den HTTPS-Server übergeben. Dieses Zertifikat verwendet der Client dann zur Authentifizierung mit einem Client-Zertifikat, wenn der Server es fordert.

Keine Datei mit einem Zertifikat gefunden und Variable nicht definiert

Wird keine Datei mit einem Zertifikat gefunden und ist die Variable nicht definiert, dann wird kein Zertifikat an den HTTPS-Server übergeben. Es erfolgt keine Fehlermeldung.

Die beschriebene Vorgehensweise wird immer dann durchlaufen, wenn Lobster Integration in der Rolle als HTTPS-Client in Erscheinung tritt. Das heißt, bei Profilen mit zeitgesteuertem Eingangsagent und Datenquelle HTTP(S) und bei Profilen mit mindestens einem Antwortweg des Typs HTTP(S).

Die ID (Seriennummer) eines eigenen Zertifikats kann über die Liste der eigenen Zertifikate in der Partnerverwaltung ermittelt werden. Einfach ein Zertifikat ansehen und mit Strg+C die ID kopieren. In der GUI kann diese dann an den entsprechenden Stellen eingegeben werden. Wahlweise kann dort auch direkt ein Zertifikat aus einer Liste gewählt werden und die ID wird automatisch eingetragen.

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 Integration Preemptive Authentication?

Relevant ist diese Frage vor allem, wenn Lobster Integration 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 im Dialog "HTTP-Header anpassen" 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.

Beispiel:

(1) HTTP-Header: "Authorization".

(2) Wert: "d2lraTpwZWRpYQ==".