GRC
HR
SCM
CRM
BI


Article

 

Achieving Network Security and Secure Load Balancing with the SAP Web Dispatcher

by Dr. Jürgen Schneider | SAPinsider

October 1, 2002

by Dr. Jürgen Schneider, SAP AG SAPinsider - 2002 (Volume 3), October (Issue 4)
 

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 Figure 1).

Figure 1 Network Positioning of the SAP Web Dispatcher and SAP Web Application Server Instances

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 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

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.

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 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 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.

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 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.

Figure 2 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 parameter wdisp/url_map_location 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:

		  
P /public/catalog
P /shop/public
P /shop/start
D /public/* 
D /shop/*
P /sap/bc/ping
D /sap/*

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 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 located.

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.

Summary

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 at http://help.sap.com.

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 IP addresses, # so, for example, 124.94.55.1 and 124.94.55.99 appear to be the same 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

1 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.

2 For 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 at j.schneider@sap.com.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ