End-to-End SSL

Funktionsweise

Im Gegensatz zum Betrieb mit HTTP kann bei Verwendung von End-to-End-SSL der SAP Web Dispatcher keine Daten des Requests lesen und damit auch ein eventuell vorhandenes Session Cookie (bei stateful Anwendungen) nicht interpretieren. Es fehlen also die notwendigen Informationen, um den Request an den richtigen Server weiterzuleiten. Der SAP Web Dispatcher kann auch nicht entscheiden, ob ein Request zu einer stateless oder stateful Anwendung gehört.

Deshalb leitet der SAP Web Dispatcher die verschlüsselten Daten unverändert an einen Applikationsserver weiter. Erst dort werden die Daten entschlüsselt.

Das einzige Unterscheidungsmerkmal, das dem SAP Web Dispatcher zur Verfügung steht, ist die Client IP-Adresse. Aus diesem Grund verwaltet der SAP Web Dispatcher eine Abbildungstabelle zwischen Client IP-Adresse und Applikationsserver. Wurde ein Request von einer Client-IP-Adresse zu Applikationsserver X geschickt, müssen alle folgenden Requests dieser Client IP-Adresse auch zu diesem Server geschickt werden, da es sich ja um eine stateful Anwendung handeln könnte. Ein Loadbalancing findet also nur beim allerersten Request des Clients statt.

Konfiguration

End-to-End-SSL ist sehr einfach zu konfigurieren. Sie setzen beim Parameter icm/server_port_<xx> das Protokoll auf den Wert ROUTER.

Einschränkungen

Alle Konfigurationen, die von der Kenntnis der HTTP-Inhalte abhängen, sind wirkungslos:

• Konfiguration von HTTP Redirects

• Konfiguration von Fehlerseiten im Web Dispatcher

• Konfiguration von Filehandlern,

• Konfiguration eines HTTP Cache im Web Dispatcher

• Zugriff auf die Web Administrationsoberfläche des Web Dispatcher über SSL

• Konfiguration eines HTTP Zugriffprotokolls

• Konfiguration abzuweisender/erlaubter URLs

• Konfiguration der Systemauswahl bei mehreren Systemen

Außerdem treten die im folgenden beschriebenen Probleme auf:

• Verwendung von Proxies

• Protokollwechsel für stateful Requests

Handhabung von Proxies

Alle Unternehmen benutzen Proxies; d.h. Requests, die über einen Proxy gehen, werden alle zu einem Server geschickt. Damit ist auch das Loadbalancing beim ersten Request ausgehebelt.

Große Unternehmen verwenden mehrere parallele Proxies (die ihrerseits einen Lastausgleich vornehmen) als Zugang ins Internet, d.h. ein Request desselben Clients geht über Proxy A, ein späterer Request desselben Clients, der zur selben Session gehört, geht über Proxy B an den SAP Web Dispatcher und hat damit eine unterschiedliche Client-IP-Adresse.

Konfiguration

Mit dem Profilparameter wdisp/HTTPS/sticky_mask können Sie mehrere Client-IP-Adressen zu einer logischen Adresse gruppieren. Im Abschnitt SSL-Parameter ist die genaue Funktionsweise des Parameters beschrieben.

Default ist: Die Maske 255.255.240.0 wird mit der realen IP-Adresse UND-verknüft; damit werden die untersten 12 Bits ausgeblendet, d.h. 124.94.55.1 und 124.94.55.99 werden dann als gleich aufgefasst.

Abbildungstabelle

Die Abbildungstabelle, mit der der SAP Web Dispatcher Client-IP-Adressen und zugeordnete Applikationsserver verwaltet, hat die folgenden Eigenschaften.

• Die Größe der Abbildungstabelle ist auch abhängig von der sticky-mask. Je mehr Bits ausgeblendet werden, desto kleiner wird die Abbildungstabelle. Wie viele Einträge diese Tabelle maximal enthalten kann, wird mit dem Profilparameter wdisp/HTTPS/max_client_ip_entries eingestellt. Im Abschnitt SSL-Parameter ist die genaue Funktionsweise des Parameters beschrieben.

  Achtung

  Beachten Sie: Wenn die Abbildungstabelle voll ist, d.h. der Wert von wdisp/HTTPS/max_client_ip_entries erreicht ist, nimmt der SAP Web Dispatcher keinen Lastausgleich mehr vor! Der Parameter soll also immer den Bedürfnissen und Ressourcen entsprechend eingestellt sein.

• Wird ein Server heruntergefahren, so ist ein Kontext auf diesem Server gelöscht und für die zugehörige Client-IP-Adresse wird ein neuer Server gesucht. Mit dem Parameter wdisp/HTTPS/context_timeout kann der Timeout für Einträge in der Client IP Tabelle angegeben werden (in Sekunden; Standardwert 3600). Ein Eintrag wird aus der Tabelle gelöscht, wenn innerhalb der angegebenen Zeitspanne kein Request von dieser Client-IP-Adresse angekommen ist. Der Wert muss immer größer sein als der Session-Timeout der Applikationsserver.

Protokollwechsel bei stateful Anwendungen

Für zustandsbehaftete (stateful) Anwendungen ist es nicht möglich, einen Protokollwechsel von HTTP nach HTTPS oder von HTTPS nach HTTP durchzuführen.

Der Grund ist, dass die Mechanismen, zustandsbehaftete Requests an die Applikationsserver weiterzuleiten, unterschiedlich sind.

Bei Verwendung des HTTP Protokolls wird die Zustandsinformation in den HTTP Daten (Cookie, URL oder Semikolonparameter) verwendet, bei Verwendung des HTTPS Routerprotokolls wird die Client-IP-Adresse verwendet, um HTTPS Requests eines Clients an immer denselben Applikationsserver weiterzuleiten.

Über einen Protokollwechsel hinaus ist es nicht gewährleistet, dass Requests einer Session an den selben Applikationsserver weitergeleitet werden.

Auswahl eines geeigneten Applikationsservers

HTTPS-fähige Applikationsserver

Mit dem Parameter wdisp/HTTPS/dest_logon_group können Sie eine Logongruppe von HTTPS-fähigen Applikationsservern definieren, zu denen dann alle HTTPS-Requests geschickt werden.

Weitere Informationen: SSL-Parameter

ABAP- oder Java-Server

Da der SAP Web Dispatcher nicht entscheiden kann, ob ein Request für die Verarbeitung im Application Server ABAP oder im Application Server Java bestimmt ist, müssen alle Server in der Logongruppe für HTTPS-Requests die gleichen Services bereitstellen. Natürlich müssen alle Server HTTPS-fähig sein, einer der folgenden Fälle muss zutreffen.

• alle Server bieten Java und ABAP an

• alle Server bieten nur ABAP an

• alle Server bieten nur Java an