Installing and Configuring SAP Web Dispatcher

Objectives

After completing this lesson, you will be able to:
  • Describe basic functions of SAP Web Dispatcher
  • Perform an installation of SAP Web Dispatcher
  • Use the Web Administration interface
  • Perform the configuration of SSL
  • Perform the configuration of load balancing
  • Describe additional functions of SAP Web Dispatcher

Application Area of SAP Web Dispatcher

SAP Web Dispatcher is SAP's reverse proxy and software load balancer. It filters, routes and distributes HTTP(S) requests across the systems and application servers in an application landscape. It is free of charge for SAP customers, low in TCO, yet high in performance and perfectly supports SAP systems and their load balancing and request routing features out of the box.

SAP Web Dispatcher provides an easily consumable Web infrastructure solution for SAP solutions based on AS ABAP, AS Java or HANA XS or any other HTTP service.

SAP Web Dispatcher usage is not mandatory (except for selected scenarios). Since HTTP is a standardized protocol, other Web infrastructure products can be used as well. For example, a hardware load balancer may be of advantage if investments in such infrastructure are already made or if very high performance requirements have to be met.

Some SAP Web Dispatcher features are:

  • Load balancing for SAP and non-SAP systems. SAP Web Dispatcher can serve as a single access point for one or multiple back-end systems.
  • Automated configuration by fetching system configuration information from the back end system.
  • Reverse proxy with request filtering, caching, request header modification, redirects.
  • Request routing to back-end systems based on host, port or path (virtual hosting).
  • Single Sign-On for on-premise SAP Fiori Launchpad and integrated cloud services.

Some of the usage scenarios of SAP Web Dispatcher are as follows:

  • The Web applications are also to be used from the internet. The company network is protected by a Demilitarized Zone (DMZ) and the critical business processes run on servers that are not recognized on the internet. How can you avoid the need to place an SAP application server within the DMZ?
  • The SAP system in question consists of multiple application servers (instances) that are distributed across multiple virtual or physical hosts. However, the Web applications provided should run under a descriptive address; technical details such as server name and port number are to remain hidden to users.
  • Complex SAP Fiori landscapes may consist of one or more front-end servers and multiple back-end systems and possibly additional cloud services, like SAP Conversational AI. HTTP requests must be routed to one of these systems depending on URL properties of the request (host name, port, path, parameters).

Requirements such as these can be implemented using third-party products known as reverse proxies or Web switches. Although there are advantages, such as high throughput and implementation in close proximity to the hardware, they must be offset against the disadvantages of additional costs and restricted SAP integration.

SAP Web Dispatcher is a stand-alone program that you can run on a separate host or even on one of the application servers of an SAP system without depending on any additional software like a database.

Hint

The internal structure of SAP Web Dispatcher is very similar to the ICM process. When it comes to the operation of SAP Web Dispatcher, you will discover some analogies to the ICM environment.

Prerequisites for SAP Web Dispatcher

SAP Web Dispatcher ultimately forwards an HTTP(S) request to a specific application server instance belonging to a specific system. This section outlines the criteria by which it is performed.

An HTTP(S) request is processed in the following stages:

  1. First, SAP Web Dispatcher determines which system should be selected for a given HTTP request based on criteria like the URL hostname or path prefix.
  2. Then SAP Web Dispatcher performs additional tasks on the HTTP request like URL filtering, cache access, HTTP request rewriting.
  3. Load balancing is then carried out between application server instances of the selected system. After SAP Web Dispatcher has identified an application server instance, it forwards the request to the ICM of the relevant application server instance.

Metadata Exchange

SAP Web Dispatcher receives information about the application servers, which it needs for load distribution, from the message server and application servers. The following list presents types of information:

  • It gets server information (the list of servers that it can use for requests) from the message server.
  • It gets information about the logon groups and URL mapping from an ABAP application server.
  • SAP Web Dispatcher checks the availability of the application servers using ping requests to the application servers.

SAP Web Dispatcher obtains information about the application servers of the SAP system from the message server via HTTP(S). You can use SAP Web Dispatcher for AS ABAP systems, AS Java systems, HANA XS systems and SAP Cloud Platform systems in some scenarios.

The HTTP interface of the message server allows you to display information about the application server instances with a Web browser. To do so, enter the following URL:http(s)://<message server host>.<message server domain>:<message server http(s) port>/msgserver/text/logon?version=1.3.

Prerequisites

The prerequisites for operating the SAP Web Dispatcher are

  • The SAP Web Dispatcher is able to contact the HTTP port of the SAP message server.
  • The following ICF services are active:
    • /sap/public/icman
    • /sap/public/icf_info and all sub-services

Check Prerequisites for SAP Web Dispatcher

Business Example

Your company uses many Web browser-based functions offered by SAP S/4HANA.

As an administrator, you intend to install SAP Web Dispatcher and want to check the prerequisites.

Task 1: HTTP Port of ABAP Message Server

Steps

  1. In your SAP S/4HANA system, determine the HTTP port of the ABAP message server.

    1. Log on to your SAP system using the credentials of your course user that is provided by your instructor (for example user train-##).

    2. Start transaction SMMS.

    3. From the menu, choose Goto → Parameters → Display.

    4. Note the value of profile parameter ms/server_port_0.

Result

You know the host name and HTTP port of the ABAP message server of your SAP S/4HANA system. The port should be 81<ASCS>, where <ASCS> is the two-digit number of the ABAP central service instance.

Task 2: Activation of Relevant ICF Services

Steps

  1. In your SAP S/4HANA system, ensure that the following ICF services are active:

    • /sap/public/icman
    • /sap/public/icf_info and all sub-services

    1. Following the previous step, start transaction SICF.

    2. Keep all default values and choose Execute (F8).

    3. On the Define Services screen, expand default_host and navigate to the /sap/public/icman node.

    4. If this service is inactive (displayed in grey or blue), activate it by right-clicking icman and choosing Activate Service. In the popup, choose the left Yes button.

    5. On the Define Service screen, now expand default_host and navigate to the /sap/public/icf_info node.

    6. If any of the sub-services of icf_info is inactive (displayed in grey or blue), activate it by right-clicking it and choosing Activate Service. In the popup, choose the left Yes button.

Result

The ICF services required by SAP Web Dispatcher are active.

Task 3: Test a relevant ICF Service

Steps

  1. Test the ICF service /sap/public/icf_info/icr_groups. After the URL was launched in a Web browser, add the parameter version=2.4 to the (generated) URL.

    1. Following the previous step, with the right mouse button, click the icr_groups node (path /default_host/sap/public/icf_info/icr_groups) and choose Test Service.

    2. The ICF service is being launched in a Web browser – note that all (running) application servers are shown.

    3. In the Web browser, add version=2.4 to the (generated) URL and press enter.

      Note

      If the generated URL ends with the ICF service name (icr_groups), use a ? sign to add the parameter (URL ends with ?version=2.4).

      If the generated URL already includes a parameter (for example sap-client), use a & sign to add the parameter (URL ends with &version=2.4).

Result

You know the URL which is used by SAP Web Dispatcher to read metadata of your SAP S/4HANA system. Note that the web page includes data about logon groups and URL prefixes.

SAP Web Dispatcher Installation

SAP Web Dispatcher is backwards compatible. This means that the SAP Web Dispatcher release can be higher or the same as the SAP system (kernel) release. The patch level can also differ from the patch level of the back-end system.

SAP Note 908097 lists the allowed combinations of SAP Web Dispatcher releases and SAP system releases.

Different installation options are available for SAP Web Dispatcher:

Provide executable and profile

On the host on which SAP Web Dispatcher will be used, it is sufficient to provide the executable (name: sapwebdisp) and a profile file. The executable is the package sapwebdisp.sar that you can download for various platforms from the SAP Support Portal (area SAP Technology Components). In addition, you need a profile, typically named sapwebdisp.pfl. For a list of profile parameters, see the online documentation. Running the command sapwebdisp pf=<profile file> is sufficient to start SAP Web Dispatcher.

Hint

On servers based on Microsoft Windows, you can set up SAP Web Dispatcher as a Windows service with the command ntscmgr install sapwebdisp -b <program path>\sapwebdisp.exe -p "service pf=<profile file> <options>".

Provide executable and use the -bootstrap option

You can also start SAP Web Dispatcher without a profile file. For this bootstrap option (started with command sapwebdisp -bootstrap), the following steps are executed:

  1. If the sapwebdisp.pfl profile file does not exist, it is created based on interactive entries.

  2. If the icmauth.txt authorization file does not exist, it is created and a user is entered for Web Administration interface.

  3. SAP Web Dispatcher is started with the profile file created.

Running SWPM / SAPinst

The tools for installing and updating SAP products are delivered with the Software Logistics Toolset (SL Toolset), which is updated several times a year, so you get the latest improvements and updates in time. In this manner, the SL Toolset delivers software logistics tool improvements on a continuous basis, independent from the SAP application product shipments. The SL Toolset is delivered in Support Package Stacks.

Software Provisioning Manager (SWPM) is the successor of the product- and release-specific delivery of provisioning tools. It provides the latest SAPinst version with software provisioning services for several products and releases for all platforms, enabling you to profit directly from up-to-date procedures powered by a reliable tool available and used for years.

Meanwhile, two versions of Software Provisioning Manager are available:

  • Software Provisioning Manager 1.0
  • Software Provisioning Manager 2.0

Both versions can be used to install SAP Web Dispatcher.

In case you explicitly want to install the non-Unicode version of SAP Web Dispatcher, you have to use Software Provisioning Manager 1.0.

To download the latest SWPM, open https://support.sap.com/sltoolset and navigate to System Provisioning → Download Software Provisioning Manager → SOFTWARE PROVISIONING MGR 2.0 → SUPPORT PACKAGE PATCHES → <Platform>. For more information about SWPM, see SAP Help Portal – Additional Content on Software Provisioning Manager 1.0 and 2.0 at https://help.sap.com/docs/SUPPORT_CONTENT/sl/3362916978.html.

The SWPM-based installation of SAP Web Dispatcher requires the following SAP archives (.SAR files):

  • SAP Web Dispatcher

  • SAP Host Agent

To download the latest SAP Web Dispatcher archive, open https://me.sap.com/softwarecenter and navigate to Support Packages & Patches → By Category → SAP Technology Components → SAP Web Dispatcher → SAP Web Dispatcher <Release> → <Platform>.

To download the latest SAP Host Agent archive, open https://me.sap.com/softwarecenter and navigate to Support Packages & Patches → By Category → SAP Technology Components → SAP Host Agent → SAP Host Agent <Release> → <Platform>.

The sapinst executable can be launched with many command line options. To see all of them, enter sapinst -p.

The option to install an SAP Web Dispatcher is located at Generic Options → SAP Web Dispatcher → SAP Web Dispatcher (Unicode) (the path may vary, depending on the SWPM release).

SWPM offers two options for Parameter Mode, Typical or Custom. The figure lists dialogs of SWPM when being executed in Parameter Mode = Typical.

To access the installations guides for SAP Web Dispatcher, open the Guide Finder for SAP NetWeaver and ABAP Platform at https://help.sap.com/viewer/nwguidefinder and search for dispatcher. Note the proper operating systems and SWPM version.

Profile Parameters

For templates for the profile and parameter descriptions, see the online documentation. SAP Web Dispatcher must know the port at which it is to receive HTTP(s) requests on which host and with which HTTP(S) port it can access the message server (both is set using SAP Web Dispatcher profile parameter wdisp/system_<xx>).

Note

If metadata is to be exchanged through HTTPS, additional steps are required (see the online documentation).

Configuration Check

You can check the configuration of SAP Web Dispatcher to ensure that your settings will work when the Dispatcher is running. To do so, start SAP Web Dispatcher from the command line with the command: sapwebdisp pf=<profile> -checkconfig. This verifies the following items:

  • If the configuration of the maximum number of sockets in the Operating System permits the required number of configured connections.
  • If the information about the application servers is configured in a file and in the wdisp/server_info_location parameter. Check the syntax and semantics of this file.
  • If the information about the application servers is configured in the message server:
    • Test the connection to the HTTP port of the message server.
    • Check the data from the message server with the configured URL.
  • If the connection to all the application servers is found.
  • If the file is configured with the wdisp/group_info_location, do a syntactic/semantic check of the group file. Otherwise, check the data from an application server with the configured URL (/sap/public/icf_info/icr_groups). Check that the ICF nodes are activated.
  • If the file is configured with the wdisp/url_map_info_location, do a syntactic/semantic check of the group file. Otherwise, check the data from an application server with the configured URL (/sap/public/icf_info/icr_urlprefix). Check that the ICF nodes are activated.

Software Update

If you want to update your SAP Web Dispatcher installation, download the SAP Web Dispatcher archive (for the proper operating system and major release) at https://support.sap.com/swdc, path Software Downloads → Support Packages & Patches → By Category → SAP Technology Components → SAP Web Dispatcher → SAP Web Dispatcher <Release> → <Platform>. Unpack that file (by executing sapcar -xvf <sapwebdisp.sar file>) to the proper directory and (re)start SAP Web Dispatcher. Continue as described in SAP Note 908097 (the procedure is similar to a kernel update).

Hint

You can determine the current version of your SAP Web Dispatcher installation as follows:

  • By executing sapwebdisp -v

  • By analyzing the most recent developer trace file (by default, dev_webdisp)

  • By launching the "Version Info" dialog in SAP MC or SAP MMC

Install SAP Web Dispatcher

Business Example

Your company is planning to use SAP Fiori apps. To provide a unique URL for end-users to access SAP S/4HANA services in a secure way, you will install an SAP Web Dispatcher 7.93. Due to the expected load and as a fail-safe, you are planning to use multiple application server instances.

Note

In this exercise, when an object name or value contains ##, replace ## by the number your trainer assigned to you.

Task 1: Preparing the Installation

Steps

  1. Using an SSH connection in MobaXterm, log on to the operating system of your feature server. Use the virtual hostname fs<q|p>host.wdf.sap.corp and the operating system user install.

    1. On the WTS, launch the application MobaXterm.

    2. Within the MobaXterm main window, choose Session.

    3. In the Connection settings dialog, choose SSH.

    4. Enter the following:

      Remote host

      Q team: fsqhost.wdf.sap.corp

      P team: fsphost.wdf.sap.corp

      Specify usernameselect this option
      field right to Specify usernameinstall

    5. Keep all other settings unchanged and choose OK.

      In case of a Connexion to... dialog, select Do not show this message again and choose Accept.

    6. Enter the password of the user install. Your instructor will provide details.

      Hint

      There is no visual feedback while you are typing the password. After you entered the correct password, MobaXterm may ask if you want to store the password permanently. If you want to, you have to provide an arbitrary master password for MobaXterm (two times).

  2. Copy the latest SAP Web Dispatcher and SAP Host Agent archives offered on the training share below /kpstransfer/Maintenance/fsXhost/SAP_Web_Dispatcher to /install/SAPWebDisp##.

    1. You are still in the SSH session, logged on at the operating system level of your feature server.

    2. To create the target folder, enter mkdir -p /install/SAPWebDisp##.

      Note

      Remember to replace ## with the number your trainer assigned to you. All commands are case-sensitive.

    3. To copy the latest SAP Web Dispatcher archive, enter cp /kpstransfer/Maintenance/fsXhost/SAP_Web_Dispatcher/SAP_Web_Dispatcher_7.93/SAPWEBDISP_SP_<PL>-80008274.SAR /install/SAPWebDisp##/.

      Note

      Replace <PL> with the latest patch level offered. You can use the Tabulator key to complete your input (in case of unique path or file names).

    4. To copy the latest SAP Host Agent archive, enter cp /kpstransfer/Maintenance/fsXhost/SAP_Web_Dispatcher/SAP_Host_Agent_7.22/SAPHOSTAGENT<PL>_<PL>-80004822.SAR /install/SAPWebDisp##/.

      Note

      Replace <PL> with the latest patch level offered. You can use the Tabulator key to complete your input (in case of unique path or file names).

  3. Extract the latest SWPM 2.0 archive offered on the training share at /kpstransfer/Maintenance/fsXhost/SAP_Web_Dispatcher/SWPM_2.0 to /install/SWPM##.

    1. You are still in the SSH session, logged on at the operating system level of your feature server.

    2. To create the target folder, enter mkdir -p /install/SWPM##.

    3. To change to this target folder, enter cd /install/SWPM##.

    4. To extract the latest SWPM 2.0 archive to the current folder, enter SAPCAR -xf /kpstransfer/Maintenance/fsXhost/SAP_Web_Dispatcher/SWPM_2.0/SWPM20SP<PL>_0-80003424.SAR.

      Note

      Replace <PL> with the latest patch level offered. You can use the Tabulator key to complete your input (in case of unique path or file names).

    5. Keep the MobaXterm SSH session open.

  4. Determine the real hostname using the hostname command.

    1. You are still in the SSH session, logged on at the operating system level of your feature server.

    2. To get the real hostname, enter hostname.

    3. Result: the real hostnames are:

      • Q team: wdflbmt0104

      • P team: wdflbmt0107

  5. Launch the sapinst executable of your SWPM 2.0 using the following command line:

    ./sapinst SAPINST_USE_HOSTNAME=fs*host

    (where * stands for q or p, depending on your system allocation).

    1. You are still in the SSH session, logged on at the operating system level of your feature server.

    2. Ensure that you are in folder /install/SWPM##.

    3. To start the SWPM, enter the following command:

      • Q team: ./sapinst SAPINST_USE_HOSTNAME=fsqhost

      • P team: ./sapinst SAPINST_USE_HOSTNAME=fsphost

      Caution

      Make sure to enter SAPINST_USE_HOSTNAME using uppercase letters and the hostname in lowercase letters.

    4. Keep the MobaXterm SSH session open.

  6. Logon to the SWPM 2.0 using the following URL

    https://fs*host.wdf.sap.corp:4237/sapinst/docs/index.html

    and provide the credentials of the install user.

    1. On the WTS, start a web browser of your choice.

    2. Launch the following URL:

      • Q team: https://fsqhost.wdf.sap.corp:4237/sapinst/docs/index.html

      • P team: https://fsphost.wdf.sap.corp:4237/sapinst/docs/index.html

      In case that you receive a browser message regarding a certificate error, ignore that message and proceed to the given URL.

    3. To start the SAP Software Provisioning Manager UI, enter the credentials of the operating system user, which is install. Your instructor will provide details.

Task 2: Performing the Installation

Steps

  1. Perform an SAP Web Dispatcher installation using the following settings:

    FieldQ TeamP Team
    Parameter ModeTypical
    SAP System ID (SAPSID)WDQWDP
    SAP Mount Directorykeep /sapmnt
    Master PasswordSAPWebDisp##
    Package Path/install/SAPWebDisp##
    Message Server Hosts4qhost.wdf.sap.corps4phost.wdf.sap.corp
    SAP Back-End System IDS4QS4P
    Message Server HTTP Port81208130
    Cleanup of Operating System Usersdo not select this option
    Instance Number2030
    HTTPS Port4432044330

    1. In the Software Provisioning Manager browser window, select Generic Options → SAP Web Dispatcher → SAP Web Dispatcher (Unicode) and choose Next.

    2. In the Parameter Mode field, choose Typical and then Next.

    3. In the SAP System ID (SAPSID) field, enter the following:

      • Q team: WDQ

      • P team: WDP

      (as in the table above). Do not change the suggested value for SAP Mount Directory. When done, choose Next.

    4. In the Master Password field(s), enter SAPWebDisp## (twice) and choose Next.

    5. On the Software Package Browser (for SAP Web Dispatcher) screen, use the F4 value help of the field Package Path to provide the proper location for the SAP Web Dispatcher and SAP Host Agent SAR files. In the Package Path screen, mark the folder /install/SAPWebDisp## and choose OK. When done, choose Next.

    6. On the next screen, verify that the Status (in the table) changed to Available, then choose Next.

    7. On the Software Package Browser (for SAP Host Agent) screen, verify that the Status (in the table) is Available, then choose Next.

    8. On the Connecting SAP Web Dispatcher to a Message Server screen, enter the following:

      Message Server Host

      Q team: s4qhost.wdf.sap.corp

      P team: s4phost.wdf.sap.corp

      SAP Back-End System ID

      Q team: S4Q

      P team: S4P

      Message Server HTTP Port

      Q team: 8120

      P team: 8130

      When done, choose Next.

    9. On the Cleanup of Operating System Users screen, choose Next.

    10. On the Parameter Summary screen, choose Show Details (at the bottom).

    11. Select the sections

      • SAP Web Dispatcher Instance
      • SAP Web Dispatcher Parameters
      (you may have to scroll down) and choose Revise (at the bottom).

    12. On the SAP Web Dispatcher Instance screen, at the Instance Number field, enter the following:

      • Q team: 20

      • P team: 30

      Keep all other settings unchanged and choose Next.

    13. On the SAP Web Dispatcher Parameters screen, at the HTTPS Port field, enter the following:

      • Q team: 44320

      • P team: 44330

      Keep all other settings unchanged and choose Next.

    14. On the Parameter Summary screen, note all parameters. When you are fine with all settings, choose Next. This will start the installation.

      Note

      The installation runtime is about 5 minutes.

    15. On the final confirmation screen Service Completed, choose Ok.

    16. Close the Feedback to SAP popup (without providing any feedback).

    17. Choose Exit. This will stop the SWPM/SAPinst server.

    18. Close the browser which was used for the installation.

Result

You have installed an SAP Web Dispatcher using SWPM/SAPinst.

Task 3: Configuration Check

Steps

  1. Using an SSH connection in MobaXterm, log on to the operating system of your feature server. Use the virtual hostname fs<q|p>host.wdf.sap.corp and the operating system user <wdq|wdp>adm.

    1. Log on to the operating system of your feature server. As an SSH access is sufficient, here are the access steps:

      1. On your WTS, start MobaXterm (the first call takes a little while).
      2. Choose Session.
      3. Choose SSH.
      4. Provide Remote host (fs<q|p>host.wdf.sap.corp), select Specify username and enter user name (wd<q|p>adm). Choose OK.
      5. Enter the Password (your master password, which should be SAPWebDisp##).

  2. Check your SAP Web Dispatcher installation by executing the following command

    sapwebdisp pf=<profile> -checkconfig

    from the profile directory of your SAP Web Dispatcher installation.

    1. Within the SSH terminal window, execute the command cdpro to switch to the profile directory of your SAP Web Dispatcher installation (/usr/sap/<WDQ|WDP>/SYS/profile/).

    2. Within the SSH terminal window, execute the following command: sapwebdisp pf=<profile> -checkconfig.

      • Q team: sapwebdisp pf=WDQ_W20_fsqhost -checkconfig
      • P team: sapwebdisp pf=WDP_W30_fsphost -checkconfig

Result

The result of a detailed check of your SAP Web Dispatcher installation is being displayed. You may see warnings regarding the HTTPS connection to the application servers of your SAP system.

Web Administration Interface

SAP Web Dispatcher offers a browser-based Web Administration interface for administration and monitoring purposes. To use this, the following prerequisites must be observed:

  • Define the icm/HTTP/admin_<xx> parameter in the SAP Web Dispatcher profile. For example, icm/HTTP/admin_0 = PREFIX=/sap/wdisp/admin,DOCROOT=$(DIR DATA)$(DIR SEP)icmandir,AUTHFILE=$(icm/authfile),PORT=8008. The command sets the URL prefix for the administration to /sap/wdisp/admin and the path for some control files to ./admin

    Note

    Using this parameter, the access to the Web Administration interface can be further restricted to a port (for example, the SSL port), a local host name (for example, "localhost"), or an external host name (then the Web Administration interface can only be accessed from this host).

    You can also authenticate yourself for the Web Administration interface with a backend (ABAP) user using the AUTHFILE=backend option of this parameter. For details and restrictions , see SAP note 2011786 – ICM / Web Dispatcher Admin UI Authentication via Backend.

  • Specify this port with icm/server_port_<xx> as the inbound port.

  • Create an authorization file icmauth.txt with an administrative user and (hashed) password.

    Note

    Run wdispmon -a to check or modify the content of icmauth.txt.

  • Ensure that the directory specified by DOCROOT (after SAP Web Dispatcher has been started for the first time) contains the files for the Web Administration interface.

    Note

    You can also unpack the wdispadmin.SAR archive manually into a subdirectory with the name admin by calling sapcar -xvf wdispadmin.SAR.

Functions of the Web Administration Interface

The following list shows the Web Administration interface functions:

  • SAP Web Dispatcher monitoring
  • Display parameter settings
  • Statistics
  • Evaluation of trace files
  • User administration
  • Maintenance mode

Enter the Web Administration interface using the following URL:

http(s)://<SAP Web Disp host and domain>:<SAP Web Disp admin port>/<admin prefix>

The <Admin prefix> section is defined through the assignment for PREFIX of the profile parameter icm/HTTP/admin_<xx>; the default value is/sap/wdisp/admin.

Note

For security reasons, use the HTTPS protocol for administration. If you use HTTP, administrator passwords are transferred without encryption and can be tapped.

Additionally, implement the option to bound SAP Web Dispatcher Web Administration to a dedicated port and localhost only.

Once you have logged on successfully, the administration and monitoring interface displays. It is divided into a navigation area (left side) and a detail area (right side).

Note

You can also monitor and administrate SAP Web Dispatcher with the wdispmon command line program (the usage is similar to the icmon command line tool.

Work with the Web Administration Interface

Business Example

Your company uses many Web browser-based functions offered by SAP S/4HANA.

As an administrator, you want to launch and use the Web Administration interface of SAP Web Dispatcher.

Task 1: Explore Settings for the Web Administration Interface

Steps

  1. Determine the prefix for the Web Administration interface (via SAP Web Dispatcher profile parameter icm/HTTP/admin_0, part PREFIX).

    1. Following the previous exercise concerning the installation of SAP Web Dispatcher, continue working at operating system level of your feature server host.

    2. Open the SAP Web Dispatcher instance profile with a text editor of your choice. It is located at /usr/sap/<WDQ|WDP>/SYS/profile/.

    3. Note the value of parameter icm/HTTP/admin_0, part PREFIX.

    Result

    The default prefix for the Web Administration interface is /sap/wdisp/admin.

  2. Determine the authentication file for the Web Administration interface (via SAP Web Dispatcher profile parameter icm/HTTP/admin_0, part AUTHFILE).

    1. Continue to analyze the SAP Web Dispatcher instance profile.

    2. Note the value of parameter icm/HTTP/admin_0, part AUTHFILE.

    Result

    The default authentication file for the Web Administration interface is referring to the value of icm/authfile.

    Note

    By default, icm/authfile is set to icmauth.txt.

  3. Determine the generated user for the Web Administration interface (via the authentication file for the Web Administration interface).

    Caution

    Do not change the content of that file!

    1. Continue working on operating system level of your feature server host.

    2. Open the Windows File Explorer.

    3. Navigate to the authentication file for the Web Administration interface (/usr/sap/<WDQ|WDP>/SYS/global/security/data/icmauth.txt).

    4. Open that file with a text editor of your choice.

      Result

      The generated user for the Web Administration interface is webadm.

Result

You are prepared to launch the Web Administration interface of SAP Web Dispatcher.

Task 2: Launch the Web Administration Interface

Steps

  1. Launch SAP Web Dispatcher Web Administration interface and log on using the generated webadm user.

    1. Following the previous task, minimize the Remote Desktop window to switch back to the WTS.

    2. Open a Web browser of your choice.

    3. Enter the following URL https://<SAP Web Disp host name>.<SAP Web Disp domain>:<SAP Web Disp HTTPS admin port>/<web admin prefix>, that is:

      • Q team: https://fsqhost.wdf.sap.corp:44320/sap/wdisp/admin
      • P team: https://fsphost.wdf.sap.corp:44330/sap/wdisp/admin

      Note

      You may also use the Web browser favorite/bookmark prepared at
      • Q team: 20 Quality Assurance → fsqhost → 20 WDQ SAP Web Dispatcher Administration
      • P team: 30 Production → fsphost → 30 WDP SAP Web Dispatcher Administration

    4. In case that you receive a Web browser message regarding a security issue, choose Advanced → Continue to fs<q|p>host.wdf.sap.corp (unsafe) (the specific path depends on the Web browser).

    5. To log on, enter webadm as the username and SAPWebDisp## as the password.

      Note

      Both user name and the password are case-sensitive.

  2. Determine the release and patch level of your SAP Web Dispatcher.

    1. In the menu on the left hand side, choose Core System → Release Information.

    2. Note the output in the details area at the right (kernel information area).

  3. Open the trace file of your SAP Web Dispatcher.

    1. Choose Core System → Trace.

    2. Note the output in the details area at the right.

      You should see error messages similar to "Failed to verify peer certificate. Peer not trusted." and warnings similar to "Failed to read group info" within the trace – SSL configuration is required to resolve this.

Task 3: User Management for the Web Administration Interface

Steps

  1. Within the Web Administration interface, create a display-only user display with the password SAPWebDisp##.

    1. Choose HTTP Handler → Admin Handler.

    2. In the details area at the right, choose Edit Users.

    3. Choose Add User.

    4. For Name, enter display. As Password, enter SAPWebDisp## (twice). Keep all other fields unchanged and choose Save.

    5. Choose Back.

  2. Launch the Web Administration interface with the user display.

    1. At WTS level, start a different Web browser (or open an incognito window of the Web browser you have used for the last step).

    2. Enter the following URL https://<SAP Web Disp host name>.<SAP Web Disp domain>:<SAP Web Disp HTTPS admin port>/<web admin prefix>, that is:

      • Q team: https://fsqhost.wdf.sap.corp:44320/sap/wdisp/admin
      • P team: https://fsphost.wdf.sap.corp:44330/sap/wdisp/admin

    3. To log on, enter display as the username and SAPWebDisp## as the password.

    4. Navigate to some areas and note the (restricted) change options. Can this user shutdown SAP Web Dispatcher? Can this user create additional users?

  3. Optional: Use the wdispmon program to create another administration user wdadmin## with the password SAPWebDisp##.

    Note

    We do not want to re-logon to the feature server using the <SAP Web Disp SID>adm operating system user and therefore provide full paths for all files.

    1. Log on to the operating system of your feature server. As an SSH access is sufficient, here are the access steps:

      1. On your WTS, start MobaXterm (the first call takes a little while).
      2. Choose Session.
      3. Choose SSH.
      4. Provide Remote host (fs<q|p>host.wdf.sap.corp), select Specify username and enter user name (wd<q|p>adm). Choose OK.
      5. Enter the Password (your master password, which should be SAPWebDisp##).

    2. Within the SSH terminal window, execute the command cdpro to switch to the profile directory of your SAP Web Dispatcher installation (/usr/sap/<WDQ|WDP>/SYS/profile/).

    3. Within the SSH terminal window, execute the following command: wdispmon pf=<profile>.

      • Q team: wdispmon pf=WDQ_W20_fsqhost
      • P team: wdispmon pf=WDP_W30_fsphost

    4. Enter m for the menu, then press the Enter key on your keyboard.

    5. Enter a followed by Enter to maintain the authentication file.

    6. Press Enter to confirm the default file name icmauth.txt.

    7. Press l followed by Enter to get a list of users stored. Confirm the list with Enter.

    8. Press a followed by Enter to add a user to the set.

    9. Enter the data from the following table, then press Enter again.

      FieldValue
      User namewdadmin##
      (Re-)Enter PasswordSuggestion: SAPWebDisp##
      Group nameadmin
      Subject value of client certLeave empty

    10. Press l followed by Enter again to get a list of users stored. Confirm the list with Enter.

    11. Press s followed by Enter to save your changes. Confirm again with Enter.

    12. Press q followed by Enter to quit the program.

    13. Back on WTS, launch the Web Administration interface again and log on with the new user.

      Note

      You may have to open a new Web browser session. Alternatively, choose another Web browser. Again, use the following URL https://<SAP Web Disp host name>.<SAP Web Disp domain>:<SAP Web Disp HTTPS admin port>/<web admin prefix>, that is:

      • Q team: https://fsqhost.wdf.sap.corp:44320/sap/wdisp/admin
      • P team: https://fsphost.wdf.sap.corp:44330/sap/wdisp/admin

Set a Parameter for SAP Web Dispatcher

Steps

  1. Using the Web Administration interface, determine the current value of the SAP Web Dispatcher parameter icm/HTTP/max_request_size_KB.

    1. Following the previous exercise on the Web Administration interface, continue working in the Web Administration interface with an administrative user (see the previous exercise for details).

    2. Choose Core System → Parameters.

    3. On the Settings tab, locate the parameter icm/HTTP/max_request_size_KB and note its value.

  2. Using the Web Administration interface, change the value of the SAP Web Dispatcher parameter icm/HTTP/max_request_size_KB permanently to 204800.

    1. Following the previous step, in the Profile Parameters view, choose Edit Parameters.

    2. Below Change Parameter, as Name, enter icm/HTTP/max_request_size_KB.

    3. Choose Get Value to get a description and the current value.

    4. For Value, enter 204800.

    5. Choose Change Value Permanently.

    6. For the Confirm operation question, choose Yes.

    7. For the Information message, choose Back.

    8. Back on the Settings tab, verify the changed value of parameter icm/HTTP/max_request_size_KB.

  3. Optional: Open the instance profile of your SAP Web Dispatcher and note the very last entry.

    1. Log on to the operating system of your feature server. As an SSH access is sufficient, here are the access steps:

      1. On your WTS, start MobaXterm (the first call takes a little while).
      2. Choose Session.
      3. Choose SSH.
      4. Provide Remote host (fs<q|p>host.wdf.sap.corp), select Specify username (and enter user wd<q|p>adm). Choose OK.
      5. Enter the Password (your master password, which should be SAPWebDisp##).

    2. Within the SSH terminal window, execute the command cdpro to switch to the profile directory of your SAP Web Dispatcher installation (/usr/sap/<WDQ|WDP>/SYS/profile/).

    3. Open the SAP Web Dispatcher instance profile with a text editor of your choice (for example using the less command:

      • Q team: less WDQ_W20_fsqhost
      • P team: less WDP_W30_fsphost

    4. The parameter icm/HTTP/max_request_size_KB should appear at the very bottom of that file. In addition, a new backup file was created in the backup subdirectory.

      Hint

      Press q to end the output of the less command.

Cryptography Fundamentals

Introducing Cryptography

Cryptography is the science of encrypting information. Why is this a very important topic in today's IT world? The standard protocol used for transporting http requests, TCP/IP, is a potentially insecure transport mechanism. Everyone connected to a specific network is able, with more or less effort and knowledge, to listen to the packages and its content transferred with the IP protocol in that network. This vulnerable protocol makes it necessary to encrypt the transferred data itself. For a better understanding we describe here a possible attack against the TCP/IP protocol and the data transferred with this protocol.

In the above example, Alice (1) initiates a communication with Bob and requests some data about customers from him. Bob gathers the requested data and responds to Alice's request (2). The entire exchange is eavesdropped by Mallory. He now knows about the information that was discussed (3).

In the context of TCP/IP, Alice (stands for a Web browser), for example, requests some data via an http request that is transferred via the TCP/IP protocol. The server (here represented by Bob) responds and transfers some sensitive customer data from the server to the client via the TCP/IP protocol. Mallory, an attacker, is on the same network and therefore is able to eavesdrop on this TCP/IP communication.

The solution for securing this communication is the encryption of the transferred data; this involves making the conversation impossible for the attacker to understand but making it understandable to the participants involved in the conversation only.

Encryption Methods

Encryption itself is based on mathematical operations. A key therefore has to be exchanged between the communication partners in order to have a computable basis for encrypting and decrypting information. There are three different methods for exchanging these keys.

Symmetric Key Encryption is the classical cryptography method for encrypting and decrypting messages. In this case, both the sender and receiver of a message share a "secret" called a secret key. The sender uses this key to encrypt the message. The receiver also uses this key to decrypt the message.

The shared secret is called a secret key. It consists of a value of a certain length, 256 bits for example. These encryption algorithms are in widespread use and are employed in most Web browsers and Web servers. Typical Symmetric Key Encryption Algorithms include:

  • Digital Encryption Standard (DES)

  • Triple DES

  • Advanced Encryption Standard (AES)

  • International Data Encryption Algorithm (IDEA)

  • RC4

  • RC5

  • Blowfish

Asymmetric Key Encryption uses a different algorithm than Symmetric Key Encryption. Asymmetric Key Encryption uses a key pair that consists of a private and a public key. These keys belong to each other. A message that is encrypted with the public key can only be decrypted with the matching private key. The public key can be made public. The owner of the key pair "publishes" the public key and can distribute it as required. The private key must be kept secret.

The person who is sending a confidential message uses the recipient‘s public key to encrypt the message. Only the recipient can then decrypt the message using his or her private key. A typical public key encryption algorithms is

  • RSA (Rivest, Shamir, Adleman),

  • Diffie-Hellman.

Disadvantages of Public Key Encryption:

  • It is slower than Symmetrical Key Encryption.

  • Encryption is only possible in one direction with a single key pair. Alice can encrypt a message to send to Bob, but not the other way round.

  • If Alice also has a key pair, then Bob can send her an encrypted message. However, there is an easier way.

Hybrid Encryption Process is the combination of both above explained encryption processes. The Hybrid Encryption Process make use of the advantages of both process types. For the better understanding we describe this process in the following example.

Process:

  1. The client (browser) contacts the ICM process respectively SAP Web Dispatcher.

  2. The Application Server responds and sends its Public Key.

  3. Client-side a Secret Key is created and encrypted with the Public Key the server sent before.

  4. The client sends back the encrypted Secret Key.

  5. On the server the Secret Key is decrypted using the Private Key. Only the server can decrypt the received Secret Key because it holds the Private Key which is necessary for the decryption.

  6. The communication partners perform a "Handshake"; they shake hands.

  7. Further communication between the client and the server is encrypted using the Secret Key.

Authentication and Digital Signatures

In the first part of this lesson we described a possible attack on the transport protocol and what can be done to secure this communication. But what happens if Mallory interferes with the communication and pretends to be Bob? He may even provide Alice a public key, saying that is Bob's key. The question is how can we make sure that Alice is really communicating with Bob and therefore the public key she received is really Bob's public key?

The problem is also covered by cryptography and is called Authentication. Authentication normally takes place using the user ID and password. But with cryptographic mechanisms it is possible to authenticate communication partners, by means of verifying that the communication partner is the one she or he pretends to be. The basis for the authentication of communication partners are Digital Certificates.

Understanding Digital Certificates and Digital Signatures

The digital certificate is the individual's "digital identity card" on the Internet. Compared to the "real world", digital certificates can be compared to a passport which contains information about owner, issuer, serial number, and validity period. The format of the certificate is specified by the X.509 standard for digital certificates.

Beneath some general information the certificate contains also the public part of the key pair whereas the private key is not included in the certificate. The private key must be kept in a safe place. The certificate is issued to a person or server by an authorized entity called a Certification Authority (CA). The CA ensures by digitally signing the certificate that the public key, which matches to a private key, belongs to a specific person or server. Thus, the CA ensures that the certificate cannot be "faked". The complete infrastructure that manages the issue and verification of certificates is called the Public Key Infrastructure (PKI).

Examples of well-known Certification Authorities:

  • Verisign Inc.

  • TC Trust Center

The certification of digital certificates is performed, for example, as follows:

  1. A public and private key pair is generated on the server.

  2. The public key is sent to the CA (it is called a Certificate Signing Request, or CSR).

  3. The CA digitally signs the server's public key and sends it back to the requestor.

  4. Import of the CSR response, the digitally signed certificate, into the server.

Different CAs use different policies, on how to check the identity of a person or system, before issuing a digital certificate.

The server is now sending the digitally signed certificate, which includes the public key, to the communication partner. This kind of authentication is called Server Authentication. But how can the communication partner ensure that the digitally signed certificate is signed from a trusted CA? The communication partner has to have a trust relationship to the CA which issued the certificate. Technically this can be achieved by importing a digital certificate of the institution (CA) issued the certificate for the server. This is the so-called root certificate. The most common root certificates are pre-installed in most Web browsers.

Securing HTTP communication using Secure Socket Layer (SSL)

In the previous sections you learned the fundamentals of Cryptography, Authentication and Digital Certificates. These technologies are also fundamental to securing the HTTP communication. Secure Socket Layer (SSL) is a transparent protocol enhancing other protocols having no security functionalities. SSL is not an HTTP-specific protocol but a protocol used between the TCP layer and application protocols like LDAP, SMTP, HTTP and so on. An HTTP application protocol that has been extended by SSL has the protocol identification HTTPS in the URL.

Hint

To be more precise, SAP Web Dispatcher (and the ICM) supports Transport Layer Security (TLS) which is the successor of SSL. In fact, TLS is a cryptographic protocol designed to provide communications security over a computer network, successor of Secure Socket Layer (SSL). But as – at least up to now – the term SSL is more common than TLS, this lesson (an the online documentation) still uses the term SSL instead.

SSL uses a Hybrid Encryption method and provides besides data encryption the following authentication mechanisms:

  • Server authentication

  • Client authentication

  • Mutual Authentication

To use SSL for server authentication, the ICM process respectively SAP Web Dispatcher possesses a private and public key pair.

  1. Alice contacts the ICM process respectively SAP Web Dispatcher using a browser.

  2. The Application Server responds and sends its Public Key with a digitally-signed message. The client-side server's identity is verified by checking the validity of the certificate. The certificate is only accepted if the client trusts the CA that issued that certificate to the ICM process respectively SAP Web Dispatcher. This is done with the CA root certificate.

  3. The Secret Key is created and encrypted with the Public Key the server sent previously.

  4. The client sends back the encrypted Secret Key.

  5. On the server the Secret Key is decrypted using the Private Key. Only the server can decrypt the received Secret Key because it holds the Private Key that is necessary for the decrypting.

  6. The communication partners perform a handshake.

  7. Further communication between the client and the server is encrypted using the Secret Key.

Using SSL with an Intermediary Server

You can also use SSL for connections where an intermediary server is used. An intermediary server may be a Web proxy or the SAP Web Dispatcher. A typical scenario is to place the intermediary server in the DMZ and the AS ABAP in the intranet zone. The servers that are supported for use with AS ABAP are:

  • SAP Web Dispatcher

  • Microsoft Internet Information Server (IIS) with an IIS proxy module from SAP

  • Other products (for example, the Apache Web Server)

The first connection type shown above does not use SSL at all. Therefore, you only need to set the port to HTTP. No extra configuration is needed.

For the second connection type, the request is terminated at SAP Web Dispatcher. The incoming connection uses HTTP and the outgoing connection uses HTTPS. Therefore, you must configure SAP Web Dispatcher as an SSL client.

For the third connection type, the request is terminated at SAP Web Dispatcher. The incoming connection uses HTTPS and the outgoing connection uses HTTP. Therefore, you must configure SAP Web Dispatcher as an SSL server.

For the fourth connection type, the request is terminated at SAP Web Dispatcher. Both the incoming connection and the outgoing connection use HTTPS. Therefore, you must configure SAP Web Dispatcher as an SSL server and an SSL client.

SAP Web Dispatcher in SSL Server Role

We will now consider how to configure SAP Web Dispatcher in an SSL server role.

We recommend that you use the Web Admin UI of SAP Web Dispatcher to configure SSL support.

As a high-level overview, these are the required steps to configure SAP Web Dispatcher for SSL when the connection is terminated and SSL is used:

  1. Create the SAP Web Dispatcher's Personal Security Environments (PSE(s)) and certificate request(s). Create an SSL server PSE if the incoming connections use SSL. Create an SSL client PSE if the outgoing connections use SSL. Create both if both connections use SSL.

    To create an SSL server PSE with Subject Alternative Name (SAN), refer to SAP Note 2502649Creating certificates with Subject Alternative Name (SAN) through the Web Admin page.

  2. Perform the following steps for each of the PSEs that you created in the previous step:

    1. Send the certificate request(s) to a CA to be signed.

    2. Import the certificate request response(s) into the PSE.

    3. Create credentials for SAP Web Dispatcher.

  3. For SSL outbound connections, import a CA root certificate into the SSL client PSE of SAP Web Dispatcher. Use the same CA root certificate for the CA that issued the SSL server certificate to the AS ABAP application server.

  4. Set the profile parameters according to the case you are using.

  5. Restart SAP Web Dispatcher.

  6. Test the connection.

For details, see the online documentation for SAP NetWeaver resp. ABAP Platform.

Addendum: URL Generation in an AS ABAP – SAP Web Dispatcher Configuration

In a simple system landscape the AS ABAP and the browsers are usually located in the same network. In this case, the browser can access the AS ABAP server directly using its configured name. Conversely, if the AS ABAP has to generate an absolute URL for the browser, it can use its configured name to generate the URL.

In more complex system landscapes a reverse proxy server, for instance, the SAP Web Dispatcher, is used in the network. This happens, for example, if the reverse proxy server is visible in the Internet and the AS ABAP is located behind a firewall. In this case the browser uses the name of the reverse proxy server when it is communicating with the server. Or the other way around: it is not possible for the AS ABAP to use its own configured name to generate absolute URLs. The URL must contain the name and port of the reverse proxy server (that is, the name and port of the unit with which the browser communicates). The configuration table HTTPURLLOC can then be used to describe how a URL is to be generated.

For more information, see SAP Note 750292 – BSP: URL Generation in a config of WebAS with Web Dispatcher which also contains a link to the online documentation.

SAP Web Dispatcher

SAP Web Dispatcher is a SAP solution for load distribution for HTTP(S) requests. If an SAP system consists of multiple instances, the SAP Web Dispatcher receives the requests from the browser and forwards them to the application server that currently has most capacity. This simplifies administration since there is only one entry point (IP address, HTTP(S) port, and so on) to the SAP system.

Enable HTTPS between the Web Browser and SAP Web Dispatcher

Business Example

Your company is planning to use SAP Fiori apps. To provide a unique URL for end users to access SAP S/4HANA services in a secure way, you have already installed an SAP Web Dispatcher. Now you want to configure SAP Web Dispatcher for SSL.

Note

In this exercise, when an object name or value contains ##, replace ## by the number your trainer assigned to you.

Task 1: Launch the Web Admin UI of SAP Web Dispatcher

Steps

  1. Open and log on to the Web Admin UI of your SAP Web Dispatcher (at WTS level).

    1. Make sure that you are on WTS level. If necessary, minimize the Remote Desktop Connection window to return to the WTS.

    2. Open a web browser of your choice.

    3. Enter the following URL: https://<full qualified SAP Web Dispatcher hostname>:443$$/sap/wdisp/admin where $$ is the SAP Web Dispatcher instance number.

      • Q team: https://fsqhost.wdf.sap.corp:44320/sap/wdisp/admin

      • P team: https://fsphost.wdf.sap.corp:44330/sap/wdisp/admin

      Note

      You may also use the Web browser favorite/bookmark prepared at
      • Q team: 20 Quality Assurance → fsqhost → 20 WDQ SAP Web Dispatcher Administration
      • P team: 30 Production → fsphost → 30 WDP SAP Web Dispatcher Administration

    4. In the case of a certificate-related security warning, ignore it and proceed in the same way as you did in a previous exercise.

    5. At the SAP Web Dispatcher logon screen, provide the following: Usernamewebadm, and your master Password (which should be SAPWebDisp##).

Result

You are logged on to the Web Admin UI of SAP Web Dispatcher with an administrative user.

Task 2: Create and Sign a Key Pair for SSL — Server

Steps

  1. Open the SAP Web Dispatcher server PSE (view SAPSSLS.pse). Recreate this PSE using the following Distinguished Name:

    • Q team: DNS=wdflbmt0104.wdf.sap.corp, CN=fsqhost.wdf.sap.corp
    • P team: DNS=wdflbmt0107.wdf.sap.corp, CN=fsphost.wdf.sap.corp
    The value of DNS will be propagated to Subject Alternative Name, which many web browsers require.

    1. Following the previous step, within the Web Admin UI, navigate to SSL and Trust Configuration → PSE Management.

    2. Ensure that at Manage PSE, the option SAPSSLS.pse is selected.

    3. Choose Recreate PSE.

    4. As Distinguished Name, enter

      • Q team: DNS=wdflbmt0104.wdf.sap.corp, CN=fsqhost.wdf.sap.corp
      • P team: DNS=wdflbmt0107.wdf.sap.corp, CN=fsphost.wdf.sap.corp

    5. Keep all other settings unchanged and choose Create.

    6. To ensure that the changed certificate is being used for your connection, complete the following five steps:

      1. Log off from the Web Admin UI (note the Logout icon at the top right).
      2. Close your Web browser window.
      3. Start the Web browser again.
      4. Launch the Web Admin UI again (for the URL: see above).
      5. Log on to the Web Admin UI (using again the credentials of the webadm user).

  2. Create a CA request, sign it using the SAP Secure Login Server hosted on the SMJ system and import the response.

    Here are some hints on the SAP Secure Login Server acting as CA in this training:

    • SAP Secure Login Administration Console (SLAC) URL: https://smhost.wdf.sap.corp:59101/slac
    • Path Certificate Management → Sign certificate requests
    • Certificate Template: SSL Server Template
    • Issuer: SAP Training SSL Sub CA
    • Certificate Response Type: PKCS#7

    1. Within the Web Admin UI, navigate to SSL and Trust Configuration → PSE Management.

    2. Ensure that at Manage PSE the option SAPSSLS.pse is selected.

    3. Choose Create CA Request.

    4. Select the complete CA Request (including the lines with the ----- signs) and save it in your clipboard.

    5. To launch the Secure Login Administration Console (SLAC), open the following URL https://smhost.wdf.sap.corp:59101/slac in a new Web browser window or tab.

      Note

      You may also use the Web browser favorite/bookmark prepared at 80 Application Lifecycle Management → smhost → 90 SMJ Secure Login Administration Console.

    6. When asked for credentials, provide the logon data of your train-## user (in client 100 of system SMA, to which the UME of system SMJ is connected).

    7. Within the SLAC, navigate to Certificate Management → Sign certificate requests.

    8. Paste the CA Request (contents of your clipboard) into the Encoded Certificate Request field.

    9. Choose Show Certificate Request.

    10. Adjust the following settings (keep the other settings unchanged):

      • End Validity: increase the suggested value (for example to one year from today)

      • Certificate Template: choose SSL Server Template

      • Issuer: choose SAP Training SSL Sub CA

      • Certificate Response Type: choose PKCS#7

    11. When you are done, choose Sign Certificate.

    12. Select the complete CA Response (including the lines with the ----- signs) and save it in your clipboard.

      Hint

      In case of issues, you may also Download the certificate response to a file.

    13. Switch back to the Web browser session for the SAP Web Dispatcher Web Admin UI.

    14. In the PSE Management / SAPSSLS view of the SAP Web Dispatcher Web Admin UI, choose Import CA Response into PSE SAPSSLS.pse.

    15. Paste the complete CA Response into the Import CA Response field (in the Web Admin UI of SAP Web Dispatcher) and choose Import.

    16. Note that the value of Issuer changed to CN=Secure Login SSL CA, O=SAP Training, C=DE.

    17. Note the value of SubjectAltName.

    18. Finally, log off from the Web Admin UI (note the Logout icon at the top right).steps:

Task 3: Verify the Configuration

Steps

  1. On the WTS, open and log on to the Web Admin UI of SAP Web Dispatcher and note the SSL status.

    1. On the WTS, close all Web browser windows.

    2. On the WTS, start a Web browser of your choice.

      Caution

      Do not use the Web browser at operating system level of your feature server.

    3. Enter the following URL: https://<full qualified SAP Web Dispatcher host name>:<SAP Web Dispatcher HTTPS Port>/sap/wdisp/admin.

      • Q team: https://fsqhost.wdf.sap.corp:44320/sap/wdisp/admin

      • P team: https://fsphost.wdf.sap.corp:44330/sap/wdisp/admin

    4. When asked for credentials, provide the following: usernamewebadm, and your master password (which should be SAPWebDisp##).

    5. Note the SSL status in the Web browser – no warnings should be reported.

      Hint

      No warnings about the SSL certificate display because the Web browsers on the WTS trust the issuing Certification Authority (CN = Secure Login SSL CA, O = SAP Training, C = DE).

SAP Web Dispatcher in SSL Client Role

If SAP Web Dispatcher also uses SSL for the connection to the AS ABAP system (re-encryption), then it also needs to possess a key pair to use for this connection. This information is stored in its SSL client PSE.

You have different options to establish a trust between SAP Web Dispatcher and an AS ABAP system. One approach is that you export the SSL server certificate from the AS ABAP system and import it to the SAP Web Dispatcher client PSE. However, a more convenient approach is that you have a common Certification Authority (CA) in place.

  • Use this CA to sign the SSL server certificate of AS ABAP (transaction STRUST).

  • Import the root certificate of the same CA into the SAP Web Dispatcher client PSE.

As of SAP Web Dispatcher 7.53, you can establish the trust with an AS ABAP-based back-end system completely in the Web Admin UI (a separate download of the respective certificate is not necessary anymore). To do so, use the feature in the Web Admin UI available at <SID of SAP system> → Monitor Application Servers → <application server menu (column Name)> → Establish Trust. Here you can choose the certificate to establish the trust (Root Certificate, Issuer Certificate(s) or Peer Certificate).

Additional information

For more information, see SAP Help Portal – Additional Content on How to Configure SAP Web Dispatcher to Trust Backend System SSL Certificate at https://help.sap.com/docs/SUPPORT_CONTENT/si/3362959216.html.

Enable HTTPS between SAP Web Dispatcher and the SAP System

Note

In this exercise, when an object name or a value contains ##, replace ## by the number your trainer assigned to you.

Task 1: Check the Communication Between SAP Web Dispatcher and the SAP System

Steps

  1. Open and log on to the Web Admin UI of your SAP Web Dispatcher.

    1. On the WTS, start a web browser of your choice.

    2. Enter the following URL: https://<full qualified SAP Web Dispatcher hostname>:443$$/sap/wdisp/admin where $$ is the SAP Web Dispatcher instance number.

      • Q team: https://fsqhost.wdf.sap.corp:44320/sap/wdisp/admin

      • P team: https://fsphost.wdf.sap.corp:44330/sap/wdisp/admin

      Note

      You may also use the Web browser favorite/bookmark prepared at
      • Q team: 20 Quality Assurance → fsqhost → 20 WDQ SAP Web Dispatcher Administration
      • P team: 30 Production → fsphost → 30 WDP SAP Web Dispatcher Administration

    3. At the SAP Web Dispatcher logon screen, provide the Usernamewebadm and your master Password (which should be SAPWebDisp##).

  2. Open the Application Server Monitor within the SAP Web Dispatcher Web Admin UI and note the HTTPS validity.

    1. Within the Web Admin UI of your SAP Web Dispatcher, navigate to <SID of your SAP system> → Monitor Application Servers. The Application Server Monitor opens.

    2. Note the column Valid (HTTPS). The tooltip of the warning (triangle icon) is Server is not reachable: SSL peer certificate untrusted – in this case due to missing configuration steps.

    3. Keep this Browser session open.

Task 2: Import the SAP Secure Login Server Root Certificate into the SAP Web Dispatcher Client PSE

Steps

  1. Determine the signer of the SSL server certificates used by the ICM processes of your SAP S/4HANA system.

    1. Log on to your SAP system using the credentials of your training user train-##.

    2. Start transaction STRUST.

    3. In the tree structure, open the folder SSL server Standard → System-wide.

    4. Double-click any of the (application server) instances.

    5. Note the Issuer Certificates section in the area Own Certificate.

    6. Do not change anything here – this is just for your reference.

    Result

    The SAP Secure Login Server has also signed the SSL server certificate used by the ICM processes of your SAP S/4HANA system.

  2. Import the SAP Secure Login Server Root Certificate into the SAP Web Dispatcher Client PSE.

    1. If you have not yet already done, within the Web Admin UI of your SAP Web Dispatcher, navigate to <SID of your SAP system> → Monitor Application Servers. The Application Server Monitor opens.

    2. Note the Name column that shows the application server instances of your SAP system.

    3. Select the Host Menu for any of the instances (by selecting them), and choose Establish Trust (see screenshot).

    4. In the line for certificate type Root Certificate, choose Import Certificate into SAPSSLC.pse (on the right in column Actions).

    5. Choose Import.

Result

You have imported the SAP Secure Login Server Root Certificate into the SAP Web Dispatcher Client PSE.

Task 3: Verify the Configuration

Steps

  1. Repeat the first task of this exercise ("Check the Communication between SAP Web Dispatcher and the SAP System").

    1. Within the Web Admin UI of your SAP Web Dispatcher, navigate to <SID of your SAP system> → Monitor Application Servers. This opens the Application Server Monitor.

    2. Note the Valid (HTTPS) column. No warnings should be displayed.

  2. On the WTS, call the ICF service /sap/public/info of your SAP system:

    • using a web browser on the WTS

    • in your SAP S/4HANA system

    • using your SAP Web Dispatcher

    1. On the WTS, open a Web browser.

    2. Enter the following URL: https://<full qualified SAP Web Dispatcher hostname>:<SAP Web Dispatcher HTTPS Port>/sap/public/info.

      • Q team: https://fsqhost.wdf.sap.corp:44320/sap/public/info

      • P team: https://fsphost.wdf.sap.corp:44330/sap/public/info

      In case of repeated refreshes, you should notice that the requests are distributed to the PAS and AAS instance of the SAP system (note the value of RFCDEST).

Task 4: Optional: Configuration Check

Steps

  1. Re-run the configuration check of your SAP Web Dispatcher by executing the following command

    sapwebdisp pf=<profile> -checkconfig

    from the profile directory of your SAP Web Dispatcher installation.

    1. Log on to the operating system of your feature server. As an SSH access is sufficient, here are the access steps:

      1. On your WTS, start MobaXterm (the first call takes a little while).
      2. Choose Session.
      3. Choose SSH.
      4. Provide Remote host (fs<q|p>host.wdf.sap.corp), select Specify username (and enter user wd<q|p>adm). Choose OK.
      5. Enter the Password (your master password, which should be SAPWebDisp##).

    2. Within the SSH terminal window, execute the command cdpro to switch to the profile directory of your SAP Web Dispatcher installation (/usr/sap/<WDQ|WDP>/SYS/profile/).

    3. Within the SSH terminal window, execute the following command: sapwebdisp pf=<profile> -checkconfig.

      • Q team: sapwebdisp pf=WDQ_W20_fsqhost -checkconfig
      • P team: sapwebdisp pf=WDP_W30_fsphost -checkconfig

Result

The result of a detailed check of your SAP Web Dispatcher installation is being displayed. Now you should not see any warnings regarding the HTTPS connection to the application servers of your SAP system.

Load Balancing

SAP Web Dispatcher routes and distributes incoming HTTP(S) requests to an appropriate application server instance. The next figure illustrates the distribution in a simplified way, also not covering an AS Java as back end system.

In case of a stateful connection, SAP Web Dispatcher selects the application server instance that is processing the transaction.

In case of a new request or a stateless connection, SAP Web Dispatcher checks if the called prefix is assigned to a logon group. Use transaction SMLG to create logon groups, and transaction SICF to assign them to ICF services or external aliases.

In case no logon group was assigned to the requested prefix, SAP Web Dispatcher uses one of the following build-in logon groups:

  • !DIAGS for https requests (made of all application server instances with a running ICM process offering the https protocol)
  • !DIAG for http requests (made of all application server instances with a running ICM process offering the http protocol)

Both static and dynamic elements are used for load balancing with the SAP Web Dispatcher. SAP Web Dispatcher provides various procedures for load balancing with a logon group. The capacity of an application server is an important factor. The capacity is a measure of the "power" of an application server – in case of AS ABAP, the calculation is based on the number of dialog work processes.

You can see what capacity of SAP Web Dispatcher is used for load balancing in the Web Administration interface under Monitor Server Groups in column Capacity. Here you can also overwrite the capacity value using the right mouse button. The changes are lost when SAP Web Dispatcher is restarted.

Hint

HTTP load balancing using the message server is deprecated. Use SAP Web Dispatcher instead. For more information, see SAP Note 1040325HTTP load balancing: Message server or Web Dispatcher?

Multiple Systems Support

Multiple Systems

SAP Web Dispatcher supports multiple SAP (backend) systems (and non-SAP Web servers) out of the box. You do not have to set up, configure, or wait for an SAP Web Dispatcher for each system; you can use a common SAP Web Dispatcher for all systems. This must then be configured for all connected systems.

You can separate the requests using one of the various mechanisms, or a combination of mechanisms configured using subparameters of parameter wdisp/system.

Host Name (subparameter SRCVHOST)
Requests are forwarded to the configured system if the host name in the URL matches the host name specified in SRCVHOST.
URL path prefix (subparameter SRCURL)
Requests are forwarded to the configured system if the URL path prefix matches the URL path prefix specified in SRCURL.
Access point (IP address (or host name) and port) of SAP Web Dispatcher (subparameter SRCSRV)
Requests are forwarded to the configured system if SAP Web Dispatcher IP address and port where the request was received match the access point specified in SRCSRV.

In most scenarios SRCVHOST and SRCURL are sufficient to perform the system selection. If the system selection cannot be performed using the subparameters listed above, it is possible to perform system selection in the HTTP modification handler by setting header field X-SAP-WEBDISP-TARGET-SID.

For each back-end system, add a wdisp/system_<xx> line to SAP Web Dispatcher profile. For example:

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

For each incoming request, SAP Web Dispatcher uses the configured criteria and the setting of wdisp/system_<xx> to check which system the request can go to. If the criteria are met by more than one system, the behavior is determined by the parameter wdisp/system_conflict_resolution. For more information and examples, see the online documentation.

Note

In a multiple system scenario, SAP Web Dispatcher ignores the profile parameters rdisp/mshost and ms/http_port (to avoid confusion, you can comment them out or even delete them).

Further Functions

SAP Web Dispatcher offers further functions, which are not covered in this lesson. Some of them are:

URL filtering

You can define URLs that you want to be rejected, and, by doing so, restrict access to your system.

Web caching

You can use SAP Web Dispatcher as a Web Cache to improve the response times and to conserve the application server cache.

Request rewriting
You can rewrite HTTP requests (and responses), for example to add or modify HTTP header fields.
SLD registration

You can configure SAP Web Dispatcher to register at a System Landscape Directory (SLD).

Mitigation of Denial of Service (DoS) Attacks

Denial of Service (DoS) attacks are intentional or accidental attacks through an external third party towards resources of the Application Server ABAP. DoS attacks can impact the availability or performance of services caused by excessive use by one or more users.

The aim of Denial of Service (DoS) protection measures is to make the AS ABAP more robust towards server overload caused by excessive use, and to differentiate DoS attacks from legitimate use. However, complete protection is impossible because there is no clear distinction between legitimate and excessive use.

The server can be protected from DoS attacks by preserving server integrity and responsiveness for single-user attacks and increasing the potential cost of attacks.

This can be achieved on multiple lines of defense:

  • Limit connections per client IP to protect SAP Web Dispatcher and back-end system resources
  • Limit concurrent requests for every back-end system (sum of all application servers)
  • Limit application server resources for each user

Limit connections per client IP to protect SAP Web Dispatcher and back-end system resources

SAP Web Dispatcher can be protected from Denial of Service (DoS) attacks by limiting the number of connections from a single IP address. For every network connection that is established, the number of existing connections per client IP address is checked.

To see an overview of the top 25 consumers, including information about the number of active connections and time of last warning and rejection, call up SAP Web Dispatcher Administration UI and navigate to Core System → Client IP Top Consumer.

Profile parameter icm/client_ip_connection_limit contains sub-parameters WARN and REJECT to specify the limits for connections from a single IP address.

The values determined for these subparameters are percentage shares of the maximum number of connections that is specified by icm/max_conn. The default values are set to 90 and 100.

If the limit for WARN is exceeded, the SAP Web Dispatcher creates a system log (Message ID IMA) and trace entry. To prevent the system log from an overload of entries, only one entry per minute is created.

If the limit for REJECT is reached, the SAP Web Dispatcher terminates the connection and creates a system log entry (Message ID IMB).

Note

This mechanism is available for both the ICM and SAP Web Dispatcher.

Limit concurrent requests for every back-end system (sum of all application servers)

The back-end system of Application Server ABAP can be protected from Denial of Service (DoS) attacks by limiting the number of concurrent requests that SAP Web Dispatcher forwards to the back-end system. That way, an overload from an untrusted request source can be avoided.The number of concurrent requests is roughly equal to the number of ABAP work processes that are occupied with processing these requests.

To monitor information about pending requests that have not yet been answered by the back-end system, call up SAP Web Dispatcher Administration UI and go to menu Dispatching Module → Backend System pending Request Info .

Profile parameter wdisp/system contains subparameters PENDING_REQUEST_LIMIT_WARN and PENDING_REQUEST_LIMIT_REJECT to specify the limits for concurrent requests in each back-end system.The values determined for these subparameters are absolute numbers. By default, this feature is disabled and has to be configured by the administrator.

If the limit for PENDING_REQUEST_LIMIT_WARN is exceeded, SAP Web Dispatcher creates both a system log (Message ID IMC) and trace entry.

If the limit for PENDING_REQUEST_LIMIT_REJECT is exceeded, SAP Web Dispatcher returns status code 503 Service Unavailable and creates a system log entry (Message ID IMD).

Note

This mechanism is available for SAP Web Dispatcher only.

Limit application server resources for each user

You can limit the resources consumed by a single user in application server instances of AS ABAP. This is configured using parameter rdisp/user_resource_limit. The parameter also has sub-parameters WARN and REJECT with respective values. These values are percentages. 100 stands for the entire amount of a resource available.

If the WARN limit is reached, syslog and trace entries are written (with flooding prevention).

If the REJECT limit is reached, a system log entry with key R2K is written and the session is cancelled.

Note

This mechanism is available for AS ABAP only.

Additional Information on SAP Web Dispatcher

  • SAP S/4HANA 2023 online documentation (Product Assistance), area Enterprise Technology → ABAP Platform → Application Server ABAP - Infrastructure → Components of Application Server ABAP → SAP Web Dispatcher

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

  • SAP Note 538405SAP Web Dispatcher: composite note

  • SAP Note 552286Troubleshooting for the SAP Web Dispatcher

  • SAP Note 1040325HTTP load balancing: Message Server or Web Dispatcher?

  • SAP Note 908097SAP Web Dispatcher: Release, Installation, Patches, Documentation

  • SAP Note 1708601Inst. Web Dispatcher SAP NetWeaver 7.1 and Higher

  • SAP Note 1282692Displaying logon groups in SAP Web Dispatcher and J2EE stack

  • SAP Note 2007212Tuning SAP Web Dispatcher and ICM for high load

  • SAP Note 2502649Creating certificates with Subject Alternative Name (SAN) through the Web Admin page

  • for installation guides, open the Guide Finder for SAP NetWeaver and ABAP Platform at https://help.sap.com/viewer/nwguidefinder and search for dispatcher

Log in to track your progress & complete quizzes

Learning

SAP FacebookSAP YoutubeSAP LinkedIn