In recent years, technology and user requirements have rapidly evolved, with modern users demanding better experiences. To meet these needs, SAP introduced the SAP Fiori Launchpad to host SAPUI5 applications, focusing on enhancing user experience.
SAP Fiori, a modern and lightweight Enterprise Portal, hosts multiple apps on a single screen, simplifying complex SAP applications into role-based apps. It improves user experience and enhances user-friendliness. As more companies implement SAP Fiori, they must determine the appropriate authorizations for employees to access the apps.
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. The Fiori world frequently uses some basic building blocks and terms.
- Tiles – A tile visually represents an app on the launchpad home page. When clicked, it triggers an intent (Semantic Object + Action) and opens the configured app.
- 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 their Fiori launchpad only when both the catalog and group contain the Tile, and the role assigned to the user includes this catalog and group.
So if we have to draw this, the scenarios will look like:
Scenario 1:
So, what do you think, what tiles will be visible to the user? Did you answer Tile X and Tile Y but not Tile Z? Your answer is absolutely…………………………. Incorrect
That is right. User will not be able to access these tiles. The reason is that there is something missing which you will find out soon
Summary: Tile X – Not Visible; Tile Y – Not Visible; Tile Z – Not Visible
Scenario 2:
What changed this time. As you can see we have assigned a group to this role. This group has Tile X only. While the Catalog has both Tile X and Tile Y. What do you think, the user will see this time? Both tiles? No. He will now see only Tile X but still cannot see Tile Y.
Summary:Tile X –Visible, working; Tile Y – Not visible
Scenario 3:
So you guessed it right this time. The user will be able to see Tile X and Tile Y. Bingo! And what did you say about Tile W? Will the user be able to see Tile W? Answer is YES! So user can see Tile W on his Launchpad BUT he will see an error on this tile. Tile W will show an authorization error
Summary:Tile X –Visible, working;Tile Y – Visible, working; Tile W – Visible, NOT working (error). So, it is easy to summarize as below:
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.
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.
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 you need to do this through the standard SAP Fiori application, you must set up a new SAP NetWeaver Gateway system for one relatively simple process or application, in addition to the available SAP ECC system.
Hybrid Scenario and Architecture
When consuming SAP Fiori from the cloud, you do not need to set up an additional SAP NetWeaver Gateway system on-premise. The SAP Cloud Platform takes over the role of the SAP NetWeaver Gateway system in providing the user interface (UI) for the SAP Fiori application. In the cloud scenario, you must install an SAP Cloud Connector.
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, you must register the OData services on the SAP backend to enable the SAP Fiori application to call them. You can choose to register these services on the on-premise Gateway system, which would still require an SAP NetWeaver Gateway system in addition to the SAP Cloud. However, the on-premise Gateway is now used solely for the registration of the OData services and no longer for the UI section.
Fiori On-cloud Architecture
In this scenario, you only need to have the OData service present on the on-premise SAP backend system, without requiring an SAP NetWeaver Gateway system for OData service registration. This eliminates the management costs of maintaining an SAP NetWeaver Gateway server. By registering through the OData provisioning service on the SAP Cloud Platform, the Fiori application routes OData calls to the relevant back-end system where the OData service is available.
Fiori Security Principals for On-cloud scenario
In an Active Directory or Microsoft Azure solution, a user logs into the SAP Fiori Launchpad using their own email address and password, which they also use for other purposes, such as logging into their PC or email account. This eliminates the need to maintain additional SAP users and allows the organization to use its existing identity provider.
In user and identity management, two streams are distinguished: a data stream and an authentication stream. The system authenticates the user through the linked identity provider (as shown in the figure, this is an Active Directory), after which it retrieves the data from the linked SAP backend system. The system then sends the authenticated user along with the data flow towards the SAP backend system.
In the cloud scenario, regardless of the chosen identity provider, the SAP user must log into the SAP backend to perform actions, such as approving a purchase order under the correct user in SAP. “Principal propagation” is used for this purpose. Certificates establish a trust relationship between the various components, from the SAP Cloud Platform to the SAP backend system. A “SAML2 assertion” propagates a user attribute from the identity provider linked to the SAP Cloud Platform towards the SAP backend system. In the SAP backend system, this attribute ensures that the correct SAP user logs in and takes action.
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
In a cloud setup, principal propagation requires a multidisciplinary approach, unlike on-premise scenarios. The key benefit is the convenience of Single Sign-On (SSO), allowing users to access SAP Fiori with their regular company credentials. While SSO is possible on-premise, it’s less common and not preconfigured like in cloud environments.
