Technical Articles
Considerations and Recommendations for Internet-facing Fiori apps
As a UX specialist in the S/4HANA Regional Implementation Group team I’m privileged to work with many of our S/4HANA customers. Many of these S/4HANA customers are looking to drive the business benefits of S/4HANA by implementing Fiori at scale. A lot of them seek our advice on how to expose their Fiori apps to the Internet. While this provides the ease to start the Fiori apps without being on the company network or via VPN, it also creates a risk because it makes the involved systems reachable via internet and makes them more vulnerable. Therefore, customers have to make sure they are well protected against cyberattacks. Some customers are not aware of the essential considerations, so as a team, we have consolidated these into this single blog. We hope you find it helpful!
IMPORTANT: This blog only deals with Internet facing Fiori apps. If you want to run your Fiori apps on mobile devices there are additional considerations for Mobile device usage. Certainly also have a look at the Fiori Client and SCP Mobile Services.
IMPORTANT: The security recommendations listed below can help to reduce, but do not eliminate all the risks involved. This blog is intended for S/4HANA but other solutions like Fiori on ERP or Suite on HANA could reuse most of the recommendations.
Once you know if your Fiori applications will be hosted by systems located in the Cloud or On-Premise, you are ready to dive deeper into the considerations. I have focused in this blog on the On-Premise architecture. You’ll find a comparison with SAP Fiori Cloud and some additional information at the end of the blog.
UPDATE 24/6/2022: Added some considerations of running embedded and Hub together and BTP Launchpad service
UPDATE 30/01/2020: Added SCP Portal and API Management info
UPDATE 20/08/2019: Added new architecture slide. Added some more info on new tools supported only for embedded deployment. Added 1909 info on mobile device support. Removed Fiori Cloud section as this is not supported anymore in latest releases of S/4HANA, this is planned to be replaced by the SCP Portal.
UPDATE 12/11/2018: Removed architecture section as this is customer specific. And some smaller updates in other sections.
UPDATE 30/04/2018: The blog section “Choosing your Fiori Frontend Server Landscape Deployment Mode” has been updated with the general recommendation for SAP S/4HANA systems for an embedded SAP Front-end server deployment instead of a hub deployment.
After activating Fiori on your S/4HANA system or other SAP Solutions, you might want to enable your end-users to also access these Fiori applications directly from the Internet. We will call this in the rest of this blog “Internet facing Fiori apps“.
Architecture when your Fiori apps are hosted On-Premise
As always with On-Premise solutions you should pay attention to the general advice and recommendations detailed in the SAP NetWeaver Security Guide. However, there are some additional considerations when providing Fiori apps on the Internet.
In the figure below the typical layers of a DMZ are listed with the relevant solutions when Fiori applications are reachable via internet.
- Security Layer with a Web Application Firewall (WAF) and Identity provider (IDP)
- Presentation Layer with a SAP Web Dispatcher configured with Edge Authentication (optional)
- Integration Layer with a dedicated Fiori Frontend Server (FES)
Choosing your SAP Fiori front-end server Deployment Options
Embedded FES = general recommendation
The general recommendation from SAP for SAP S/4HANA systems is to configure an embedded FES deployment and not a hub deployment. More info on this in the blog on SAP Fiori Deployment Options and Recommendations. An important limitation is that having multiple SAP S/4HANA systems with different releases (eg. 1610 and 1709 together) connected to one FES system while sharing the same FLP is not possible.
However, with the embedded deployment option there is no separate FES sever in the DMZ. And when enabling internet facing Fiori apps, the SAP S/4HANA system is exposed more directly. Therefore, when choosing for this deployment option it is even more important to have a good firewall and network security in place. Some options and recommendations on how to do this are discussed later in this blog.
Central hub = exceptional, adds security but also extra costs
Depending on the existing system landscape and Fiori usage scenarios a hub deployment might be preferable for security reasons because the FES can be placed in the DMZ, providing an additional security layer by doing a protocol conversion (OData to RFC) and input validation of the incoming requests.
It’s important to be aware also of the functional restrictions of a central hub deployment. The new Fiori Rapid activation tools released December 2018 are only supported on the embedded deployment option.
Therefore, a central hub deployment will lead to an increased effort to setup and configure Fiori and also requires an additional server. It is up to the customer to decide if this extra cost is worth the additional security gains.
Note that these 2 deployment options can be combined however there are some considerations. The embedded FES could serve all apps while the internet facing central hub FES is only providing SAPUI5 apps.
UPDATE 24/6/2022: some considerations of running embedded and hub FES together
- Having the very same apps exposed on embedded FES and HUB FES might come with some trouble regarding Gateway configuration – the very same service using local Gateway and hub Gateway won`t be straight forward. Either you have to do some tweaking in the configuration or you deploy the apps twice (internal version, external version) each coming with dedicated OData services. And this will work for SAPUI5 based Fiori apps only, not classical UIs.
- Personalization and UX Key user adaptations are stored on the FES. Besides the redundant maintenance for admins and key users, end user must not come in via both (external/internal) channels because the experience might be different and they would have to personalize twice as well.
BTP Launchpad
UPDATE 24/6/2022: various updates
BTP Launchpad can be used as a central FLP for S/4HANA and other solutions both cloud and on-premise. This would be a more future proof architecture as the hub deployment should only be by exception.
You can configure via roles which apps can be accessed and in this way you can provide a subset of the S/4HANA apps via the BTP Launchpad service. The discovery page contains more information on pricing of this service and links to further documentation.
Considerations and Recommendations when exposing SAP Fiori apps to the Internet
There are multiple options for customers to bring additional security in their landscape when allowing Fiori applications to be reached via the internet.
Placing Your Firewall and Network Zones
A Web Application Firewall should be placed in front of the SAP Web Dispatcher, monitoring and controlling all incoming HTTP requests. These Firewall solutions have various security features protecting the systems behind against cyberattacks and establishes a barrier between a trusted internal network and the untrusted internet. Attacks like a Distributed Denial of Service (DDoS) should be stopped by the Firewall, so they cannot reach your SAP S/4HANA system.
You can also use a network security mitigation partner to route and filter the internet connections via their network before passing it to your organization.
Firewalls can also be configured with Edge authentication to block all non-authenticated requests.
Configuring Your SAP Web Dispatcher Routing
The SAP Web Dispatcher is needed for routing and distributing the network calls to the correct systems. It should only forward requests to services in the internet communication manager that are necessary to run SAP Fiori apps. In the UI Technology Guide, chapter 3.6.2.2 SAP Web Dispatcher: Setup of, where the latest recommended Web Dispatcher configuration is described.
The SAP Web Dispatcher together with SAP SSO 3.0 can be configured to only pass authenticated requests, in case this is not handled by your Firewall. For more info you can have a look at the SAP Single Sign-On Network Edge Authentication configuration documentation.
NOTE: You can also replace the SAP Web Dispatcher with a 3rd party reverse proxy if you have one already in your network infrastructure. Only for SAP CoPilot there is specific functionality built-in the SAP Web Dispatcher required for authentication.
Do not allow WDA and WebGUI apps
Take special care when allowing SAP GUI for HTML and WDA apps via Internet. If you do want to enable these via internet, make sure to regularly check and implement all related security notes. Implementing these might require some downtime of the backend S/4HANA system. See also one of the next paragraphs on Managing Your Security Patches.
You can use a separate SAP Web Dispatcher instance or different configuration for internal and external access. For internal access you could allow WDA and WebGUI applications, while requests coming from external can be denied WDA and WebGUI access.
NOTE: Using SAP Screen Personas on top of Web Dynpro for ABAP or SAP GUI for HTML is not overriding any security concerns. See SAP Note 314568 on Limitations / Restrictions / Behavior of SAP Screen Personas.
NOTE: SAP GUI for HTML and Web Dynpro for ABAP are not supported on all mobile devices or smartphones for releases until S/4HANA 1809, with the 1909 release some scenarios and devices are supported.
- SAP GUI for HTML. Extract from SAP Note 314568 on the functionality / Limitations / Sp. Behaviour of
- Web Dynpro for ABAP. Extract from SAP Note 314568 on the list of known Restrictions and Browser Support : No mobile device/ Smartphone support. Exceptions for iPad in newer Release
- New with S/4HANA 1909 : some devices/browsers are now supported : SAP Note 2700517 – Mobile device support for Unified Rendering based frameworks: Web Dynpro ABAP and SAP GUI for HTML
Encrypt all System Connectivity
When using non-encrypted network connections, the username and passwords and other sensitive network traffic can be captured by other parties.
Therefore, when enabling Fiori applications from the internet, you should always enable HTTPS end-to-end. Check the Web Dispatcher, NetWeaver ABAP Application Server documentation on how to do this.
After enabling HTTPS you should also prohibit any HTTP connection to your ABAP based systems. This can be done by removing the non-encrypted HTTP ICM services on ABAP Application Server like the SAP S/4HANA system, allowing only HTTPS connectivity.
Managing Passwords and Single Sign-On
Setup good password management, ensure users are required to use longer passwords including digits and special characters, and are prompted to change passwords regularly. Also look into Single Sign-On to enforce the same password management settings across all the involved systems. This can be achieved with technologies like Kerberos, SAML or X.509.
SAML is generally the preferred option for SAP Fiori as this integrates with the cloud solutions like SAP Cloud Platform.
NOTE: There are several solutions such as SAP CoPilot, SAP CoPilot which is provided via the SAP Cloud Platform is available since SAP S/4HANA 1709 FPS1 (on-premise).
SAP also has the SAP SSO and SAP Cloud Platform Identity Authentication solutions which can be used in this context.
Whitelisting ICF node and OData Services via Activation
Only activate the necessary ICF nodes and OData services for the Fiori apps you intend to use. Existing apps which are no longer in use anymore should be deactivated, eg. apps retired due to being replaced by a successor app as part of a release or feature pack upgrade.
Restrict the roles and authorizations of the end-users roles allowing only to what is strictly needed and in all environments available via internet. You can restrict the Fiori Roles via customizing Fiori Catalogs as described in Creating PFCG Role on Front End and Assigning Launchpad Catalogs and Groups and Creating PFCG Role on Back End for Launchpad Catalogs.
Managing Your Security Patches
When systems are reachable from the internet it is even more important to keep these up to date and all security patches should be implemented regularly.
As at time of writing this blog, every second Tuesday of every month is security Patch Day at SAP, where the SAP Product Security Response Team shares a montly summary on the the fixes for vulnerabilities discovered of the last month in SAP products. SAP strongly recommends that the customer visits the Support Portal and applies patches on a priority to protect his SAP landscape. This wiki page contains an overview of the past Security Patch day blogs.
You can implement security patch management with SAP Solution Manager and check the Early Watch (EWA) report to get an overview of the security patches to be implemented on your system. Also the Web Dispatcher can be included, this is described Security Patch Process FAQ.
Managing System Load (Load Balancing & High Availability)
When exposing Fiori apps to the internet, you are opening a channel which can be consumed by all the company’s users as long as they can authenticate to the system. This can translate in bigger system loads.
Therefore a correct sizing and architecture definition must be prepared from the start, considering Fiori will be the single point of access, as you don’t want to have a system-down scenario.
Make sure all systems involved are realistically sized, scalable (additional application servers or more hardware can be allocated) and are installed in a high availability setup.
Fiori Via VPN
Another option to allow Fiori from outside the company network is to use VPN. It is important to note that network response times are very important for the usability of SAP Fiori, so the VPN provider must be evaluated carefully.
… and More !
The SAP Mentors call and summary blog What you always wanted to know about SAP Security, but did not dare to ask! and linked recording contain a lot of good background information on how SAP handles security for its products and in the SAP IT Infrastructure and contains further considerations for customers, some of which have already been discussed above.
Thank you,
Hannes
Becoming a SAP Fiori for SAP S/4HANA guru
You’ll find much more on our SAP Fiori for SAP S/4HANA wiki
Brought to you by the S/4HANA RIG
Great collection of Documents and other Resources ...
Thanks Hannes,
With regards the architecture, what about on-premise (internal) access to SAP Fiori within the company? This is the main use case initially (laptops/desktops), with mobile access also to be provided.
From your blog are you suggesting a second Front End Server should be provisioned in the DMZ which only offers out the externally facing Fiori apps?
We are running S/4HANA 1610 and a FES in Hub mode.
Thanks
We are generally recommending embedded deployment. I just updated the blog with some more suggestions to make also that deployment option more secure.
Know that such a mixed setup with embedded + hub (only for internet facing) will greatly increase the effort for administration and customizing needed for Fiori, so this is not recommended.
Regards, Hannes
Hello.
What would be the best config for a Fiori URL on a replicated environment? Site A replicates to Site B. On failover, users need to access differente URL, or is it better to access using SAP GUI?
Hi Mauricio,
I think you could look into DNS Failover but this is not really the topic of this blog.
Regards, Hannes
Hi Hannes,
With SAP Gateway ABAP AS as UME for user authentication. How can we configure OTP?
Hello Hannes,
I am looking for recommendations regarding the follwing two options:
The most recommedations I read so far seperated always the backend from the frontend+webdispatcher, never only the webdispatcher from the rest. Are there any disadvantages in this scenario? From my opinion it would combine the advantages of the embedded scenario with a reasonable security concept.
This applies also for the second scenario where you of course would have additional efforts regarding the reverse proxy but this was also the case in former non-Fiori releases when you wanted to make web services of SAP applications available externally.
Am I overlooking an aspect typical for fiori applications/setups only?
Regards, Björn
Hi Bjorn,
Embedded deployment is the general recommendation As explained in other blog and linked document a central hub has disadvantages : more hardware needed, no support different S/4HANA releases, more complex architecture, ..
Also there are some Fiori activation tools recently released only working for embedded deployment, see notes: 2704570 - Composite SAP note: Rapid Activation for Fiori in S/4HANA 1809 and 2695653 - Composite SAP note: Rapid Activation for Fiori in S/4HANA 1709 .
For internet facing scenario we see that a good firewall with edge authentication is adding more security compared to a FES in the DMZ zone. Also Fiori Cloud could be a good option.
Regards, Hannes
Nice summary.
How do you think reverse proxy (like web dispatcher) in DMZ, and FES Hub in internal network?
Thank you Hannes for nice summary.
I need your help to clarify one thing about your updates highlighted below with bold and italics.
UPDATE 20/08/2019: Added new architecture slide. Added some more info on new tools supported only for embedded deployment. Added 1909 info on mobile device support. Removed Fiori Cloud section as this is not supported anymore in latest releases of S/4HANA, this is planned to be replaced by the SCP Portal.
Which 'FIORI Cloud' you are referring to here? There is a package on SAP Cloud Platform called 'FIORI Package on SCP', are you referring to that? Currently, we are on ECC EHP7 and planning to launch some FIORI Apps using 'FIORI Package on SCP' and i want to make sure that this is not something which is not supported in future as we are planning for S/4HANA also in upcoming years.
Thank you!
Best Regards,
Mandeepak
Hi Mandeepak, It is referring to the SAP Fiori Cloud service on SAP Cloud Platform. This one…
https://www.sap.com/australia/products/cloud-platform/capabilities/digital-experience.fiori-cloud.html
You are ok to use for ERP.
However for SAP S/4HANA the preferred approach is SAP Cloud Platform Portal Service which you can run as a SAP Fiori Launchpad. In this approach you still need a backend SAP Gateway or SAP Fiori frontend server - for SAP S/4HANA the recommended approach is to use Embedded mode. So your Fiori frontend server is part of your SAP S/4HANA system.
Btw embedded is recommended for a number of reasons, e.g. your SAP FIORI FOR SAP S/4HANA version and SAP S/4HANA version have a 1 to 1 relationship, you can still upgrade your FES (including SAP_UI component for your SAPUI5 version) as per https://blogs.sap.com/2020/02/17/sap-fiori-front-end-server-6.0-extended-maintenance-and-upgrade-recommendations/ and https://blogs.sap.com/2020/03/13/how-and-why-to-upgrade-sap-fiori-for-your-sap-s-4hana-solution/
You can also use the Portal Service as a central launchpad – which will be in Cloud Foundry.
Refer to
SAP Fiori Deployment Options and System Landscape Recommendations
Trust that helps?
Hello Hannes,
I've a client started a Fiori project but doesn't want to have a FES before back-end system for minimizing the cost.
A consulting company developing new applications for using Fiori Lunchpad.
The company recommended to use embedded gateway in back-end SAP ERP system to the client.
I think such an architecture may create a security risk for SAP back-end system.
But I was not able to find any official SAP document or an article that gives information about the risks of accessing to back-end via Fiori Lunchpad without an SAP FES.
There is no business scenario for accessing the system via internet or a mobile application for now but in the future most probably the users will ask for it.
I need information about the solutions that can only be implemented in FES but not in an embedded gateway of a back-end system for eliminating security risks.
I'd appreciate if you can give information or provide link of any document or blog for my question
Thanks and kind regards
Ayse
Hello Ayse,
Choosing for the embedded is the recommended option by SAP, certainly if there are currently no internet facing scenarios foreseen.
Regarding security I think this blog give you some ideas of the options to increase the security.
When internet facing requirements exists it would be an option to enable these via an external portal like SCP Launchpad. This way you can also provide a external launchpad with a limited set of apps (no SAP GUI for HTML and ABAP Web Dynpro) compared to the internal embedded lauchpad.
Hope this helps !
Regards, Hannes
Thanks Hannes
Regards
Ayse
Hello,
Thank you for this great blog, can you confirm that BTP Launchpad can be deployed in parallel with on premise FLP? So the on premise FLP would not be exposed on Internet and could have all the apps (SAPUI5, Web GUI, Web Dynpro) and the BTP Launchpad would consume only SAPUI5 apps. I believe then that the access to Web GUI and Web Dynpro would still be a security problem even from BTP Launchpad with SAP Cloud Connector?
Thank you.