One of the questions commonly asked these days about SAP systems, and
the SAP Web Application Server in particular, concerns the setup of networks
and SAP application server instances for optimal security and availability.
This is particularly true of customers who are running large intranets
with hundreds, perhaps thousands of clients, and then connecting these
intranets - and their SAP applications - to the Internet. Clearly, they
want to make sure that their SAP servers are safe from attacks at various
levels, especially at the network and communications level, as it provides
the means to access the SAP applications from inside and outside the company.
Of course, the more connections there are with the Internet, the more
web requests come into your system, and the greater the demands on your
system resources. So it has become increasingly important to properly
distribute incoming web requests over the available application server
instances to achieve optimal load balancing.
With SAP Web Application Server (Web AS)
Release 6.20, the SAP Web Dispatcher function provides additional help
for precisely these tasks. This article provides a brief overview of the
SAP Web Dispatcher function and the benefits it provides for network security
and secure load balancing for your SAP Web Application Server installations.
What Is the SAP Web Dispatcher?
The SAP Web Dispatcher provides the function of a "software"
web switch for applications running on your SAP Web Application Server.
It is a standalone program provided with the SAP Web Application Server
Release 6.20 that can be installed separately on a server in the De-Militarized
Zone (DMZ) between your intranet and the Internet.1
To help ensure high availability and greater
security, the SAP Web Dispatcher has two main functions:
- It acts as the single entry point for all web requests destined for
applications running on the SAP Web AS.
- It distributes and load balances these requests among the different
application server instances.
As such, the SAP Web Dispatcher represents
a "first line of defense" against all kinds of attacks at the
network and protocol level - mainly denial of service attacks by network
flooding, and protocol attacks via malformed URLs and HTTP requests, such
as buffer overflow attacks.
At the same time, the SAP Web Dispatcher
provides load balancing for both stateless and stateful SAP applications,
whether they are Business Server Pages (BSP) or Java-based (J2EE) applications.
The Web Dispatcher functions keep track of the current load of the application
server instances and take care that web requests belonging to one session
are always sent to the same application server instance holding that session.
Positioning the SAP Web Dispatcher in Your Network for Enhanced Security
To realize secure access from the Internet, the SAP Web Dispatcher is
placed on a computer running in your network's DMZ. Typically, with this
setup, a first, external firewall system blocks all access from the Internet,
allowing only the HTTP and HTTPS protocols to pass through. Even then,
these protocols can only reach the computers installed in the DMZ (see
||Network Positioning of the SAP Web Dispatcher and SAP Web Application
The SAP Web Dispatcher runs on one of these
computers in the DMZ. It receives the requests and, if appropriate, routes
the requests over a second, internal firewall system to one of the application
servers in the internal network.
As part of this function, the SAP Web Dispatcher
is able to analyze incoming web requests, check if they belong to an existing
session (HTTP only), and then make the routing decision, using information
about logon groups and the current load situation of the SAP application
server instances, to forward it to the appropriate application server
To retrieve current information about existing
application servers, configured logon groups, and their URL mappings,
the SAP Web Dispatcher communicates with the message server and the application
server instances of your SAP Web AS installation. As such, it can be perceived
as an extension of Internet Communication Manager (ICM) processes, which
run with each of the application server instances and handle communications
between the SAP Web Application Server and all clients.2
However, unlike other functions of the
application server processes - like user authentication and authorization
- the SAP Web Dispatcher function always remains an "untrusted"
part of this process system, and it only forwards HTTP(S) requests and
responses to and from the web clients.
The major benefit is that, even if a denial
of service and buffer overflow attack were successful, it could only affect
the SAP Web Dispatcher, leaving all the other parts of your SAP Web AS
installation fully operational (for example, for intranet access). A simple
restart of the SAP Web Dispatcher after the attack immediately provides
recovery from such situations, should they occur.
Load Balancing for High Availability
The SAP Web Dispatcher uses a "weighted round-robin" approach,
familiar to solution architects, to divide the load for maximum "fairness"
of scheduling. The "weight" is derived from the number of work
processes, which are configured for each application server instance.
The Web Dispatcher is set to route new, incoming web requests round-robin
to the next application server instance, depending on the server's previous
For stateful applications, the SAP Web
Dispatcher inspects the HTTP requests and looks for the SAP_CONTEXT_ID
cookie. If this cookie is present, it contains information about the application
server instance holding the corresponding session. The SAP Web Dispatcher
uses this information to route the request to this application server
For HTTPS requests, where the complete
request data is encrypted by means of the Secure Sockets Layer (SSL) protocol,
the client IP address is used as the basis for load balancing only. We
will get back to this mode in a later section.
The basic configuration of the SAP Web
Dispatcher is purposely simple, and setup requires little work on the
part of system administrators. The next sections detail how you can start
using the Web Dispatcher so it can begin gathering the information it
needs - server load, URL mappings, HTTPS routing, etc. - and some simple
options you can add to meet the particular needs of your own systems.
Simple Setup and Minimal Configuration
The SAP Web Dispatcher program was designed to require "zero administration."
Just copy the sapwebdisp
executable from your SAP Web Application Server Release 6.20 installation
to the computer where the SAP Web Dispatcher should run. To start it,
enter sapwebdisp pf =
on the command line of your administration console
for this computer, where "profile" is the path and filename
of a file containing the SAP profile parameter settings.
file only requires some basic information to be up and running: the instance
number of the appropriate SAP system, the host name of the message server,
and the port numbers to be used for HTTP and HTTPS, as you can see in
the profile example on the next page. If you choose, you can incorporate
additional options to supplement the SAP Web Dispatcher defaults.
URL Mapping and Filtering
To fulfill mapping and filtering functions, the SAP Web Dispatcher needs
to know which URLs map to which services and applications in the SAP Web
AS. By default, only those URLs that actually map to existing applications
need to be processed. In addition, you can configure certain URLs to be
handled by corresponding server groups only (logon groups).
Configuration of the URLs and URL prefixes
- and the virtual hosts and logon groups supporting them - is done by
the administrator of your SAP Web Application Server installation using
dialog transaction SICF (see Figure 2). By default, the SAP Web
Dispatcher retrieves these configuration settings from one of the application
servers by using the public information services of the Internet Communications
Framework (ICF) function of the SAP Web AS, so that it understands which
services are linked to which applications. In Figure 2, you can see these
public services provided by the ICF listed in the icf_info service
group of the default host configuration.
||Administration of Service Access in the SAP Web Application Server
If you are not using the default host,
but you have configured your own virtual hosts with SICF, you have to
provide aliases in SICF pointing to the ICF public information services
to be used by the Web Dispatcher. You can then make your aliases for the
ICF public services available to the Web Dispatcher by setting the profile
in the profile file for the Web Dispatcher (see the example below).
In addition to mapping capabilities, the
SAP Web Dispatcher and the SICF configuration settings provide powerful
functions for URL filtering and blocking. As an option in the profile
file for the SAP Web Dispatcher, you can define a URL permission table
with profile parameter wdisp/permission_table,
as shown in the sample profile. The entries in the permission_table file
can either permit (P) or deny (D) URL patterns from passing through the
Web Dispatcher. Setting a URL pattern to S would require the use of HTTPS
for all the URLs defined by this pattern. The entries are evaluated from
top to bottom, and the first matching entry is applied.
The usual strategy is to first have explicit
"permit" entries for the URLs mapped to configured applications
and then add "deny" entries for anything else. The default SAP
service tree can also be blocked at the SAP Web Dispatcher this way. For
example, your permission_table entries might look like this:
Using the permission_table
option with the SAP Web Dispatcher provides URL blocking for your
SAP Web Application Server installation only as long as there is
no other network path that bypasses the SAP Web Dispatcher.
As a result, it is highly recommended
that you do not rely on this option exclusively, but also activate
and deactivate services as desired in your SAP Web Application Server
installation directly using dialog transaction SICF.
Load Balancing with SSL: The HTTPS Routing Option
When working with secure web requests over the Secure Sockets Layer (SSL)
protocol and HTTPS, the request data is completely encrypted using strong
cryptography. This encryption is end-to-end - from the web client (the
web browser, for example) through to the Internet Communication Manager
(ICM) process in the receiving application server instance. As a result,
the SAP Web Dispatcher does not have access to the request data and cannot
use the URL or the data contained in the SAP_CONTEXT_ID cookie for load
balancing. Instead, it uses other information to make the load-balancing
decision while preserving stateful sessions.
In the case of HTTPS web requests, the
only information available to the Web Dispatcher is the client IP address.
This might present a certain problem for load balancing, since a whole
group of web clients could potentially use a single HTTP proxy through
which they send their requests. The SAP Web Dispatcher cannot differentiate
between different web clients that are sending requests via the same HTTP
proxy. Sometimes, a group of web clients might even use alternate HTTP
proxies during one session, depending on the Internet provider being used.
There are a couple of ways around this.
It is possible to specify a bitmask for load balancing based on the client
IP address ("sticky-mask"), so that requests from a whole group
of clients are always routed to the same application server, which is
required to support stateful applications. It is also possible to create
a special logon group that contains all application servers where SSL
is configured and that support HTTPS. The incoming HTTPS requests will
then only be distributed between the servers in this group. Our sample
profile file is set to handle HTTPS load balancing this way.
In any case, it is obvious that the client
IP address-based load balancing might not be optimal if a large percentage
of web clients are located behind a single HTTP proxy. Here we are faced
with a typical tradeoff between optimal load balancing and end-to-end
security. In the end, whether this is a satisfactory approach to load
balancing will depend on your expected web clients and where they are
Whether it is wise to therefore terminate
the SSL connections before your application server instances can be a
matter of debate between the networking and the security camps in your
administration staff. This option is not currently provided by the SAP
Web Dispatcher, but is possible with the SAP Web AS using public-domain
or partner solutions.
This article provided an overview of the SAP Web Dispatcher, an important
function of SAP Web AS Release 6.20 that can be very useful for complementing
your network security and providing load balancing for applications running
on your SAP Web AS installation. If you are planning on installing the
SAP Web AS on your system, consider maximizing its security capabilities
by installing the SAP Web Dispatcher in the DMZ of your network to protect
your main SAP Web AS installation from various attacks from the Internet.
Once you have gone through the simplified setup, you'll encounter "zero
administration" in most cases.
As a kind of simple "software"
web switch, the SAP Web Dispatcher is not intended to replace or compete
with enhanced offerings by SAP partner vendors in this area that, for
example, provide the same functions with higher performance through dedicated
hardware solutions or extend filtering and screening capabilities as compared
to the SAP Web Dispatcher. The use of partner solutions is still possible
with the SAP Web AS.
For more information on the SAP Web Dispatcher
function, see the SAP Web Application Server 6.20 online documentation
Example of a "Profile" File for the SAP Web Dispatcher
# Minimum configuration settings:
# SAP System identification and instance number (examples)
SAPSYSTEMNAME = C11
SAPSYSTEM = 66
# Describe message server host (example host name)
rdisp/mshost = sidmain# Description of access ports (examples)
icm/server_port_0 = PROT=HTTP, PORT=8855, TIMEOUT=30
icm/server_port_1 = PROT=ROUTER, PORT=22222, TIMEOUT=300
# Example additional configuration settings:
# (only needed if defaults are not ok)
# URL mapping infos (examples)
wdisp/max_url_map_entries = 50
wdisp/url_map_location = /acme/urlinfos
# URL filtering (example file name)
wdisp/permission_table = cfg/permtab
# Parameters for HTTPS routing (examples)
# This example bitmask "masks" the last 12 bits of client
# so, for example, 184.108.40.206 and 220.127.116.11 appear to be the
wdisp/HTTPS/dest_logon_group = HTTPSGROUP
wdisp/HTTPS/sticky_mask = 255.255.240.0
# Server infos and info refresh interval (examples)
wdisp/max_servers = 100
wdisp/max_server_groups = 32
wdisp/server_info_location = /msgserver/text/logon
wdisp/group_info_location = /acme/groupinfos
wdisp/auto_refresh = 120
Although this is the most important use of the SAP Web Dispatcher program,
it can be used to support the separation of network zones and optimal
load balancing inside your intranet as well.
more information on the Internet Communication
Manager in the SAP Web Application Server,
see the white paper " SAP Web Application Server:
Building Reliable Business Applications" at www.SAP.com/solutions/technology.
Dr. Jürgen Schneider has been involved in the design and implementation
of SAP security functions since 1996. Since 1998, he has been the Development
Manager for Security in SAP's Technology Development. He can be reached