Skip to Content

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“.   The term “Internet-facing Deployment Security” is also used in the SAP Best Practices Guide: SAP S/4HANA Fiori Advanced Network and Security Configuration (MAB) .

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 does makes the different systems involved vulnerable for cyberattacks.   Often 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 have a look at the Fiori Client.

IMPORTANT: The security recommendations listed below can help to reduce, but not eliminate, the risks involved.   This blog focusses on 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.

TIP: I have focussed 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.

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.

Choosing your Fiori Frontend Server Landscape Deployment Mode

UPDATE (30/04/2018): There are 2 deployment options for the Fiori Frontend Server (FES): embedded and central deployment.  Both options have their advantages, the general recommendations, as detailed in the  SAP Enterprise Architecture Explorer, is to use the embedded deployment option and not have a separate system for the Fiori Frontend server.

IMPORTANT:  When you are enabling your Fiori applications via the Internet the central deployment option could also be considered by customers because of the additional security layer this provides. If you choose to use an embedded FES, there is no separate FES sever providing the Fiori apps and therefore the backend is exposed directly from the internet, making it vulnerable for cyber attacks.

UPDATE (30/04/2018): The general recommendation from SAP for SAP S/4HANA systems is to setup an embedded FES deployment instead of a hub deployment, see blog on SAP Fiori Deployment Options and Recommendations.  Having multiple backend systems with different S/4HANA releases (eg. S/4HANA 1610 and 1709 together) and one hub FES is not supported.

Nevertheless, dependent on the existing system landscape and usage scenario a hub deployment in some cases might be preferable.  The security considerations described in this blog on the embedded deployment are still valid and for customers with high security requirements, a central hub will be the preferred deployment option.  When such customer has a multiple backends with different S/4HANA releases, a landscape is possible where every S/4HANA system has its own FES system.  Of course this has other drawbacks like increased complexity, higher maintenance, higher TCO, …  This could also be an additional reason to look into the SAP Cloud Platform option to host your internet facing Fiori apps, see the last section of this blog.

Deploying Your Fiori Landscape in Hub Mode

In the diagram below the general Fiori architecture using On-Premise systems is shown. Clients like a web browser, SAP NetWeaver Business Client or the SAP Fiori Client mobile app are connecting to the Fiori Frontend Server (FES) which is providing the Fiori Launchpad and Fiori Apps.  These connections are made using the HTTPS network calls and routed by the SAP Web Dispatcher.

Diagram: General Architecture for external facing SAP Fiori apps

The Fiori name is often (incorrectly) used as an umbrella for different application types covering both SAP Fiori apps, and Classic UIs with the Fiori Visual Theme applied.  From SAP S/4HANA 1610 these can all be started from the Fiori Launchpad.  The 3 different application types are :

  • SAP Fiori Apps built and running with SAPUI5. These include transactional and analytical apps. These apps can be created via the Fiori Elements framework or freestyle developments using HTML5, JavaScript and the SAPUI5 libraries.
    • You can expose these SAP Fiori apps  to the Internet provided you take the necessary precautions.
  • Classic Transactions using SAP GUI for HTML or WebGui with the Fiori Visual Theme applied
    • Enabling these from the Internet exposes your backend system, this is not recommended and therefore indicated with a red cross in the diagram.
  • Classic ABAP WebDynpro apps with the Fiori Visual Theme applied
    • Enabling these from the Internet exposes your backend system, this is not recommended and therefore indicated with a red cross in the diagram.

NOTE: The Fiori Visual Theme itself has no impact on this recommendation.

Depending on the app type the different requests are redirected to either the Fiori Frontend Server (FES) or backend (e.g. S/4HANA Core Server).  For WebGui and ABAP WebDynpro apps a direct connection to the backend is needed. 

IMPORTANT: Of course if you have chosen to use embedded mode for your Fiori Deployment Landscape then all apps are directly connected to the backend (e.g. S/4HANA Core Server).

The FES is hosting application resources for the Fiori Launchpad and Fiori Apps.  Fiori Launchpad Tiles and Fiori apps will send OData calls, requesting information from the backend.

OData (Open Data Protocol) is an Open protocol, sharing similarities with JDBC. OData uses HTTP messages on the network layer alongside Atom standards, JSON (JavaScript Object Notation) and XML data formats.

The FES will interpret these OData calls and is using RFC (Remote Function Call) calls to retrieve the information from the backend.  In this way there is also a protocol transition made in the FES from HTTP to RFC.

RFC is a proprietary SAP protocol.  Trusted RFC on the diagram indicates  that the authenticated user making the OData call is propagated via the RFC connection to the backend.

More on SAP Fiori architecture is described in the blog Updated SAP Fiori Architecture deep-dive with Focus on S/4 HANA and the attached document.

Considerations and Recommendations when exposing SAP Fiori apps to the Internet

All of the following recommendations assume that you are using a Hub mode architecture.  That is, all the involved systems like the Reverse Proxy, FES, backend or are residing in the customer or hosting partner (this could also be the SAP HEC) network as described above.

Placing Your Firewall and Network Zones

A 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 untrusted internet.

You typically place your Fiori Frontend Server (FES) in a Demilitarized Zone (DMZ) to support providing internet-facing services.  This DMZ zone should also be shielding the systems not directly facing the Internet, such as the backend (e.g. S/4HANA Core Server) , behind another Firewall.

If the threat for Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks is perceived as high you could also decide to use a mitigation partner who can route and filter the internet connections to their network before passing it to your organization.

Configuring Your SAP Web Dispatcher Routing 

The SAP Web Dispatcher is needed for routing the network calls to 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 Routing Rules for SAP Web Dispatcher and ABAP Front End,  the latest recommended Web Dispatcher configuration is described here.  The current recommendation is to forward /sap/bc, /sap/public, /sap/opu URLs to the FES.  Other endpoints should not be forwarded to the FES.

NOTE: You can also replace it with another reverse proxy if you have one already in your network infrastructure. The UI Technology and SAP Best Practice Configuration guides however only describe the configuration for the SAP Web Dispatcher so if you use a different reverse proxy you will have to translate these to your chosen reverse proxy.

NOTE: InA Search Request calls can, since S/4HANA 1709, also be routed through the FES instead of forwarded to the backend, see SAP note 2356997.  For this you additionally need to configure the endpoints /sap/bw/ina in the SAP Web Dispatcher.

Native Fiori apps use OData calls to retrieve their information from the backend.  These calls are interpreted by the FES and use another protocol RFC to the backend.  This is providing an extra layer of security protecting the backend system.

Prevent Direct Connections from Your SAP Web Dispatcher to Backend Server

Application types SAP GUI for HTML and ABAP WebDynpro require a direct connection to the backend (e.g. S/4HANA Core Server).

When performing direct network calls there is no protocol transition in the FES, therefore allowing these applications types via the internet directly exposes your backend system. Allowing this increases the possibility of a cyber attack on your main S/4HANA System.  Make sure you are aware of this risk and make sure your Firewall is capable of blocking possible cyber attacks.

NOTE: Similarly care should be taken with Fiori Search InA Search Request calls on Business Objects in S/4HANA 1610 (or SAP AS ABAP NetWeaver 7.51) and below. From S/4HANA 1709 (or SAP AS ABAP NetWeaver 7.52), you should route calls through the FES instead of forwarded to the backend server, see SAP note 2356997.

NOTE: The SAP Web Dispatcher can be configured to allow these application types when reached from the Intranet and not from Internet.  You could use the same  or use a seperate SAP Web Dispatcherfor internal traffic, depending on ypur network architecture.

NOTE: Using SAP Screen Personas on top of ABAP WebDynpro or SAP GUI for HTML is not overriding any security concerns. See SAP Note 314568 on imitations / Restrictions / Behavior of SAP Screen Personas.

NOTE: SAP GUI for HTML and ABAP WebDynpro are also not guaranteed for use on mobile devices like smartphones.

  • SAP GUI for HTML.  Extract from SAP Note 314568 on the functionality / Limitations / Sp. Behaviour of :

    Browsers on the IOS or Android patform behave differently and lack essential features the like Java runtime, navigation concepts like right mouse click and double-click. Running transactions with SAPGUI for HTML is therefore not supported. There are SAP transactions that work, others that do not work

  • Web Dynpro 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 Releases

Encrypt the System Connectivity with HTTPS

When using non-encrypted network connections, the username and passwords and other sensitive network traffic can easily 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 FES and backend systems, allowing only HTTPS connectivity.

Managing Passwords and Single Sign-On

Setup good password management, e.g. ensure users are required to use longer passwords including digits and special characters, and 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 planned to be available for SAP S/4HANA 1709 (on-premise) in Q1/2018.

SAP also has the SAP SSO and SAP Cloud Platform Identity Authentication solutions which can be used in this context.

Web Dispatcher offers a feature called Network Edge Authentication that helps customers set up secure access to their internal systems using SAP SSO.

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 authorisations of the end-users roles allowing only to what is strictly needed. In the Fiori Frontend Server restrict the Fiori Tile Catalogs users can access as described in Creating PFCG Role on Front End and Assigning Launchpad Catalogs and Groups.

In the backend (e.g. S/4HANA Core Server) restrict access using Fiori catalogs and configure the authorization object S_SERVICE as described in 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 security patches should be performed 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 have can authentication 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.

… 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.

Alternative to On-Premise: SAP Cloud Platform for Fiori

An alternative for accessing SAP Fiori apps from the internet is via SAP Cloud Platform using the SAP Fiori Cloud service. With this approach the SAP Cloud Platform is the first line of defence and therefore not directly exposing the customer on-premise systems to the internet.

With SAP Fiori Cloud and the mobile services customers benefit from a cloud-based design-time and run-time environment for SAP Fiori.  The frontend user experience (UX) artefacts are managed by SAP (e.g. regular updates to applications, SAPUI5 libraries, SAP Fiori launchpad version, development Web IDE etc.).  The users access the content securely through SAP Cloud Platform and the cloud connector.

You may find this solution particularly interesting if you do not have other internet-facing solutions in place as yet (e.g. Firewalls or VPN).

The available SAP Fiori Cloud apps scope is documented in the SAP Fiori apps reference library which include now also a SAP Fiori Cloud filter showing the Fiori apps supported by Fiori Cloud, this number is rapidly growing!

More information on SAP Fiori Cloud can be found here:



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

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member


    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.


  2. Mauricio Zeledon


    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?


Leave a Reply