SAP Web Dispatcher installieren und konfigurieren

Der SAP Web Dispatcher erhält vom Message-Server und den Applikationsservern Informationen über die Applikationsserver, die er für die Lastverteilung benötigt. Die folgende Liste zeigt die Arten von Informationen:

• Er holt Serverinformationen (die Liste der Server, die er für Requests verwenden kann) vom Message-Server.
• Sie erhält Informationen über die Anmeldegruppen und die URL-Zuordnung von einem ABAP-Anwendungsserver.
• Der SAP Web Dispatcher prüft die Verfügbarkeit der Applikationsserver durch Ping-Requests an die Applikationsserver.

Der SAP Web Dispatcher erhält Informationen über die Applikationsserver des SAP-Systems vom Message-Server über HTTP(S). Sie können den SAP Web Dispatcher in einigen Szenarien für AS-ABAP-Systeme, AS-Java-Systeme, HANA-XS-Systeme und SAP-Cloud-Platform-Systeme verwenden.

Die HTTP-Schnittstelle des Message-Servers ermöglicht es Ihnen, Informationen über die Applikationsserver-Instanzen mit einem Web-Browser anzuzeigen. Geben Sie dazu die folgende URL ein:http(s)://<Message-Server-Host>.<Message-Server-Domäne>:<Message-Server-Port>/msgserver/text/logon?Version = 1.3.

Voraussetzungen für den Betrieb des SAP Web Dispatchers sind

• Der SAP Web Dispatcher kann den HTTP-Port des SAP-Message-Servers kontaktieren.
• Folgende ICF-Services sind aktiv:
  • /sap/public/icman
  • /sap/public/icf_info und alle Unterservices

Auf dem Host, auf dem der SAP Web Dispatcher verwendet wird, genügt es, die ausführbare Datei (Name: sapwebdisp) und eine Profildatei bereitzustellen. Die ausführbare Datei ist das Paket sapwebdisp.sar, das Sie für verschiedene Plattformen aus dem SAP Support Portal (Bereich SAP Technology Components) herunterladen können. Außerdem benötigen Sie ein Profil, das in der Regel sapwebdisp.pfl heißt. Eine Liste der Profilparameter finden Sie in der Online-Dokumentation. Das Ausführen des Befehls sapwebdisp pf=<Profildatei> ist ausreichend, um den SAP Web Dispatcher zu starten.

Sie können den SAP Web Dispatcher auch ohne Profildatei starten. Für diese Bootstrap-Option (gestartet mit dem Befehl sapwebdisp -bootstrap) werden die folgenden Schritte ausgeführt:

1. Wenn die Profildatei sapwebdisp.pfl nicht vorhanden ist, wird sie basierend auf interaktiven Einträgen angelegt.

2. Wenn die Berechtigungsdatei icmauth.txt nicht vorhanden ist, wird sie angelegt und ein Benutzer für die Web-Administrationsoberfläche eingegeben.

3. Der SAP Web Dispatcher wird mit der erzeugten Profildatei gestartet.

Die Werkzeuge für die Installation und Aktualisierung von SAP-Produkten werden mit dem Software Logistics Toolset (SL Toolset) ausgeliefert, das mehrmals im Jahr aktualisiert wird, sodass Sie rechtzeitig die neuesten Verbesserungen und Updates erhalten. Auf diese Weise liefert das SL Toolset kontinuierlich Verbesserungen an Softwarelogistikwerkzeugen, unabhängig von der Auslieferung von SAP-Anwendungsprodukten. Das SL Toolset wird in Support Package Stacks ausgeliefert.

Software Provisioning Manager (SWPM) ist der Nachfolger der produkt- und release-spezifischen Auslieferung von Bereitstellungswerkzeugen. Es bietet die neueste SAPinst-Version mit Softwarebereitstellungsservices für mehrere Produkte und Releases für alle Plattformen, sodass Sie direkt von aktuellen Verfahren profitieren können, die von einem zuverlässigen Tool unterstützt werden, das seit Jahren verfügbar ist und verwendet wird.

In der Zwischenzeit sind zwei Versionen von Software Provisioning Manager verfügbar:

• Software Provisioning Manager 1.0
• Software Provisioning Manager 2.0

Beide Versionen können für die Installation des SAP Web Dispatchers verwendet werden.

Wenn Sie explizit die Nicht-Unicode-Version von SAP Web Dispatcher installieren möchten, müssen Sie Software Provisioning Manager 1.0 verwenden.

Um den neuesten SWPM herunterzuladen, öffnen Sie https://support.sap.com/sltoolset, und navigieren Sie zu System Provisioning → Download Software Provisioning Manager → SOFTWARE PROVISIONING MGR 2.0 → SUPPORT PACKAGE PATCHES → <Plattform> . Weitere Informationen zu SWPM finden Sie im SAP Help Portal – Additional Content on Software Provisioning Manager 1.0 and 2.0 unter https://help.sap.com/docs/SUPPORT_CONTENT/sl/3362916978.html.

Die SWPM-basierte Installation des SAP Web Dispatchers erfordert die folgenden SAP-Archive (.SAR-Dateien):

• SAP Web Dispatcher

• SAP Host-Agent

Um das neueste SAP-Web-Dispatcher-Archiv herunterzuladen, öffnen Sie https://me.sap.com/softwarecenter, und navigieren Sie zu Support Packages & Patches → By Category → SAP Technology Components → SAP Web Dispatcher → SAP Web Dispatcher <Release> → <Plattform>.

Um das neueste SAP-Host-Agent-Archiv herunterzuladen, öffnen Sie https://me.sap.com/softwarecenter, und navigieren Sie zu Support Packages & Patches → By Category → SAP Technology Components → SAP Host Agent → SAP Host Agent <Release> → <Plattform>.

Die ausführbare Datei sapinst kann mit vielen Befehlszeilenoptionen gestartet werden. Um alle anzuzeigen, geben Sie sapinst -p ein.

Die Option zum Installieren eines SAP Web Dispatchers finden Sie unter Generische Optionen → SAP Web Dispatcher → SAP Web Dispatcher (Unicode) (der Pfad kann je nach SWPM-Release variieren).

SWPM bietet zwei Optionen für den Parametermodus: Typisch oder Benutzerdefiniert. Die Abbildung listet Dialoge von SWPM auf, wenn sie im Parametermodus = Typisch ausgeführt werden.

Um auf die Installationsleitfäden für den SAP Web Dispatcher zuzugreifen, öffnen Sie den Guide Finder for SAP NetWeaver and ABAP Platform unter https://help.sap.com/viewer/nwguidefinder, und suchen Sie nach dispatcher. Beachten Sie die richtigen Betriebssysteme und SWPM-Version.

Kopiervorlagen für das Profil sowie Parameterbeschreibungen finden Sie in der Online-Dokumention. Der SAP Web Dispatcher muss wissen, an welchem Port er HTTP(s)-Requests auf welchem Host und mit welchem HTTP(S)-Port auf den Message-Server zugreifen kann (beide werden über den Profilparameter wdisp/system_<xx> des SAP Web Dispatchers gesetzt).

Sie können die Konfiguration des SAP Web Dispatchers prüfen, um sicherzustellen, dass Ihre Einstellungen funktionieren, wenn der Dispatcher läuft. Starten Sie dazu den SAP Web Dispatcher aus der Kommandozeile mit dem Kommando: sapwebdisp pf=<profile> -checkconfig. Dadurch werden die folgenden Positionen verifiziert:

• Wenn die Konfiguration der maximalen Anzahl von Sockets im Betriebssystem die erforderliche Anzahl konfigurierter Verbindungen zulässt.
• Wenn die Informationen zu den Applikationsservern in einer Datei und im Parameter wdisp/server_info_location konfiguriert sind. Prüfen Sie Syntax und Semantik dieser Datei.
• Wenn die Informationen zu den Applikationsservern im Message-Server konfiguriert sind:
  • Testen Sie die Verbindung zum HTTP-Port des Message-Servers.
  • Prüfen Sie die Daten vom Message-Server mit der konfigurierten URL.
• Wenn die Verbindung zu allen Anwendungsservern gefunden wird.
• Wenn die Datei mit wdisp/group_info_location konfiguriert ist, führen Sie eine syntaktische/semantische Prüfung der Gruppendatei durch. Ansonsten prüfen Sie die Daten eines Applikationsservers mit der konfigurierten URL (/sap/public/icf_info/icr_groups). Prüfen Sie, ob die ICF-Knoten aktiviert sind.
• Wenn die Datei mit wdisp/url_map_info_location konfiguriert ist, führen Sie eine syntaktische/semantische Prüfung der Gruppendatei durch. Andernfalls prüfen Sie die Daten eines Anwendungsservers mit der konfigurierten URL (/sap/public/icf_info/icr_urlprefix). Prüfen Sie, ob die ICF-Knoten aktiviert sind.

Wenn Sie Ihre SAP-Web-Dispatcher-Installation aktualisieren möchten, laden Sie das SAP-Web-Dispatcher-Archiv (für das richtige Betriebssystem und Hauptrelease) unter https://support.sap.com/swdc unter folgendem Pfad herunter: Software Downloads → Support Packages & Patches → By Category → SAP Technology Components → SAP Web Dispatcher → SAP Web Dispatcher <Release> → <Plattform>. Entpacken Sie diese Datei (indem Sie sapcar -xvf <sapwebdisp.sar file> ausführen) in das richtige Verzeichnis, und starten Sie den SAP Web Dispatcher (neu). Fahren Sie wie in SAP-Hinweis 908097 beschrieben fort (die Vorgehensweise ähnelt einem Kernel-Update).

Ähnlich wie der ICM-Prozess wird der SAP Web Dispatcher über Parameter konfiguriert. Die Vorschlagswerte sind so gewählt, dass Sie keine Änderungen an diesen Parametern vornehmen müssen. Den Zugangspunkt zu Ihrem SAP-System ermitteln Sie mit dem Parameter icm/server_port_<x>.

Sie können die Parameter verwenden, um die Konfiguration an bestimmte Systemanforderungen anzupassen.

Da sich der SAP Web Dispatcher mit dem SAP-Message-Server verbindet und über HTTP mit ihm kommuniziert, muss der Parameter wdisp/system_<x> im Profil des SAP Web Dispatchers korrekt gesetzt sein.

Sie haben mehrere Möglichkeiten, die Parameter des SAP Web Dispatchers zu ändern.

Eine Möglichkeit besteht darin, einen Parameter im Instanzprofil des SAP Web Dispatchers mit einem Texteditor Ihrer Wahl zu ändern.

Starten Sie einen gestoppten SAP Web Dispatcher mit einem der folgenden Werkzeuge:

• SAP Management Console (SAP MC)
• SAP Microsoft Management Console (SAP MMC)
• Befehlszeilenwerkzeug sapcontrol (Option -function StartSystem ALL)
• Befehlszeilenwerkzeug sapwebdisp (Option pf=<Instanzprofil>)

Verwenden Sie eines der folgenden Werkzeuge, um einen laufenden SAP Web Dispatcher neu zu starten:

• SAP Management Console (SAP MC)
• SAP Microsoft Management Console (SAP MMC)
• Befehlszeilenwerkzeug sapcontrol (Option -function RestartSystem ALL)
• Befehlszeilenwerkzeug sapwebdisp (Option pf=<Instanzprofil>)
• Web-Administrationsoberfläche des SAP Web Dispatchers (Shutdown oder Soft Shutdown)

Ein alternativer Ansatz besteht darin, einen laufenden SAP Web Dispatcher neu zu konfigurieren, nachdem Sie einen Parameter in seinem Instanzprofil geändert haben. Stellen Sie als Voraussetzung sicher, dass der Parameter wdisp/config_reload auf TRUE gesetzt ist (der Standardwert ist FALSE).

Um die Neukonfiguration eines laufenden SAP Web Dispatchers auszulösen, geben Sie den folgenden Befehl auf Befehlszeilenebene ein:

sapwebdisp pf=<Instanzprofil> -recofig profile

Auf der Web-Administrationsoberfläche können Sie auch Parameter ändern. Navigieren Sie dazu zu Core → Systemparameter → Parameter bearbeiten.

Nachdem Sie einen Parameternamen eingegeben haben, wählen Sie Wert abrufen. Im Falle eines gültigen Eintrags werden eine Kurzbeschreibung und der Typ des Parameters angezeigt.

Viele, aber nicht alle Parameter sind dynamisch änderbar. Wenn ein dynamisch änderbar ist, haben Sie die Möglichkeit, ihn vorübergehend zu ändern. Ähnlich wie bei einer Änderung eines dynamischen Parameters im AS ABAP (Transaktion RZ11) wird die Änderung sofort übernommen, geht aber nach einem Neustart des SAP Web Dispatchers verloren.

Wenn Sie den Parameter dauerhaft ändern, wird die Änderung auf das Instanzprofil des SAP Web Dispatchers angewendet. Außerdem wird eine Sicherung des früheren Instanzprofils angelegt (im Sicherungsunterverzeichnis des Profilpfads). Bei einem dynamisch änderbaren Parameter wird die Änderung auch auf den laufenden SAP Web Dispatcher angewendet.

Kryptographie ist die Wissenschaft der Verschlüsselung von Informationen. Warum ist dies ein wichtiges Thema in der Informationstechnologie? Das Standardprotokoll für die Übertragung von HTTP-Anfragen, TCP/IP, ist ein potentiell unsicherer Transportmechanismus. Jeder, der mit einem bestimmten Netzwerk verbunden ist, kann mit mehr oder weniger Aufwand und Wissen die übertragenen Pakete und deren Inhalt über dieses IP-Protokoll in diesem Netzwerk abhören. Durch die Anfälligkeit dieses Protokolls ist es notwendig, die übertragenen Daten selbst zu verschlüsseln. Zur Veranschaulichung beschreiben wir im folgenden einen möglichen Angriff auf das TCP/IP-Protokoll und die Daten, die über dieses Protokoll übertragen werden.

Im obigen Beispiel initiiert Alice (1) eine Kommunikation mit Bob und fordert Kundendaten von ihm an. Bob sammelt die angeforderten Daten und antwortet auf Alices Anfrage (2). Die gesamte Unterhaltung wurde von Mallory abgehört. Dieser weiß nun von den besprochenen Informationen (3).

In den Kontext der TCP/IP-Welt übertragen, steht Alice für einen Web-Browser, der zum Beispiel Daten über einen HTTP-Request anfordert, der über das TCP/IP-Protokoll übertragen wird. Der Server (hier durch Bob dargestellt) reagiert, und verschickt einige sensible Kundendaten über das TCP/IP-Protokoll vom Server an den Client. Mallory, ein Angreifer, befindet sich im gleichen Netzwerk und kann somit diese TCP/IP-Kommunikation abhören.

Die Lösung zur Sicherung dieser Kommunikation ist die Verschlüsselung der übertragenen Daten, so dass die Konversation nur für die an der Konversation Beteiligten verständlich, und somit für den Angreifer unverständlich ist.

Die Verschlüsselung basiert auf mathematischen Operationen. Daher muss ein Schlüssel zwischen den Kommunikationspartnern ausgetauscht werden, um eine Berechnungsbasis für die Verschlüsselung und die Entschlüsselung von Informationen bereitzustellen. Es gibt drei verschiedene Methoden, diese Schlüssel auszutauschen.

Symmetrische Verschlüsselung ist die klassische Methode zur Verschlüsselung und Entschlüsselung von Nachrichten. In diesem Fall teilen der Sender und Empfänger einer Nachricht ein „Geheimnis", das als geheimer Schlüssel bezeichnet wird. Mit diesem Schlüssel verschlüsselt der Sender die Nachricht. Der Empfänger verwendet diesen Schlüssel zum Entschlüsseln der Nachricht.

Das geteilte Geheimnis wird als geheimer Schlüssel (engl.: secret key) bezeichnet. Er besteht aus einem Wert einer bestimmten Länge, zum Beispiel 256 bit. Diese Verschlüsselungsalgorithmen sind weit verbreitet und werden in den meisten Web-Browsern und Web-Servern eingesetzt. Typische Algorithmen der symmetrischen Verschlüsselung sind unter anderem:

• Digital Encryption Standard (DES)

• Triple DES

• Advanced Encryption Standard (AES)

• International Data Encryption Algorithm (IDEA)

• RC4

• RC5

• Blowfish

Die asymmetrische Verschlüsselung verwendet einen anderen Algorithmus als die symmetrische Verschlüsselung. Bei der asymmetrischen Verschlüsselung wird ein Schlüsselpaar verwendet, das aus einem privaten Schlüssel (private key) und einem öffentlichen Schlüssel (public key) besteht. Diese Schlüssel gehören zusammen. Eine Nachricht, die mit einem öffentlichen Schlüssel verschlüsselt wurde, kann nur mit dem dazugehörigen privaten Schlüssel entschlüsselt werden. Der öffentliche Schlüssel kann veröffentlicht werden. Der Eigentümer des Schlüsselpaares veröffentlicht den öffentlichen Schlüssel und kann diesen nach Bedarf herausgeben. Der private Schlüssel muss geheim gehalten werden.

Der Sender der vertraulichen Nachricht verwendet den öffentlichen Schlüssel des Empfängers, um die Nachricht zu verschlüsseln. Nur der Empfänger kann dann mit dem privaten Schlüssel die Nachricht entschlüsseln. Ein typischer Public-Key-Verschlüsselungsalgorithmus ist

• RSA (Rivest, Shamir, Adleman),

• In: Diffie-Hellman.

Nachteile der Verschlüsselung mit öffentlichen Schlüsseln

• Langsamer als die symmetrische Verschlüsselung.

• Die Verschlüsselung ist nur in eine Richtung mit einem Schlüsselpaar möglich. Alice kann eine Nachricht verschlüsseln, die an Bob gesendet werden soll, aber nicht umgekehrt.

• Fall jedoch Alice auch über ein Schlüsselpaar verfügt, kann Bob ihr eine verschlüsselte Nachricht senden. Es gibt jedoch noch einen einfacheren Weg.

Hybride Verschlüsselung ist die Kombination beider, oben beschriebener, Verschlüsselungsmethoden. Der Hybrid-Verschlüsselungsprozess nutzt die Vorteile beider Prozesstypen. Zum besseren Verständnis beschreiben wir den Prozess an folgendem Beispiel.

Ablauf:

1. Der Client (Browser) kontaktiert den ICM-Prozess bzw. den SAP Web Dispatcher.

2. Der Anwendungsserver antwortet und sendet seinen öffentlichen Schlüssel.

3. Clientseitig wird ein geheimer Schlüssel angelegt und mit dem öffentlichen Schlüssel verschlüsselt, den der Server zuvor gesendet hat.

4. Der Client sendet den verschlüsselten geheimen Schlüssel zurück.

5. Auf dem Server wird der geheime Schlüssel mit dem privaten Schlüssel entschlüsselt. Nur der Server kann den empfangenen geheimen Schlüssel entschlüsseln, da er den privaten Schlüssel enthält, der für die Entschlüsselung erforderlich ist.

6. Die Kommunikationspartner führen einen "Handshake" durch; sie schütteln die Hände.

7. Die weitere Kommunikation zwischen dem Client und dem Server wird mit dem geheimen Schlüssel verschlüsselt.

Im ersten Teil dieser Lektion haben wir einen möglichen Angriff auf das Transportprotokoll beschrieben und beschrieben, was getan werden kann, um diese Kommunikation zu sichern. Was passiert jedoch, wenn Mallory die Kommunikation stört und vorgibt, Bob zu sein? Er kann unter Umständen sogar einen öffentlichen Schlüssel vorweisen, und Alice glaubhaft machen, dass dies Bobs Schlüssel ist. Die Frage ist, wie wir sicherstellen können, dass Alice wirklich mit Bob kommuniziert und daher der öffentliche Schlüssel, den sie erhalten hat, wirklich Bobs öffentlicher Schlüssel ist?

Dieses Problem wird auch von der Kryptographie abgedeckt, und wird als Authentifizierung bezeichnet. Authentifizierung findet normalerweise über die Benutzer-ID und das Passwort statt. Mit kryptografischen Mechanismen ist es jedoch möglich, Kommunikationspartner zu authentifizieren, indem überprüft wird, ob der Kommunikationspartner derjenige ist, den er vorgibt. Grundlage für die Authentifizierung von Kommunikationspartnern sind digitale Zertifikate.

Das digitale Zertifikat ist der "digitale Personalausweis" des Einzelnen im Internet. Im Vergleich zur „realen Welt" können digitale Zertifikate mit einem Reisepass verglichen werden, der Informationen über Eigentümer, Aussteller, Seriennummer und Gültigkeitszeitraum enthält. Das Format des Zertifikats wird durch den X.509-Standard für digitale Zertifikate festgelegt.

Unter einigen allgemeinen Informationen enthält das Zertifikat auch den öffentlichen Teil des Schlüsselpaars, während der private Schlüssel nicht im Zertifikat enthalten ist. Der private Schlüssel muss an einem sicheren Ort aufbewahrt werden. Das Zertifikat wird von der Zertifizierungsstelle (Certification Authority, CA) an eine Person oder einen Server vergeben. Durch die digitale Signatur des Zertifikats stellt die Zertifizierungsstelle sicher, dass der öffentliche Schlüssel, der zu einem privaten Schlüssel passt, einer bestimmten Person oder einem bestimmten Server gehört. Die Zertifizierungsstelle stellt somit sicher, dass das Zertifikat nicht „gefälscht" werden kann. Die Infrastruktur, die die Ausgabe und Verifizierung der Zertifikate verwaltet, wird als Public-Key-Infrastruktur (PKI) bezeichnet.

Beispiele bekannter Zertifizierungsstellen:

• Verisign Inc.

• TC Trust Center

Die Zertifizierung eines digitalen Zertifikats läuft z. B. wie folgt ab:

1. Auf dem Server wird ein Public-Key-Schlüsselpaar generiert.

2. Der öffentliche Schlüssel wird an die CA gesendet (sie wird als Certificate Signing Request oder CSR bezeichnet).

3. Die CA signiert den öffentlichen Schlüssel des Servers digital und sendet ihn zurück an den Anforderer.

4. Import der CSR-Antwort, des digital signierten Zertifikats, in den Server.

Verschiedene Zertifizierungsstellen verwenden unterschiedliche Richtlinien, wie die Identität einer Person oder eines Systems geprüft werden kann, bevor ein digitales Zertifikat ausgestellt wird.

Der Server sendet nun das digital signierte Zertifikat, das den öffentlichen Schlüssel enthält, an den Kommunikationspartner. Diese Art der Authentifizierung wird als Server-Authentifizierung bezeichnet. Aber wie kann der Kommunikationspartner sicherstellen, dass das digital signierte Zertifikat von einer vertrauenswürdigen CA signiert wird? Der Kommunikationspartner muss eine Vertrauensbeziehung zur CA haben, die das Zertifikat ausgestellt hat. Technisch kann dies erreicht werden, indem ein digitales Zertifikat der Einrichtung (CA) importiert wird, die das Zertifikat für den Server ausgestellt hat. Dies ist das sogenannte Root Zertifikat (Root Certificate). Die verbreitesten Root Zertifikate sind in den meisten Web-Browsern vorinstalliert.

den vorherigen Abschnitten lernten Sie die Grundlagen von Kryptographie, Authentifizierung und digitalen Zertifikaten kennen. Diese Technologien sind auch für die Sicherung der HTTP-Kommunikation von grundlegender Bedeutung. Secure Sockets Layer (SSL) ist ein transparentes Protokoll, das andere Protokolle mit Sicherheitsfunktionen ausstattet. SSL ist kein HTTP-spezifisches Protokoll, wird jedoch als Protokoll zwischen der TCP-Schicht und den Anwendungsprotokollen wie LDAP, SMTP, HTTP usw. eingesetzt. Ein HTTP-Anwendungsprotokoll, das mit SSL erweitert wurde, erkennen Sie an der Protokollidentifikation HTTPS in der URL.

SSL verwendet eine Hybrid-Verschlüsselungsmethode und stellt neben der Datenverschlüsselung die folgenden Authentifizierungsmechanismen bereit:

• Server-Authentifizierung

• Client-Authentifizierung

• Gegenseitige Authentifizierung

Um SSL für die Serverauthentifizierung zu verwenden, verfügt der ICM-Prozess bzw. SAP Web Dispatcher über ein privates und ein öffentliches Schlüsselpaar.

1. Alice kontaktiert den ICM-Prozess bzw. den SAP Web Dispatcher über einen Browser.

2. Der Applikationsserver antwortet und sendet seinen öffentlichen Schlüssel mit einer digital signierten Nachricht. Die Identität des Client-seitigen Servers wird durch die Überprüfung der Gültigkeit des Zertifikats geprüft. Das Zertifikat wird nur akzeptiert, wenn der Client der CA, die dieses Zertifikat ausgestellt hat, dem ICM-Prozess bzw. dem SAP Web Dispatcher vertraut. Dies geschieht über das Zertifizierungsstellen-Stammzertifikat.

3. Der geheime Schlüssel wird angelegt und mit dem öffentlichen Schlüssel verschlüsselt, den der Server zuvor gesendet hat.

4. Der Client sendet den verschlüsselten geheimen Schlüssel zurück.

5. Auf dem Server wird der geheime Schlüssel mit dem privaten Schlüssel entschlüsselt. Nur der Server kann den empfangenen geheimen Schlüssel entschlüsseln, da er den privaten Schlüssel enthält, der für die Entschlüsselung erforderlich ist.

6. Die Kommunikationspartner führen einen Handshake durch.

7. Die weitere Kommunikation zwischen dem Client und dem Server wird mit dem geheimen Schlüssel verschlüsselt.

Sie können SSL auch für Verbindungen mit einem zwischengeschalteten Server verwenden. Ein zwischengeschalteter Server kann ein Web-Proxy oder der SAP Web Dispatcher sein. Ein typisches Szenario ist, den zwischengeschalteten Server in der DMZ und den AS ABAP in der Intranet-Zone zu platzieren. Folgende Server werden für die Verwendung mit AS ABAP unterstützt:

• SAP Web Dispatcher

• Microsoft Internet Information Server (IIS) mit einem IIS-Proxymodul von SAP

• Andere Produkte (z.B. der Apache-Web-Server)

Der erste oben gezeigte Verbindungstyp verwendet SSL überhaupt nicht. Daher müssen Sie den Port nur auf HTTP setzen. Es ist keine zusätzliche Konfiguration erforderlich.

Beim zweiten Verbindungstyp wird der Request beim SAP Web Dispatcher beendet. Die eingehende Verbindung verwendet HTTP und die ausgehende Verbindung verwendet HTTPS. Daher müssen Sie den SAP Web Dispatcher als SSL-Client konfigurieren.

Beim dritten Verbindungstyp wird der Request beim SAP Web Dispatcher beendet. Die eingehende Verbindung verwendet HTTPS und die ausgehende Verbindung verwendet HTTP. Daher müssen Sie den SAP Web Dispatcher als SSL-Server konfigurieren.

Beim vierten Verbindungstyp wird der Request beim SAP Web Dispatcher beendet. Sowohl die eingehende als auch die ausgehende Verbindung verwenden HTTPS. Daher müssen Sie den SAP Web Dispatcher als SSL-Server und als SSL-Client konfigurieren.

Es wird nun darüber nachgedacht, wie der SAP Web Dispatcher in einer SSL-Serverrolle konfiguriert wird.

Wir empfehlen, die SSL-Unterstützung über das Web-Admin-UI des SAP Web Dispatchers zu konfigurieren.

Als allgemeine Übersicht sind die folgenden Schritte erforderlich, um den SAP Web Dispatcher für SSL zu konfigurieren, wenn die Verbindung beendet und SSL verwendet wird:

1. Legen Sie die persönlichen Sicherheitsumgebungen (PSE) und Zertifikatsanforderungen des SAP Web Dispatchers an. Legen Sie eine SSL-Server-PSE an, wenn die eingehenden Verbindungen SSL verwenden. Legen Sie eine SSL-Client-PSE an, wenn die ausgehenden Verbindungen SSL verwenden. Legen Sie beides an, wenn beide Verbindungen SSL verwenden.

   Informationen zum Anlegen einer SSL-Server-PSE mit Alternativname des Inhabers (SAN) finden Sie im SAP-Hinweis 2502649Zertifikate mit Alternativnamen des Inhabers (SAN) über die Web-Admin-Seite anlegen.

2. Führen Sie die folgenden Schritte für jede PSE aus, die Sie im vorherigen Schritt angelegt haben:

   1. Senden Sie die Zertifikatsanforderung(en) zum Signieren an eine CA.

   2. Importieren Sie die Zertifikatsantwort(en) in die PSE.

   3. Legen Sie Credentials für den SAP Web Dispatcher an.

3. Importieren Sie für ausgehende SSL-Verbindungen ein CA-Wurzelzertifikat in die SSL-Client-PSE des SAP Web Dispatchers. Verwenden Sie dasselbe CA-Wurzelzertifikat für die CA, die das SSL-Serverzertifikat an den AS-ABAP-Anwendungsserver ausgestellt hat.

4. Setzen Sie die Profilparameter entsprechend dem von Ihnen verwendeten Fall.

5. Starten Sie den SAP Web Dispatcher neu.

6. Führen Sie einen Verbindungstest durch.

Weitere Informationen finden Sie in der Online-Dokumentation für SAP NetWeaver bzw. ABAP-Plattform.

In einer einfachen Systemlandschaft befinden sich der AS ABAP und die Browser in der Regel im selben Netzwerk. In diesem Fall kann der Browser über seinen konfigurierten Namen direkt auf den AS-ABAP-Server zugreifen. Wenn der AS ABAP dagegen eine absolute URL für den Browser generieren muss, kann er seinen konfigurierten Namen verwenden, um die URL zu generieren.

In komplexeren Systemlandschaften wird ein Reverse-Proxy-Server, z.B. der SAP Web Dispatcher, im Netzwerk verwendet. Dies geschieht z.B., wenn der Reverse-Proxy-Server im Internet sichtbar ist und sich der AS ABAP hinter einer Firewall befindet. In diesem Fall verwendet der Browser bei der Kommunikation mit dem Server den Namen des Reverse-Proxy-Servers. Oder umgekehrt: Es ist nicht möglich, dass der AS ABAP seinen eigenen konfigurierten Namen verwendet, um absolute URLs zu generieren. Die URL muss den Namen und Port des Reverse-Proxy-Servers enthalten (d.h. den Namen und Port der Einheit, mit der der Browser kommuniziert). Über die Konfigurationstabelle HTTPURLLOC kann dann beschrieben werden, wie eine URL erzeugt werden soll.

Weitere Informationen finden Sie im SAP-Hinweis 750292 – BSP: URL-Generierung in einer Konfiguration von WebAS mit Web Dispatcher, der auch einen Link zur Online-Dokumentation enthält.

SAP Web Dispatcher ist eine SAP-Lösung zur Lastverteilung für HTTP(S)-Requests. Besteht ein SAP-System aus mehreren Instanzen, so nimmt der SAP Web Dispatcher die Anfragen vom Browser entgegen und leitet diese an den Applikationsserver weiter, der gerade die meiste Kapazität hat. Hierdurch vereinfacht sich die Administration, da es nur den einen Einstiegspunkt (IP-Adresse, HTTP(S)-Port usw.) zum SAP-System gibt.

Wenn der SAP Web Dispatcher SSL auch für die Verbindung zum AS-ABAP-System verwendet (Neuverschlüsselung), muss er auch über ein Schlüsselpaar verfügen, das für diese Verbindung verwendet werden kann. Diese Informationen werden in der SSL-Client-PSE gespeichert.

Sie haben verschiedene Möglichkeiten, eine Vertrauensbeziehung zwischen dem SAP Web Dispatcher und einem AS-ABAP-System herzustellen. Ein Ansatz besteht darin, dass Sie das SSL-Serverzertifikat aus dem AS-ABAP-System exportieren und in die Client-PSE des SAP Web Dispatcher importieren. Ein bequemer Ansatz ist jedoch, dass Sie über eine gemeinsame Certification Authority (CA) verfügen.

• Verwenden Sie diese CA, um das SSL-Serverzertifikat des AS ABAP zu signieren (Transaktion STRUST).

• Importieren Sie das Wurzelzertifikat derselben CA in die Client-PSE des SAP Web Dispatcher.

Ab SAP Web Dispatcher 7.53 können Sie die Vertrauensbeziehung mit einem AS-ABAP-basierten Backend-System vollständig auf der Web-Admin-UI einrichten (ein separater Download des entsprechenden Zertifikats ist nicht mehr erforderlich). Verwenden Sie dazu die Funktion auf der Web-Admin-UI, die unter <SID des SAP-Systems> → Monitor Application Servers → <Anwendungsserver-Menü (Spalte Name)> → Establish Trust verfügbar ist. Hier können Sie das Zertifikat auswählen, um die Vertrauensbeziehung herzustellen (Wurzelzertifikat, Ausstellerzertifikat(e) oder Peer-Zertifikat).

Weitere Informationen finden Sie im SAP Help Portal – Additional Content on How to Configure SAP Web Dispatcher to Trust Backend System SSL Certificate unter https://help.sap.com/docs/SUPPORT_CONTENT/si/3362959216.html.

Der SAP Web Dispatcher unterstützt mehrere sofort einsatzbereite SAP-(Backend-)Systeme (und Nicht-SAP-Web-Server). Sie müssen nicht für jedes System einen SAP Web Dispatcher einrichten, konfigurieren oder warten, sondern können einen gemeinsamen SAP Web Dispatcher für alle Systeme verwenden. Diese muss dann für alle angeschlossenen Systeme konfiguriert werden.

Sie können die Requests über einen der verschiedenen Mechanismen trennen oder eine Kombination von Mechanismen, die über Subparameter des Parameters wdisp/system konfiguriert wurden.

Hostname (Subparameter SRCVHOST)

Requests werden an das konfigurierte System weitergeleitet, wenn der Hostname in der URL mit dem in SRCVHOST angegebenen Hostnamen übereinstimmt.

URL-Pfadpräfix (Subparameter SRCURL)

Anfragen werden an das konfigurierte System weitergeleitet, wenn das URL-Pfadpräfix mit dem in SRCURL angegebenen URL-Pfadpräfix übereinstimmt.

Zugriffspunkt (IP-Adresse (oder Hostname) und Port) des SAP Web Dispatchers (Subparameter SRCSRV)

Requests werden an das konfigurierte System weitergeleitet, wenn die IP-Adresse und der Port des SAP Web Dispatchers, an dem der Request empfangen wurde, mit dem in SRCSRV angegebenen Zugriffspunkt übereinstimmen.

In den meisten Szenarien reichen SRCVHOST und SRCURL aus, um die Systemauswahl durchzuführen. Wenn die Systemselektion nicht über die oben aufgeführten Subparameter durchgeführt werden kann, ist es möglich, die Systemselektion im HTTP-Modifikations-Handler durchzuführen, indem Sie das Kopffeld X-SAP-WEBDISP-TARGET-SID setzen.

Fügen Sie für jedes Backend-System eine wdisp/system_<xx>-Zeile zum SAP-Web-Dispatcher-Profil hinzu. Beispiel:

wdisp/system_0 = SID=ECC, MSHOST=ms_ecc.wdf.sap.corp, MSPORT=8104, SRCVHOST=ecc.acme.com

wdisp/system_1 = SID=NWP, MSHOST=ms_nwp.wdf.sap.corp, MSPORT=8134, SRCVHOST=nwp.acme.com

Für jeden eingehenden Request prüft der SAP Web Dispatcher anhand der konfigurierten Kriterien und der Einstellung von wdisp/system_<xx>, in welches System der Request springen kann. Wenn die Kriterien von mehr als einem System erfüllt werden, wird das Verhalten durch den Parameter wdisp/system_flict_resolution bestimmt. Weitere Informationen und Beispiele finden Sie in der Online-Dokumentation.

Der SAP Web Dispatcher bietet weitere Funktionen, die in dieser Lektion nicht behandelt werden. Dazu gehören:

URL-Filterung

Sie können URLs definieren, die abgelehnt werden sollen, und dadurch den Zugriff auf Ihr System einschränken.

Web-Caching

Sie können den SAP Web Dispatcher als Web-Cache verwenden, um die Antwortzeiten zu verbessern und den Cache des Anwendungsservers zu sparen.

Umschreibung anfordern

Sie können HTTP-Requests (und -Responses) umschreiben, um z.B. HTTP-Header-Felder hinzuzufügen oder zu ändern.

SLD-Registrierung

Sie können den SAP Web Dispatcher so konfigurieren, dass er sich bei einem System Landscape Directory (SLD) registriert.

Der SAP Web Dispatcher kann vor Denial-of-Service-Angriffen (DoS-Angriffen) geschützt werden, indem die Anzahl der Verbindungen von einer einzelnen IP-Adresse begrenzt wird. Für jede aufgebaute Netzwerkverbindung wird die Anzahl der vorhandenen Verbindungen pro Client-IP-Adresse geprüft.

Um eine Übersicht über die Top-25-Consumer anzuzeigen, einschließlich Informationen über die Anzahl der aktiven Verbindungen und den Zeitpunkt der letzten Warnung und Ablehnung, rufen Sie die Administrations-UI des SAP Web Dispatcher auf, und navigieren Sie zu Core System → Client IP Top Consumer.

Der Profilparameter icm/client_ip_connection_limit enthält die Unterparameter WARN und REJECT, um die Grenzen für Verbindungen von einer einzelnen IP-Adresse anzugeben.

Die für diese Subparameter ermittelten Werte sind prozentuale Anteile der maximalen Anzahl von Verbindungen, die durch icm/max_conn vorgegeben wird. Die Standardwerte sind auf 90 und 100 gesetzt.

Wenn die Grenze für WARN überschritten wird, legt der SAP Web Dispatcher ein Systemprotokoll (Message-ID IMA) und einen Trace-Eintrag an. Um zu verhindern, dass das Systemprotokoll eine Überlastung der Einträge verursacht, wird nur ein Eintrag pro Minute angelegt.

Wenn die Grenze für REJECT erreicht ist, beendet der SAP Web Dispatcher die Verbindung und legt einen Systemprotokolleintrag an (Message-ID IMB).

Das Backend-System des Application Server ABAP kann vor Denial-of-Service-Angriffen (DoS-Angriffen) geschützt werden, indem die Anzahl der gleichzeitigen Requests begrenzt wird, die der SAP Web Dispatcher an das Backend-System weiterleitet. Auf diese Weise kann eine Überlastung aus einer nicht vertrauenswürdigen Request-Quelle vermieden werden. Die Anzahl der gleichzeitigen Requests ist ungefähr gleich der Anzahl der ABAP-Workprozesse, die mit der Verarbeitung dieser Requests belegt sind.

Um Informationen über ausstehende Requests zu überwachen, die noch nicht vom Backend-System beantwortet wurden, rufen Sie die Administrationsoberfläche des SAP Web Dispatcher auf und wählen Sie Dispatching Modul → Backend-System schwebende Request-Info.

Der Profilparameter wdisp/system enthält die Subparameter PENDING_REQUEST_LIMIT_WARN und PENDING_REQUEST_LIMIT_REJECT, um die Grenzen für gleichzeitige Requests in jedem Backend-System anzugeben. Die für diese Subparameter ermittelten Werte sind absolute Zahlen. Standardmäßig ist diese Funktion deaktiviert und muss vom Administrator konfiguriert werden.

Wenn das Limit für PENDING_REQUEST_LIMIT_WARN überschritten wird, legt der SAP Web Dispatcher sowohl ein Systemprotokoll (Message-ID IMC) als auch einen Trace-Eintrag an.

Wenn das Limit für PENDING_REQUEST_LIMIT_REJECT überschritten wird, gibt der SAP Web Dispatcher den Statuscode 503 Service Unavailable zurück und legt einen Systemprotokolleintrag an (Message-ID IMD).

Sie können die Ressourcen begrenzen, die von einem einzelnen Benutzer in Anwendungsserverinstanzen des AS ABAP verbraucht werden. Dies wird über den Parameter rdisp/user_resource_limit konfiguriert. Der Parameter hat auch die Subparameter WARN und REJECT mit den entsprechenden Werten. Bei diesen Werten handelt es sich um Prozentsätze. 100 steht für die gesamte Menge einer verfügbaren Ressource.

Wenn die WARN-Grenze erreicht ist, werden Syslog- und Trace-Einträge geschrieben (mit Überschwemmungsverhütung).

Wenn die REJECT-Grenze erreicht ist, wird ein Systemprotokolleintrag mit dem Schlüssel R2K geschrieben und die Sitzung abgebrochen.

• SAP S/4HANA 2023 Online-Dokumentation (Product Assistance), Bereich Unternehmenstechnologie → ABAP Platform → Application Server ABAP - Infrastruktur → Komponenten des Application Server ABAP → SAP Web Dispatcher

• SAP Help Portal – Additional Content on SAP Client-Server Technology (Bereich SAP Web Dispatcher) unter https://help.sap.com/docs/SUPPORT_CONTENT/si/3362958857.html

• SAP-Hinweis 538405SAP Web Dispatcher: Sammelhinweis

• SAP-Hinweis 552286Fehlerbehebung für den SAP Web Dispatcher

• SAP-Hinweis 1040325HTTP-Lastverteilung: Message-Server oder Web Dispatcher?

• SAP-Hinweis 908097SAP Web Dispatcher: Release, Installation, Patches, Dokumentation

• SAP-Hinweis 1708601Einr. Web Dispatcher SAP NetWeaver 7.1 und höher

• SAP-Hinweis 1282692Anmeldegruppen im SAP Web Dispatcher und J2EE-Stack anzeigen

• SAP-Hinweis 2007212Tuning SAP Web Dispatcher and ICM for high load

• SAP-Hinweis 2502649- Anlegen von Zertifikaten mit Alternativnamen des Inhabers (SAN) über die Web-Admin-Seite

• Öffnen Sie für Installationsleitfäden den Guide Finder for SAP NetWeaver and ABAP Platform unter https://help.sap.com/viewer/nwguidefinder, und suchen Sie nach dispatcher.