Skip to content

Reverse Invoke for Added Security:
SAP Web Dispatcher as an example

reverse invoke img

In this article, we want to highlight a specific feature: the reverse invoke connection setup, by taking an SAP Web Dispatcher to SAP backend scenario as an example.   

Reverse what?

First, let’s have a look at the concept of reverse invoke. Assume two components A and B, where component A wants to send data to component B. In a ‘normal’ scenario, A will try to connect to B and send the data across when the connection is set up successfully. In a reverse invoke scenario, A cannot directly set up a connection to B, but instead, B has to make the connection to A first. And once that connection is established, only then A can send data to B. Compared to the ‘normal’ scenario, the connection is started (invoked) in reverse order.   

Why is this more secure than the ‘normal’ scenario? Compare it to a physical door with a lock to protect access to a building. No matter how secure the lock is, if it’s a door that can only be opened from the inside, it’s even better!  

Standard scenario

Let’s explore this concept for a concrete SAP scenario. A common way to set up external web connectivity to an on-premise SAP environment is to have an SAP Web Dispatcher located in a separate network zone (DMZ), that acts as a reverse proxy to SAP backend systems in a local network. Optionally (and preferably), the DMZ Web Dispatcher does not connect to the local backend systems directly but connects to a Web Dispatcher in the local network first, which in turn, connects to backend systems. These networks are normally strictly separated by firewalls and only the required connections are allowed to be established. This setup is depicted below 

sap web dispatcher - reverse invoke

Reverse invoke scenario

As said, this downside can be avoided with the reverse invoke concept.   

The local Web Dispatcher can set up a connection first to the DMZ Web Dispatcher and afterwards, this connection can be used from the DMZ Web Dispatcher to the local Web Dispatcher to access the backend systems accordingly. This way, HTTPS connections must still be allowed from the internet over port 443 to the DMZ but from there, NO open ports are needed from the DMZ to the local network. This setup is depicted below.  

sap web dispatcher reverse invoke 2

This setup is reached with a set of parameters that activates the reverse invoke function and makes the local Web Dispatcher register itself to the DMZ Web Dispatcher. See the SAP help documentation references below for details.  

In our experience, the reverse invoke principle is not often used in SAP environments and not many consultants are even aware of this possibility for additional security. Still, this option has been around for more than 10 years and is not only valid for the SAP Web Dispatcher but also for SAProuter configurations. Additionally, the SAP Cloud Connector, which is used to connect SAP cloud services to an on-premise SAP environment works with the same principle. Offering the same advantage as mentioned above with the DMZ, no direct connectivity from the SAP cloud environment is required to the on-premise SAP environment. For more information, see here 

As shown above, reverse invoke can be of significant value to set up connectivity more securely and is worth considering for any landscape. Points to consider:   

Elevate the security of your SAP systems with SecurityBridge, a comprehensive security solution designed to protect your critical business data. For more SAP security-related news, articles, and whitepapers, follow us on LinkedIn! 

Posted by 

Gert-Jan Koster

Find recent Security Advisories for SAP©

Looking into securing your SAP landscape? This white-paper tells you the “Top Mistakes to Avoid in SAP Security“. Download it now.