Alternatives For Securing Internet Facing SAP Applications
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.
Introduction:
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
backend.
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,
this very detailed guidance from SCN Rock Star Thomas Jung:
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.
This strategy is advocated here by one of SCN’s Portal Experts, Tobias Hofmann:
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
available.
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)
Master Guide: SAP Product Lifecycle Management (SAP PLM) 7.02 Using ERP 6.0 EHP 6.0
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
onwards).
The SAP document
EHP 7 for SAP ERP 6.0 – Operations Guide
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.
Best regards,
Andy.
.
Hello,
What is your pain point ?
Why I ask : solution have to be build case by case, but classical solution is using 2 level of firewall, 1rst for Portal, 2nd for WebDispatcher & CE, 3rd for backup, and Internet connection through a Proxy/Load Balancer
BR
Hi William,
the pain point is, vanilla ABAP WebDynPro interfaces in the Internet Facing Scenario, eg, SNC Partner Access, force the Enterprise to open firewall ports from the Internet all the way directly to the critical SAP Business System, in this case Supply Chain Management, and this represents a strategic High Risk Security Vulnerability which for companies can be unacceptable.
One has to wonder, if it is a deliberate strategy that FSCM Biller Direct has not moved to ABAP WebDynPro and has remained hosted on the SAP Portal as a Java Business Package using JCo RFC based connections to the critical SAP ECC Finance Business System. Because, should FSCM Biller Direct one day move to ABAP WebDynPro it will also necessitate the opening of firewall ports from the Internet directly to the critical SAP ECC Finance Business System and for most companies this will not be an acceptable strategy because of the security vulnerability it presents.
Therefore the question and point of this blog remains, what are the architectural alternatives to opening the firewall ports from the Internet directly to critical SAP Business Systems when ABAP WebDynPro is the vanilla web Interface.
Looking forward to your feedback.
Best regards,
Andy.
Hello Andy,
You have truly opened up the discussion(and minds ) regarding the application architecture.
If, it is recommended not to make use of WD ABAP for internet scenarios then we are left with option of UI5 and ( the orphaned), WD Java.
Keenly following the reply from SAP.
Thank you.
Regards,
Sharath
Hi Sharath,
it's not so much that SAP does not recommend to use WD ABAP for Internet scenarios, it is that Security Teams at multinational companies rule that the vulnerability and risk of exposing critical SAP Business systems directly to the Internet is too high, and therefore, SAP Architects at multinational companies have to find a way to meet Business Demands and Security Team's criteria.
WD ABAP and a Web Server on the Business System is or could be considered useful in the Intranet scenario, but still there needs to be an aggregator infront, to achieve the design elegance of one single url to access everything instead of publishing one Intranet Url for this system, one Intranet Url for that system etc etc. The aggregator being the SAP Portal.
Back to the Internet scenario and meeting the criteria of not exposing a critical SAP Business System directly to the Internet returns us to the options discussed in this blog.
If a SAP Customer follows the example given above for an ABAP CE, or, the SAP approved design as shown above in the PLM scenario and installing an empty PLM in the DMZ, the architectural design is still missing a content aggregator, a layer to enable one single url for all Internet Access to the critical SAP Backend systems.
That aggregator would be either another SAP Portal in the DMZ, or alternatively, an architecture which has not yet been touched in this blog, using the SAP Hana Cloud Portal as the content aggregator.
This blog discusses using the SAP Hana Cloud Portal as the content aggregator.
Best regards,
Andy.
Hello,
I don't understand why you have to open your network.
You can interface your WD ABAP JCO to a Web Dispatcher which are in a separate DMZ.
For me the traditional DMZ design is :
User --> Load Balancer (SAP or not SAP) --> | DMZ | --> SAP Portal --> |DMZ| --> SAP WebDispatcher --> |DMZ| --> SAP Backend
Regards
Hi William,
ABAP WebDynPro User Interface applications run on the critical SAP Business system backend.
Consequently unless you implement the strategy described in the PLM solution in the blog, you will have no choice than to open FireWall Ports all the way to your critical SAP Business System backend.
Best regards,
Andy.
I'm with William NICOL - why doesn't web dispatcher work for this? You have to expose the web dispatcher host to the outside world, at least the http/https ports, but access to the ABAP stack comes only from the web dispatcher host and not from the end user client machine. Or have I missed something?
Steve.
Hi Steve,
perhaps I am not phrasing this correctly, even with a WebDispatcher, and firewall ports aside, we are still directly exposing the critical SAP Business System to the Internet. That's the restriction, multinational company, strict security standards and Security Team do not allow the highest critical SAP Business systems to be exposed directly to the internet.
The WebDispatcher relative paths of the Urls are executing directly against the backend ABAP WebDynPro.
With Jco, the Portal provides a layer of abstraction towards the SAP Backend using jco rfc's as in the BD example.
With ABAP WebDynPro where the out of the box web ui is ABAP WebDynPro (eg HRxSS/SNC Partner Access etc) and not Portal Java Business Package and Jco, then the only way to achieve the layer of abstraction, that is, stop Internet connections from directly reaching the ABAP stack is to implement what SAP propose when exposing PLM to the Internet and having an empty PLM ECC in the DMZ for Internet access as described here and here.
This is the question and the point.
And this is very expensive.
Is there a magical cheaper way to achieve the same ?
If this blog and discussion can find that, it will be useful to the community as a whole.
And that is why the blog is here.
All the best,
Andy.
What I have in mind is this: http://help.sap.com/saphelp_nw70/helpdata/en/e9/3bb7f8f6ea4e938ef0b9687cbb6c14/content.htm
I'm obviously misunderstanding your requirement - how is what you want different from what is described on that page?
Steve.
Hi Steve,
you're not misunderstanding, this is a special case.
What's special is the ABAP WebDynPro nature of the Web UI applications being built and executed on the critical SAP Business System and accessible via http from the Internet and therefore without exteme care and proactive attention becoming vulnerable to malicious attacks from the Internet.
The UI ABAP WebDynPro application is called from the Web Browser and even with a Web Dispatcher to conceal the hostname and ports of the app server, the relative path of the url is still leading straight to the backend ABAP stack and being executed directly on the backend ABAP stack.
How to mitigate that risk where that risk is not acceptable ?
. Custom Java Jco development on an ETF Portal
. An 'ABAP' CE in the DMZ and custom ABAP WebDynPro ui development with rfc communication to the backend data.
. An empty ABAP stack in the DMZ like in the PLM example
etc etc ie, a layer of abstraction between the UI and the backend, which sorry to say, Portal Java Business Packages like Biller Direct 635 have built in.
Andy.
Ah! Now I think I've got it! I'm a bit slow today:-)
So it isn't just the network access you're wanting to prevent, but the direct access to functionality of any kind? You're looking for a WDA proxy, not a web proxy, in effect, right? You're looking for WDA stubs on the empty machine calling RFCs on the real ECC machine to get/set data? Or something like that. So the UI lives on the WDA proxy and not on the backend ECC machine.
I don't think there's a simple, quick or easy way to build such a thing, and if you're talking about standard SAP WDA applications I don't see how you can do it at all. It is an interesting idea, though. I've not heard of anyone wanting such a thing before, but I can see the attraction.
I guess if you were building your own app, you could use Gateway as the proxy...
Hi Steve,
exactly, now we're farming 🙂
And such a requirement is on my desk.
Interestingly, as I said, SAP offer such a solution design for exposing PLM to external partners, it's on page 19/20 of this document.
And the mechanics of it are described in this document and that is useful for everyone to know.
Yes once you get to the point of building your own custom apps, to achieve this goal then it opens a whole new can of worms for the technology selection - however in the large multinational there should be some standards and guidelines to start with, but if we need to I will take your input and examine the Gateway.
In the meantime if you happen to stumble across the holy grail cheap and quick and robust and secure and scalable and futureproof solution, just let me know.
All the best,
Andy.
Andy very intersting and I think very topical.
I don't claim to be an expert in the area
The risk of having to expose the FI / HR system to the outside world frightens me.
We pondered this when installing SAP E-Recruiting.
SAP's E-Recruiting "Fort Knox option" (their words not mine) - has a web dispatcher then an "external" NW stack with E-Recruiting serving up the WDA web pages, which then calls an internal NW stack with E-Recruiting acting as the internal backend.
The external calls to the web pages then make RFC calls across to the internal system to do the work.
We decided not to install the ERecruiting parts into our ECC system ( its is an option though ..) to ensure we kept things as separate as we could.
I guess this is not exaclty cheap - more layers to install and manage for us.
But it shows that a team in SAP has catered for the "Fort Knox" solution and provided configuation within E-Recruiting at least to allow separation of external web page from the backend system.
I guess this is all development work and adds to the solution cost.
As you have demonstrated not all SAP components folow the same development thought process.
Not sure if a hacker could crack the external WDA and use the RFC to make calls into the internal backend. But at least they are not hitting ECC in our set up.
It would be great to have a suggested standard architecture for web facing components.
perhaps with either a Portal or NW ABAP stack as the external point to deliver the web pages then RFC or Jco to the ABAP backend in ECC.
Then all web facing products could be developed to meet the architetcure.
Regards
Matt
Hi Matt,
thank you very much for taking the time to share your insight into "SAP's E-Recruiting Fort Knox" option.
Your insight is precisely why the new SCN NetWeaver Architecture Category which is here has been created, to provide a forum for like minded Architects to discuss and philosophise and share knowledge and engage to the benefit of all.
The architectural solution from SAP which you describe sounds along similar lines to the strategy for securing PLM for external Partner access described on pages 19 and 20 of this document.
Do you by any chance have a link to documentation for the Fort Knox scenario on SAP Market Place or SCN ?
I totally agree it would be great to have a suggested standard architecture for Internet Facing components and scenarios and even example template architectures, because every company every SAP customer is having to go through the same time consuming expensive process of researching, evaluating and designing the best which they can come up with.
One of my goals is that we the community build this up in the SCN NetWeaver Architecture Category.
Thanks and best regards,
Andy.
Hi Matt,
I have found the SAP doco on this, here are the links:
SAP Production Strategy for Large Enterprises discusses precisely the subject of security and putting an ECC xyz into the DMZ and even goes so far as to reference this OSS Note 1017866 Consulting Note: Candidates scenarios using WebDynPro ABAP
Best regards,
Andy.
Andy
The link we used for E-recruiting architecture at the time was
http://help.sap.com/erp2005_ehp_05/helpdata/en/48/7862d889dd501ae10000000a42189b/content.htm?frameset=/en/48/7a8518c12a06b2e10000000a42189b/frameset.htm
Just to clarify for E-Recruiting we have a NW stack with the E-Recruiting component installed rather than a complete ECC system - we try to restrict the number of functions we have in an external facing system to the minimum required.
I look forward to seeing more information in this Arctitecture area, thanks for your good work.
Regards
Matt
Hi Matt,
thanks for coming back and correcting/confirming what SAP advised and even more for the help.sap.com link.
This fills a lot of gaps on this subject.
I too want to see more in the Architecture way, I want to see more people blogging interesting things they have done with architecture and also putting architecture questions and discussions.
I am sure what you did with ECC is just the tip of the iceberg, so if you have time, write an architecture blog on some interesting architectural implementation you've done and what thre decisions points were and what the destination result was and how it was achieved at and why it was achieved at.
All the best.
Andy.
Hi Andy,
Late to the discussion but I wanted to counter the point you raised in your blog about exposing WDA to the outside world. In the presence of Reverse Proxy, that won't be the case as the Rev Proxy is intercepting all client requests, rewriting those with the correct URL for the backend system, and forwarding these requests to backend systems. The URL of the backend is only known inside the company DMZ layer, not outside. The execution of WDA and BSP pages will be on the backend system but again this is not exposed to the internet.
I am aware of the Fort Knox option due to experience with several E-Rec implementations. This is all fine and certainly a valid option. It is the same architecture with applications like SLC (Sell Side and Buy Side), and SRM ABAP coupled with SUS. So a minimalistic version of the backend application is exposed as a separate system to the outside world. This is certainly more secure as we now have added another security layer. In case of E-Rec, this layer is limited to processing on the front-end only as data resides in the backend system. In case of SLC, partial data resides on SLC Sell Side which is replicated with Buy Side.
However, the orignal premise that internal backend system need to be exposed to the internet even in the presence of Reverse Proxy is not correct in my view. Happy to be corrected on that.
Regards,
Shehryar
Hi Shehryar,
thank you for your detailed feedback and contribution to this discussion and sharing your thoughts and experience.
I am not sure if anybody is correct, in this area of securing SAP where the boundares are constantly moving.
My main point on ABAP WebDynPro is:
. Basically, ABAP WebDynPro means there is a WebServer on the critical SAP Business System, which means that HTTP/S requests are getting from the Internet all the way to the critical SAP Business System
consequently, this opens vulnerabilities, because, by the very nature, the intruder has made it all the way to the backend critical SAP Business System
. Having the Presentation WebSite layer on a separate system, infront of the critical SAP Business System, eg the classical SAP Portal
and then, having a classical architecture, like Biller Direct, where there is a SAP Portal Business Package, which uses Remote Function Calls to call business logic in the ECC Finance critical SAP Business System
means, that the SAP Portal is a layer of abstraction and abstracts the UI away from
the critical SAP Business system and means that Internet traffic end their journey at
the SAP Portal and interaction between Portal and SAP backend continues at a
different layer, RFC, or other service technologies
These days, a Web Dispatcher to disguise host names, and SSL, these two alone are not enough, there are many many layers of security vulnerabilities which needs to be remediated in concert and not in isolation and failing to remediate one of the layers of vulnerability makes the rest of the investment redundant.
Looking forward to your feedback,
Kind regards,
Andy.
Hi Andy,
Thanks for the response. Sorry, I didn't mean to prove you or myself correct or incorrect. I just wanted to challenge my own thinking as I am currently architecting a landscape including Sourcing, SLC, MDG, SRM, Portal, PI, and ERP systems, some of which will be internet facing.
I totally agree with the point that Portal, or a 2 tier config like suggested for PLM, E-Rec, SLC, etc is more secure as there is phyical separation between layers of interaction and layers of execution. In fact, I am inclined towards having a hybrid landscape by using something like SAP Cloud Portal aaS, Ariba Supplier Portal, or other 3rd party portals purely for initial vendor interaction in our case. Once the vendor is confirmed as suppliler or bidders, we can move them to internal systems like Sourcing and SRM for Rfx activities. This is one of the ways of hiding our internal systems from general public and only allow validated business partners to access our systems through pre-defined comm channels. I am sure other approaches exist as well.
The key thing is to balance the cost/complexity of final solution vs maintainability/ease of use. Troubleshooting old Java based ESS/MSS applications used to be a nightmare given all the different development layers. So SAP decided to move away from that approach and redevelop based on WDA. The Portal business package is still there to call the backend but the application execution only takes place on the SAP HR system. This is simpler to deploy and easier to maintain when compared to old approach. But it does mean that focus for security changes towards hardening the Internet facing layers if ESS/MSS is enabled for internet access.
Still, I am standing by my point that introducing a Reverse Proxy like Apache or Web Dispatcher actually breaks the direct link between internet based client and backend system. The Reverse Proxy, as in cases of SSL termination and/or re-encryption, goes beyond typical redirection and actually brokers the interaction between client and server through URL rewriting. Hence, Reverse Proxy becomes the client for the backend system on behalf of internet based user. This approach is similar as in case of Portal acting as the broker and making the calls to backend system on behalf of client. The layer at which it happens is certainly different as Reverse Proxy is acting at Transport Layer while Portal at App Layer. However, the end result is the same which is that backend system is only known to the DMZ layer next to it and not beyond. This addresses the concerns around exposing backend system to the internet.
My 2 cents.
Regards,
Shehryar
Hi Shehryar,
sounds like you have an interesting project.
Very interesting to see you are also thinking about using the Hana Cloud Portal as an entry point for certain scenarios, you might be interested in this blog where I explored the concept of using the Hana Cloud Portal as an entry point from the Internet.
It is nice to see somebody else having these thoughts. Our friends, The specified item was not found. and
Thomas Hensel should keep an eye on this.
I disagree that the a reverse proxy like Apache or Web Dispatcher breaks the direct link between the internet based client and the backend system, for a number of reasons, including this one:
A skilled attacker, knows about a vulnerability on the critical SAP ABAP Business System, eg, some SICF service which called with the correct parameters opens an opportunity to execute other functionality
The attacker, by having access to the Web Server on the critical SAP ABAP backend system, enters a URL including the URL parameters, XSS/scripts which he needs to activate the vulnerability which he knows about on the critical SAP ABAP backend.
If, on the other side, there was a physical layer of abstraction between the critical SAP ABAP backend and the Internet, eg, a Portal or other system, then, such an attack would not be possible, or more difficult to the power of n.
For the Intranet, ok, ABAP WebDynPro's are acceptable, from the Internet, in critical solutions like the ones you are describing, Sourcing and Biller Direct etc, then I am from the school of thought that an abstraction layer is best practice.
Best regards,
Andy.
Andy,
Was your organization able to figure out how to provide SAP SNC partner access conforming the standards your organization has? we are having similar challenge where what SAP provides and our company's security standards do not match.
Hi Devang,
I've implemented SNC Partner Access at two companies.
Both times we have gone a long way in the direction of laying on top of the solution Web Access Management (eg SiteMinder - which bugs me that SAP have not yet got the message to bundle and market the Hana Cloud Portal and Hana Cloud Platform as a Web Access Management Solution) ), Internet Facing Portals, reverse proxies etc going through to Internal SAP EP's and finally right at the back the SNC Abap WebDynPro web pages with single sign on all the way through.
Best regards,
Andy.