SAP Web Dispatcher as an example
In previous blogs, we have written about security aspects of the SAP Web Dispatcher and SAProuter, see the following links here and here. In this blog we want to give attention to a feature that can give significant added value to these components: reverse invoke connection setup. We will explore this 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 sends the data across when the connection is setup successfully. In a reverse invoke scenario, A cannot directly setup 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 you fit in that door, a door that can only be opened from the inside, is even better!
Standard scenario
Let’s explore this concept for a concrete SAP scenario. A common way to setup 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.
The downside of this setup is that the connections are initiated from outside to inside and need to be allowed as such. For a common web scenario, HTTPS connections must be allowed from the internet over port 443 to the DMZ. And then from the DMZ, connections must be allowed to the local network (not necessarily port 443). No matter the additional network security measures taken, this connectivity must be allowed and ports need be opened which are in principal a potential starting point for exploitation.
Reverse invoke scenario
As said, this downside can be avoided with the reverse invoke concept.
The local Web Dispatcher can setup 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 DMZ to the local network. This setup is depicted below.
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 not only valid for the SAP Web Dispatcher but also for SAProuter configurations. Additionally, the SAP Cloud Connector, that is used to connect SAP cloud services to an on-premise SAP environment works with the exact same principal. Offering the same advantage as mentioned above with the DMZ, that 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 setup connectivity more securely and is worth considering for any landscape. Points to consider:
- A reverse invoke setup can be more complex than the ‘standard’ setup.
- SAP recommends the setup between Web Dispatchers and to avoid direct setup between web dispatcher and backend systems, see SAP note 2220456. Although this latter scenario is described by SAP as well.
- See the following SAP notes for further information:
- SAP note 2977428 – Multiple Reverse Invoke for one Backend System.
- SAP note 2220456 – How to configure SAP Web Dispatcher for Reverse Invoke.
- SAP note 1599704 – Reverse Invoke does not work for Web Dispatcher
- See the following help files for documentation concerning reverse invoke and scenarios, including the scenario described above.
- https://help.sap.com/docs/SAP_NETWEAVER_750/af8bcf35778c4d098ba482cc0b59f339/46d5491e2d2b65d0e10000000a155369.html?q=reverse%20invoke
- https://help.sap.com/docs/ABAP_PLATFORM_NEW/af8bcf35778c4d098ba482cc0b59f339/46d5491e2d2b65d0e10000000a155369.html?q=reverse%20invoke
For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!
Try out Protect4S for 1 month for free or request a demo!
