This article appeared in the Oct Nov Dec 2002 issue of SAP Insider and appears here with
■ ■
permission from the publisher, Wellesley Information Services (WIS), www.WISpubs.com.
Achieving Network Security
and Secure Load Balancing
with the SAP Web Dispatcher
One of the questions commonly asked
these days about SAP systems, and the
SAP Web Application Server in partic-
ular, 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 connec-
tions 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.
Regular Feature
Security
Strategies
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)
Dr. Jürgen Schneider, SAP AG
between your intranet and the Internet.1
To help ensure high availability
and greater security, the SAP Web
Dispatcher has two main functions:
both stateless and stateful SAP applica-
■
It acts as the single entry point for all tions, whether they are Business Server
web requests destined for applications Pages (BSP) or Java-based (J2EE)
running on the SAP Web AS. applications. The Web Dispatcher
functions keep track of the current
■
It distributes and load balances these
load of the application server instances
requests among the different applica-
and take care that web requests
tion server instances.
belonging to one session are always
As such, the SAP Web Dispatcher
sent to the same application server
represents a “first line of defense”
instance holding that session.
against all kinds of attacks at the
network and protocol level — mainly
Positioning the SAP Web
denial of service attacks by network
Dispatcher in Your Network
flooding, and protocol attacks via
for Enhanced Security
malformed URLs and HTTP requests,
To realize secure access from the
such as buffer overflow attacks.
Internet, the SAP Web Dispatcher is
At the same time, the SAP Web placed on a computer running in your
Dispatcher provides load balancing for network’s DMZ. Typically, with this setup,
a first, external firewall system blocks
1
Although this is the most important use of the SAP
all access from the Internet, allowing
Web Dispatcher program, it can be used to support
the separation of network zones and optimal load only the HTTP and HTTPS protocols to
balancing inside your intranet as well. pass through. Even then, these protocols
Subscribe today. Visit www.SAPinsider.com.
can only reach the computers installed
in the DMZ (see Figure 1).
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 informa-
tion about logon groups and the current
load situation of the SAP application
server instances, to forward it to the
appropriate application server session.
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
2
For more 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.
Figure 1 Network Positioning of the SAP Web Dispatcher
and SAP Web Application Server Instances
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 load.
Subscribe today. Visit www.SAPinsider.com.
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 informa-
tion about the application server
instance holding the corresponding
session. The SAP Web Dispatcher uses
this information to route the request to
this application server instance.
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 adminis-
tration.” 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 =
<profile> 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.
The profile 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 applica-
tions. 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.
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 param-
eter wdisp/url_map_location
in the profile file for the Web
Dispatcher (see the example on the
next page).
In addition to mapping capabilities,
the SAP Web Dispatcher and the SICF
configuration settings provide powerful
Figure 2 Administration of Service Access in the SAP Web Application Server
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 param-
eter 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:
P /public/catalog
P /shop/public
P /shop/start
D /public/*
D /shop/*
P /sap/bc/ping
D /sap/*
Subscribe today. Visit www.SAPinsider.com.
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
✔ NOTE!
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 recom-
mended 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.
 balancing will depend on your expected
Example of a “Profile” File for the SAP Web Dispatcher web clients and where they are located.
# Minimum configuration settings: Whether it is wise to therefore termi-
# SAP System identification and instance number (examples)
nate the SSL connections before your
SAPSYSTEMNAME = C11 application server instances can be a
SAPSYSTEM = 66 matter of debate between the networking
# Describe message server host (example host name) and the security camps in your adminis-
rdisp/mshost = sidmain tration staff. This option is not currently
# Description of access ports (examples) provided by the SAP Web Dispatcher,
icm/server_port_0 = PROT=HTTP, PORT=8855, TIMEOUT=30 but is possible with the SAP Web AS
icm/server_port_1 = PROT=ROUTER, PORT=22222, TIMEOUT=300
using public-domain or partner solutions.
# Example additional configuration settings:
# (only needed if defaults are not ok) Summary
# URL mapping infos (examples) This article provided an overview of
wdisp/max_url_map_entries = 50
the SAP Web Dispatcher, an important
wdisp/url_map_location = /acme/urlinfos
function of SAP Web AS Release 6.20
# URL filtering (example file name)
that can be very useful for comple-
wdisp/permission_table = cfg/permtab
menting your network security and
# Parameters for HTTPS routing (examples)
providing load balancing for applications
# This example bitmask "masks" the last 12 bits of client IP addresses,
# so, for example, 124.94.55.1 and 124.94.55.99 appear to be the same running on your SAP Web AS installa-
wdisp/HTTPS/dest_logon_group = HTTPSGROUP tion. If you are planning on installing the
wdisp/HTTPS/sticky_mask = 255.255.240.0
SAP Web AS on your system, consider
# Server infos and info refresh interval (examples) maximizing its security capabilities by
wdisp/max_servers = 100
installing the SAP Web Dispatcher in the
wdisp/max_server_groups = 32
wdisp/server_info_location = /msgserver/text/logon DMZ of your network to protect your
wdisp/group_info_location = /acme/groupinfos main SAP Web AS installation from
wdisp/auto_refresh = 120 various attacks from the Internet. Once
you have gone through the simplified
setup, you’ll encounter “zero administra-
the request data and cannot use the for load balancing based on the client tion” in most cases.
URL or the data contained in the IP address (“sticky-mask”), so that
As a kind of simple “software” web
SAP_CONTEXT_ID cookie for load requests from a whole group of clients
switch, the SAP Web Dispatcher is not
balancing. Instead, it uses other infor- are always routed to the same applica-
intended to replace or compete with
mation to make the load-balancing deci- tion server, which is required to support
enhanced offerings by SAP partner
sion while preserving stateful sessions. stateful applications. It is also possible
vendors in this area that, for example,
In the case of HTTPS web requests, to create a special logon group that
provide the same functions with higher
the only information available to the contains all application servers where
performance through dedicated hardware
Web Dispatcher is the client IP address. SSL is configured and that support
solutions or extend filtering and screening
This might present a certain problem for HTTPS. The incoming HTTPS requests
capabilities as compared to the SAP Web
load balancing, since a whole group of will then only be distributed between
Dispatcher. The use of partner solutions is
web clients could potentially use a single the servers in this group. Our sample
still possible with the SAP Web AS.
HTTP proxy through which they send profile file is set to handle HTTPS
their requests. The SAP Web Dispatcher load balancing this way. For more information on the SAP
cannot differentiate between different Web Dispatcher function, see the SAP
In any case, it is obvious that the
web clients that are sending requests via Web Application Server 6.20 online docu-
client IP address-based load balancing
the same HTTP proxy. Sometimes, a mentation at http://help.sap.com.
might not be optimal if a large
group of web clients might even use percentage of web clients are located
Dr. Jürgen Schneider has been involved in the
alternate HTTP proxies during one behind a single HTTP proxy. Here we
design and implementation of SAP security
session, depending on the Internet are faced with a typical tradeoff functions since 1996. Since 1998, he has been
provider being used. between optimal load balancing and the Development Manager for Security in SAP’s
There are a couple of ways around end-to-end security. In the end, whether Technology Development. He can be reached at
this. It is possible to specify a bitmask this is a satisfactory approach to load j.schneider@sap.com.

Subscribe today. Visit www.SAPinsider.com.