In the past few years, there has been a rapid change in the technology and the user requirements. There is a new generation of users demanding modern user experiences, thus making User Experience being a driving factor for the success of any product. So, to address these modern needs of better User Experience, SAP has come up with all new SAP Fiori Launchpad that can host all new SAPUI5 Applications.

SAP Fiori can be considered as a new-age, light weight Enterprise Portal which hosts a number of apps on one screen, subdividing the complex underlying SAP applications into role-based SAP Fiori apps with the aim improving user friendliness while also enhancing the user experience. A rising number of companies are considering implementation of SAP Fiori apps and are now faced with determining which authorizations must be allocated to their employees for access to the app.

Basic Elements of Fiori

Before we delve deeper into the SAP Fiori and Security concepts, it is very important to discuss and understand some building blocks of Fiori. Some basic building blocks and terms which are used frequently in Fiori world are:

• Tiles – Tile is a visual representation of an app on the launchpad home page. When user clicks on a tile, an intent (Semantic Object + Action) is triggered, configured app is opened
• Catalogs – A catalog is a set of apps you want to make available for one role. Depending on the role and the catalogs assigned to the role, users can browse through the catalogs and choose the apps that they want to display on the entry page of the SAP Fiori launchpad
• Groups – A group is a subset of apps from one or more catalogs. Which tiles are displayed on a user’s entry page depends on the groups assigned to the user’s role. In addition, the user can personalize the entry page by adding or removing apps to pre-delivered groups or self-defined groups
• Launchpad – SAP Fiori Launchpad is known as the entry point to Fiori apps. Consider it as the new age enterprise portal which hosts SAP Fiori tiles (apps) which run on multiple device types and provides a single point of access for business applications such as transactional, analytical, factsheet, smart business apps

 Category of Fiori Apps

Fiori apps are divided into three categories. This division is mainly based on what you are trying to do with the app. Are you executing a transaction to achieve a result? Or do you want to search an employee number or a GRC request number.

• Transactional Apps – To achieve or complete a transaction in an underlying SAP system
• Fact Sheet App – Used to search or navigate an object
• Analytical App – Graphical representation of data on a Fiori app

Relationship and Mapping of key Fiori objects

A user receives the access to Fiori tiles through a role. A role is a same PFCG role as present in other ABAP systems like ECC. However, the major difference is that the apps in Fiori system does not have Transaction codes. While a typical ECC role looks like a collection of Tcodes and associated authorization objects, Fiori role is a collection of one or many Catalog, Groups and associated services. An overall mapping of these object folds onto a role and then role is assigned to a user. Below diagram gives the flow and mapping between these objects

A user can see a Tile on his Fiori launchpad only when this tile is present in both in catalog and group, and these catalog and group are in turn added onto a role which is assigned the user.

So if we have to draw this, the scenarios will look like:

Tile is Not in Group but in Catalog = Hidden

Tile is in Group but not in Catalog = Error

Tile is in Group and in Catalog = Visible and works

Fiori On-Premise vs On-Cloud

With the advent of SAP Digital Applications and cloud, many customers are moving the essential features of their technical landscape to cloud including the front-end Fiori apps. It becomes important to understand the difference between Fiori on-premise vs. Fiori on-cloud. This is because some of the underlying architectural concepts change with this transition.

On-Premise Architecture

In the on-premise scenario, an SAP NetWeaver Gateway is required to call SAP Fiori applications. Here, the necessary files are retrieved from the SAP NetWeaver Gateway. These files form the so-called user interface (UI) of the SAP Fiori application and are based on SAPUI5. In addition, SAP Fiori applications use the OData protocol to call business data from the linked backend system. After all, without data, a SAP Fiori application is an “empty shell”; the application must be connected to a back-end system that feeds it with data. To call OData services in an on-premise scenario, SAP NetWeaver Gateway system is required. It supports the so-called CRUD concept (Create, Read, Update, Delete) to provide the application with data, or to perform certain actions in the back-end system. Consider, for example, the creation of a purchase order, or the approval of an invoice. When in a certain SAP Fiori application the “Approve” button is pressed, this approval is processed via an OData call in the underlying backend system. Every SAP Fiori application has an OData service, which can be registered on the SAP NetWeaver Gateway system. Without this Gateway registration, the OData service can not be called from the Fiori application. The external OData call is converted to a SAP-specific call via registration, for example a method in an ABAP class. Although every SAP NetWeaver system can function as an SAP NetWeaver Gateway system from 7.0 or higher, the deployment of an SAP NetWeaver Gateway system on-premise is an additional burden on the management of the system landscape. Consider, for example, the scenario for approving purchase orders. If this has to be done through the standard SAP Fiori application, a new SAP NetWeaver Gateway system must be set up for one relatively simple process / application in addition to the available SAP ECC system.

Hybrid Scenario and Architecture

If SAP Fiori is consumed from the Cloud, the need to set up an additional SAP NetWeaver Gateway system on-premise is no longer necessary. The role that the SAP NetWeaver Gateway system fulfills for making the user interface (UI) of the SAP Fiori application available can therefore be taken over by the SAP Cloud Platform. When using the cloud scenario, an SAP Cloud Connector must be installed. The SAP Cloud Connector provides the connection between the SAP Cloud Platform and the underlying SAP back-end system. In addition to consuming the UI from the SAP Cloud Platform, the OData services on the SAP backend still have to be registered so that they can be called from the SAP Fiori application. It is possible to opt for this registration to take place on the on-premise Gateway system, so that in addition to the SAP Cloud, an SAP NetWeaver Gateway system is still required. However, the on-premise Gateway is now only intended for the registration of the OData services and no longer for the UI section

Fiori Security Principals for On-cloud scenario

In an on-premise scenario, the SAP users of the SAP back-end system must be replicated on the SAP NetWeaver Gateway system. This therefore requires extra management work for the maintenance of employees within an organization. In the cloud scenario, no additional Gateway SAP users are needed, but the users need to be created in a connected identity provider in the SAP Cloud Platform. When SAP Fiori is used in the Cloud, SAP provides an identity provider that can be used for this purpose. However, the SAP Fiori cloud scenario is very well prepared to use the already available identity provider within an organization. Think of an Active Directory or Microsoft Azure solution, where a user for the SAP Fiori Launchpad logs in with his or her own e-mail address and password which is also used elsewhere (for example when logging in to the PC or e-mail account). This means that no additional SAP users need to be maintained and the already available identity provider of the organization can be used.

As far as user / identity management is concerned, two streams can be distinguished: a data stream and an authentication stream. It must be authenticated towards the linked identity provider (in the figure below this is an Active Directory), after which the data can be retrieved from the linked SAP backend system. The user established with the authentication is sent along with the data flow towards the SAP backend system.

Regardless which identity provider is chosen in the cloud scenario, the corresponding SAP user ultimately has to be logged into the SAP backend, for example to perform the approval of a purchase order under the right user in SAP. For this purpose use is made of the so-called “principal propagation“. A trust relationship is realized with certificates between the various components from the SAP Cloud Platform up to and including the SAP backend system. By means of so-called “SAML2 assertion” an attribute of the user on the identity provider linked to the SAP Cloud Platform is “propagated” towards the SAP backend system. In the SAP back-end system, this attribute ensures that the correct SAP user is logged in and takes action in the SAP back-end system.

To realize this, the following trust relations have been set up through certificates:

Identity provider <-> SAP Cloud Platform

SAP Cloud Platform <-> SAP Cloud Connector

SAP Cloud Connector <-> SAP backend system

It goes without saying that such a set-up to realize this required principal propagation requires a certain multidisciplinary effort, which is not necessary in an on-premise scenario. The big advantage, however, is that users experience the convenience of single sign on (SSO) : with their regular username and password within the company they can also use SAP Fiori, without having to remember separate SAP user names and passwords. Of course, such an SSO design can also be realized in an on-premise scenario, but is not required and is therefore less common. In addition, the on-premise scenario is not prepared in the same way or preconfigured on setting up a local identity provider such as the cloud scenario.