Landscape Architecture: SAP Web Dispatcher deployment

[JoeGoerlich]

The SAP Web Dispatcher is a reverse proxy designed to work best with other SAP software solutions. While there exist many reverse proxy solutions from various software vendors out there, the SAP Web Dispatcher

• is maintained and supported by SAP,


• is available for multiple operating systems,


• follows the same configuration principles as the ICM of SAP NetWeaver AS ABAP/Java,


• can be monitored by the SAP Solution Manager or SAP Focused Run without huge effort and


• is free of additional license costs.

All in all, it integrates very well into an existing SAP Landscape - be it on-premises, be it at hyperscalers.

Updates:

2021-11-08: Added link to SAP note 3115889 on SAP Web Dispatcher embedded deployment
2021-10-15: Added a section describing how to use the SAP Web Dispatcher to securely integrate legacy devices not supporting latest protocols or strong cipher suites.

---

Capabilities of the SAP Web Dispatcher

There are different reasons why we may want or need to deploy the SAP Web Dispatcher as a reverse proxy in our SAP Landscape.

Some of them are

• Implement (stateful) load balancing (which is not possible with Message Server)


• Establish a Single Point of Entry (since bookmarking on client side may lead to issues when Message Server is used for load balancing)


• Ability to display a maintenance page while a backend is unavailable


• Modify headers


• Implement a Cross-Origin Resource Sharing (CORS) setup


• Web caching


• Enable HTTP/2 towards the clients (if older backends don’t support it)

Some more security focused reasons are

• Prevent direct access to the SAP NetWeaver’s ICM or SAP HANA's Platform Router


• Terminate TLS connections (depending on your security teams philosophy)


• Perform URL filtering


• Perform URL rewriting (hiding origins)


• Modify specific security-relevant headers


• Filter certain HTTP methods/verbs


• Establish a DoS attack prevention


• Establish a DDoS attack prevention


• Establish a Slowloris attack prevention


• Perform Network Edge Authentication (NEA)


• Provide a communication middleware for legacy devices to keep the distance of weak-encrypted (or even unencrypted) traffic as short as possible

After we clarified which goals we like to have fulfilled by introducing the SAP Web Dispatcher we have to think about our target landscape architecture. In other words, we have to think about where to deploy/place the SAP Web Dispatcher in our landscape(s).

I did a quick search through some blogposts dealing with the SAP Web Dispatcher. While I could find many valuable blogs going into details of certain configuration aspects I could find none talking about this important superior topic.
In the following I listed some options and noted for each the issues I see.

Please note: I picked just some examples. For sure there exist a lot of possible combinations or variations of these.
At time of writing there is no official support to deploy the SAP Web Dispatcher in a container (see SAP Note 1122387) so I did not consider such a setup.

 

Deployment options of the SAP Web Dispatcher

Now let's have a closer look where we may place the SAP Web Dispatcher as reverse proxy for one of our SAP backend systems.

Please note: In the figures I use SAP NetWeaver (AS ABAP and AS Java) as the backend, but almost everything is also valid for SAP HANA XSA (as well as mostly for the deprecated SAP HANA XS Classic) as a backend.

(A)SCS Instance with Integrated SAP Web Dispatcher

The first deployment option which may come into one's mind is to startup the embedded / integrated SAP Web Dispatcher of the (A)SCS instance. Details about how to do so can be found at SAP Note 2771578.

The SAP note 3115889 gives you guidance whether to opt for a standalone or embedded deployment.

 

Figure taken from help.sap.com

Problems we can identify in this scenario:

• SAP Web Dispatcher process runs with the <sapsid>adm. We should not expose this high privilege account of our SAP NetWeaver system to additional risk.


• It shares resources with the ASCS and in many scenarios also with the (primary) Application Server. We should not expose the Single-Point-of-Failure of our SAP NW to additional risk (e.g., from DDoS attacks)


• It shares in many scenarios also resources with the (primary) Application Server.


• It is not located in a separate network or DMZ. We should not introduce possibilities for lateral movement.


• It shares the maintenance window with the SAP NetWeaver and the underlying Operating System.


• SAP recommends this option for special scenarios only (without go into details what is meant with "special scenarios").

(A)SCS Instance with standalone SAP Web Dispatcher

The deployment option we may logically consider next is to setup a standalone SAP Web Dispatcher on the host of the (A)SCS instance.

Problems we still can identify in this scenario:

• SAP Web Dispatcher Shares resources with the ASCS and in many scenarios also with the (primary) Application Server.


• It is not located in a separate network or DMZ.


• It shares the maintenance window with the operating system of the SAP NetWeaver

Separate standalone SAP Web Dispatcher

The last consideration may then be to setup a standalone SAP Web Dispatcher on a separate host.

From a security perspective this is the go-to architecture.

• SAP Web Dispatcher process runs with its own <sid>adm.


• It doesn't share resources with the Backend(s)


• It is - or at least should be(!) - located in a separate network or DMZ.


• It has its own maintenance window.

To further increase the security level

• SAP Web Dispatcher could be setup as a high available cluster (see below).


• Reverse invoke can be configured to avoid opening the firewall for incoming connections on the backend systems.

 

Integration of the SAP Web Dispatcher into one System Landscape

Since SAP system landscapes consist of a two or more systems (development, sandbox, quality assurance, integration test and production system) as a next step we have to think about how to include all the systems in our considerations.

Single separate standalone SAP Web Dispatcher installation

So, let's start with the simplest architecture.



Problems we can identify:

• Attacks on the SAP Web Dispatcher may affect the whole SAP system landscape. This is even worse when the SAP Web Dispatcher is exposed to the internet.


• No separation between traffic of productive and non-productive systems.


• Certificate stores of the productive and non-productive are accessible by the same OS user.


• Maintenance window of SAP Web Dispatcher affects the availability of all backends (at least if SAP Web Dispatcher is not high available).


• The configurations' complexity increases with the number of backends attached.

Multiple separate standalone SAP Web Dispatcher installations

In the next deployment option, we separate productive from non-productive.

With this we

• separated the traffic between productive and non-productive systems.


• separated the certificate management between productive and non-productive.


• Maintenance window of non-productive SAP Web Dispatcher doesn't affect the availability of productive backends and vice versa.


• The configuration is less complex.

To further increase the security level:

• We may setup at least the productive SAP Web Dispatcher as a high available cluster.


• We may setup two or more SAP Web Dispatcher installations as active/active cluster fronted by an additional load balancer. With this we could also prevent the usage of extbind (runs with elevated privileges) for binding ports <1024 while providing services for the clients on port 443.


• Reverse invoke can be configured to avoid opening the firewall for incoming connections on the backend systems


• The non-productive SAP Web Dispatcher may be further splitted up for each backend (INT/QAS and DEV, etc.),


• web applications can be tested for example how they behave when it comes to load balancing, URL rewriting,


• security measures can be verified before implementing in productive environment.

 

Integration of the SAP Web Dispatcher into multiple (independent) System Landscapes

When we have several (independent) SAP system landscapes in our environment we may come to a point where we have to consider cost savings. Though we may think about optimizations and come to an architecture in which multiple landscapes share a SAP Web Dispatcher.

One SAP Web Dispatcher serves for multiple backends

If we still like to separate the traffic between productive and non-productive systems, we may think about connecting multiple backends of the same classification to one SAP Web Dispatcher.

Problems we can identify:

• Attacks on the SAP Web Dispatcher may affect multiple landscapes. This is even worse when the SAP Web Dispatcher is exposed to the internet,


• multiple certificate stores are accessible by the same OS user (especially when it comes to TLS re-encryption or if multiple domains are addressed via SNI),


• maintenance window of SAP Web Dispatcher affects the availability of all productive or non-productive backends (unless the SAP Web Dispatcher is setup as a high available cluster),


• the configurations' complexity increases with the number of backends attached.

Please note: In some scenarios this architecture is inevitable. For example, if the backends are a SAP Fiori Gateway (ABAP frontend) and SAP Fiori Search (ABAP backend), or SAP NW ABAP and SAP HANA XS, or if the backends are SAP NW AS ABAP and SAP Analytics Cloud - Live Data Connections.

Multiple SAP Web Dispatcher installations on one host

If we still like to save money for an additional box, we may consider running a farm of SAP Web Dispatchers on one host.

Problems we can identify:

• Resources are shared between all SAP Web Dispatcher installations,


• the quota configuration complexity increases with the number of backends and their utilization profiles,


• privilege escalation vulnerabilities may put all SAP Web Dispatcher installations at risk,


• when TLS termination or re-encryption is in place memory may contain unencrypted data of other backends,


• maintenance window of the operating system affects the availability of all backends (unless the SAP Web Dispatcher is setup as a high available cluster),


• different port numbers have to be used for the ports to be allocated by each SAP Web Dispatcher,


• some scenarios require a combination with the setup described above. This introduces additional complexity.

 

Using the SAP Web Dispatcher to securely integrate legacy devices

In some scenarios, legacy devices are used which have been an expensive invest and where the ROI is not reached, yet. Such legacy devices are prone to be used over many many years and get seldom updated. For example, barcode scanner or IoT devices. To keep such devices connected to the SAP backend system without weakening the security of all interfaces.

It might be desirable to use the SAP Web Dispatcher for offering a dedicated entry point. To achieve that, a SAP Web Dispatcher could be placed as close as possible to the legacy devices. It may support defined protocols and cipher suites considered as insecure and weak, and be restricted to be accessed only from defined sources.

Conclusion

As a conclusion we can note: The landscape architecture depends on our budget, already existing operation automation, as well as on our risk appetite.

Please note: SAP’s recommended installation method for the SAP Web Dispatcher is by using SWPM. Since this will also install the SAP Instance Agent and the SAP Host Agent I recommend to visit my blogposts Securing the SAP Host Agent and Securing the SAP Instance Agent / SAP Start Service on how to secure them both properly.

Finally, I like to promote my blogpost about configuration of TLS protocol versions and cipher suites offered by the CommonCryptoLib which is also used by the SAP Web Dispatcher for providing TLS encryption.