Blog Updated – 18th October 2013 – SAP documentation supporting ERP system in
DMZ for securing AbapWebDynPro
Good Evening All,
some questions and an exploration of thoughts about securing SAP from the Internet.
During the last 5 years requirements have come up during SAP assignments for Internet Facing SAP
Solutions to be setup.
Two classic examples of Internet Facing SAP Solutions which will be used for the purpose of examples
in this blog are the:
. FSCM Biller Direct
. SNC Partner Access
For the scope of the blog, the following will not be discussed or taken into consideration:
. Web Access Management
. User provisioning
. Firewalls, Reverse Proxies, Security Zones
the assumption will be made for the sake of this blog that the above layers are correctly in place.
The company where we are working for is a committed SAP Customer and sticks to SAP Products
suite and SAP standard as much as possible.
Now to the Challange:
Let’s set the scene, you are a Basis Architect, or Basis Administrator/Architect.
A Demand has landed on your desk stating that the Business want to implement the following:
. Internet Facing FSCM Biller Direct
. SNC Partner Access
How to do this and how to make the solution as secure as possible ?
Starting with FSCM Biller Direct, the beauty with FSCM BIller Direct is,
. it is still a Portal Java Business Package, using classical JCo’s for the abstraction
of the intergration to the backend SAP ECC FI system
. this is true right upto EP 7.3 and the Biller Direct 635 Business Package
This means, we setup a SAP Portal as an Internet Facing Portal.
And we have no requirement to directly expose the SAP ECC FI system, we do not need to
open any Firewall Ports from the Internet towards the SAP ECC FI system because, the
integration between SAP Portal and SAP ECC FI is handled by classical abstraction of JCo
Java Connector Remote Function Calls.
In this situation, the Portal is acting as a Proxy for the requests towards the SAP ECC FI
This solution adheres to the classical security recommendations of not exposing SAP Business
Systems to the Internet where possible.
As described in the help.sap.com documentation,
For the SNC Partner Access the situation could not be more the opposite
In the SNC Partner Access, we can use the SAP Portal as the container, managing Roles, and standardising
look and feel, but with SNC Partner Access the out of the box vanilla functionality runs on the SAP SCM/SNC
backend Business System as ABAP WebDynPro.
The ABAP WebDynPro applications are served up by the Web Server on the ABAP Stack.
Consequently, in this scenario, the SAP Portal, acts simply as a container and provides an IFrame (Application
Integration Iview) for the SAP SCM/SNC ABAP WebDynPro Applications running on the backend.
Therefore, in this scenario, we are forced to open Internet Facing Firewall Ports directly for the SAP SCM/SNC
Business System and once the Users have accessed the SAP Portal their interaction and communication
from the Internet is directly against the backend SAP SCN/SNC Business System.
This goes against the recommended standard of not opening SAP Business Suite systems directly to the Internet.
The scenario is described here in the help.sap.com documentation:
Naturally there is guidance from SAP and other sources on how to make the best of this situation, for example,
But this still does not change the fact that this approach is exposing a SAP Business System directly to the Internet.
What are the alternatives for Internet Facing Business Demands where the SAP Standard is ABAP WebDynPro ?
The next question then, is, for the scenarios where the SAP standard vanilla solution is using ABAP WebDynPro, what
are the alternative ways to fulfill the Demands from the Business, the Business Requirements, and at the same time
not expose the SAP Business System(s) directly to the Internet ?
You could do classical custom Java JCo development on the Portal and create your own interfaces from the Portal towards
the SAP backend business system using JCo’s and RFCs and therefore keeping the SAP Portal as the Proxy and abstracting
the connection between Portal and SAP backend Business System from the User and Internet perspective.
What about an ABAP CE ?
Another alternative would be to install a vanilla ABAP Stack as a sort of ABAP CE.
An ABAP Composition Environment for Composing ABAP Compositions and Web Interfaces
written in ABAP WebDynPro and interfacing and integrating with further SAP Business Systems
behind the ABAP CE system.
This approach would mean that the backend for example SAP SCM/SNC SAP Business System is not
exposed directly to the Internet.
The ABAP ‘CE’ acts as the Proxy and abstracts the communication between the ABAP CE and
the SAP Business Suite System beyond.
The ABAP CE could be used for Composing in ABAP WebDynPro Interfaces towards SAP Business
Suite Systems where a SAP Portal Business Package written in Java WebDynPro or Java Jco is not
The question with both of these alternatives is money, the money argument is mitigated by the security
risk, the security risk dictates how much $$$ to spend on securing the solution.
What does everybody think, assuming we are at a SAP Customer, where the security risk of exposing
for example SCM/SNC backend SAP Business System is not acceptable and provides the lever for
the availablility of investment $$$ for an alternative solution, what do you think ?
What other alternatives are there when sticking as close as possible to SAP Products and securing critical
SAP backend systems towards the Internet, by not opening Internet Firewall Ports directly to critical
SAP Business Systems ?
Looking forward to feedback and an interesting discussion.
Update: 18th October 2013
Further research into the possibilities for securing WebDynPro ABAP applications towards the Internet,
has turned up some interesting documentation on SAP Product Lifecycle Management.
There is a scenario in SAP Product Lifecycle Management which involves an Internet facing User Interface
for external business partners to access the system written in ABAP WebDynPro.
The SAP document (OSS User required)
describes a landscape architecture in the scenario where you want to grant access to external users
because you cooperate with business partners, where SAP recommends the installation of an
additional SAP ERP6 EHP6 with PLM activated in a demilitarized security zone DMZ (Page 19
The SAP document
describes in detail how the SAP ERP PLM business system in the DMZ will cooperate with the
master SAP ERP PLM business system in the intranet and how RFC is used between the two,
therefore making the DMZ SAP ERP PLM system the proxy and stopping Internet based Users
getting a direct connection to the intranet SAP ERP PLM system.
We have been thinking about designing such an architecture, and it is nice to see it in print in a
SAP document including the practicalities of how to operate it.
Again, it is a question of money, but, the nice advantage of this solution is that there is not
custom coding involved, therefore reducing the cost of maintenance, operation, and upgrades.