by Alessandro Banzer, Xiting SAP Fiori 3.0 is the latest user interface (UI), or user experience (UX), from SAP to replace traditional UIs like the SAP GUI. With SAP Fiori 3.0, SAP provides applications by using cards (formerly called tiles) to encapsulate standard business tasks, such as approving purchase requisitions, displaying sales orders, etc., through role-based SAP Fiori apps. SAP Fiori is available for most SAP software products, such as SAP ERP (ECC), SAP S/4HANA, SAP Ariba Mobile, SAP Hybris Cloud for Customer, SAP SuccessFactors, etc. utilizing the latest in-memory computing technology with the SAP HANA Database. To use SAP Fiori, the end-user must have proper authorizations to the applications and underlying business data. In addition to app-specific authorizations, the end-users also need certain general authorizations for the front-end server and back-end server. These authorizations are required to run the SAP Fiori launchpad, to trigger the OData services required for the SAP UI5 applications, and to run, e.g., analytical SAP Fiori apps launched by using a KPI tile. Role administrators must maintain SAP Fiori authorizations in transaction code PFCG, similar to traditional ABAP authorizations. Before we get into the details of authorizing SAP Fiori apps, we need to get a general understanding of the architecture.

SAP Fiori Architecture and Deployment Scenarios

The architecture in every SAP Fiori installation includes the SAP Fiori Launchpad (FLP), the SAP Web Dispatcher, as well as the SAP Frontend Server (FES) and the SAP Backend Server (BES), as shown in Figure 1. The SAP Fiori Launchpad and the SAP Web Dispatcher run on the SAP Frontend Server. SAP Fiori can be deployed in two different scenarios — an embedded or a central hub deployment. In an embedded deployment scenario, the frontend and backend servers run on the same instance, whereas in the central hub scenario the frontend and backend server are physically separated and connected through a remote function call (RFC). The backend server (BES) can be any type of an SAP system like an SAP NetWeaver ABAP installation (e.g. SAP S/4HANA or SAP ERP). Figure 1: SAP Fiori Architecture   In the early stages of Fiori, SAP recommended the central hub scenario but revised the recommendation with later releases. Nowadays, SAP recommends the embedded scenario whereas the frontend and backend server are located on the same system. The main drivers for using the embedded scenario are better upgradability with new releases, and lower cost by reducing the number of systems required. Regardless of the deployment scenario, your end-users require authorizations for both the frontend (SAP Fiori Launchpad, Cards, etc.) as well as the backend server (oData services). Figure 2 demonstrates the flow of authorization checks that must occur. In an embedded scenario, you can build the frontend and backend authorizations into one role. Contrary, in the central hub scenario, you have to build two roles — one for frontend authorizations on the frontend server, and one for backend authorizations on the backend system. From an SAP security perspective, the end-user needs the proper authorizations to start an application (card) in the SAP Fiori Launchpad by having authorizations to the corresponding Fiori Group and Catalog on the frontend server. That ensures that the Fiori Application can be executed in the SAP Fiori Launchpad and call the OData service on the backend server. On the frontend server, you have to build a PFCG role that contains and authorizes the group, catalog, and frontend OData services (object IWSG). On the backend server, you have to authorize the catalog, the backend OData services (object IWSV) as well as transactions, web dynpros, etc. and the authorization objects required in the back-end role. Figure 2: SAP Fiori — Flow of Authorization Checks  

SAP Fiori Authorizations

The end-user requires basic authorizations to start and use the SAP Fiori Launchpad. SAP delivers predefined role templates for end-users as well as for administrators. The roles are SAP_UI2_USER_700 for end-users, and SAP_UI2_ADMIN_700 for administrators. However, we recommend building custom roles for your end-users with the authorizations listed in Table 1. SAP standard roles should not be assigned to productive users and hence it’s recommended to build a custom role. Table 1: Recommended authorizations   Note: In a central hub scenario, your back-end authorizations require authorization objects S_RFC and S_RFCACL to enable access to the backend server via a trusted RFC connection. Remember, when using trusted RFC connections the user IDs need to be identical on the frontend and backend server. Also, for S_RFCACL add the SIDs and clients from all the frontend-servers (DEV, QAS, PROD) specifically instead of an asterisk (*). Figure 3 shows the Fiori Launchpad when properly authorized. In addition to the basic authorizations to start the Fiori Launchpad, users require app-specific authorizations through so-called catalogs and groups. The catalogs carry the authorizations to an application, whereas the group displays the applications on the end-user’s home screen in tabs. Figure 3: Example of the SAP Fiori Launchpad   When building Fiori roles, it’s important to build them through the role menu to take advantage of the authorization proposals from transaction SU24. SAP delivers SU24 authorization default values for the backend services and so we recommend applying the same security principles as you would for your ABAP tcodes to leverage the proposals from transaction SU24. This approach not only helps you in building the roles initially, but also to maintain a sustainable role design going forward.

SAP Fiori Apps Library

The SAP Fiori Apps Library (Figure 4) offers an excellent overview of and insights into the available Fiori applications. It’s a great starting point to explore new apps and to learn how to correctly authorize them. The SAP Fiori Apps Recommendation service allows you to upload historical usage data (e.g. ST03N) to see which Fiori applications can possibly replace or enhance the legacy transactions your users have used in the past. For example, you can search for legacy transaction VA01 and the app library will show you available Fiori apps that can replace parts or all of the transactions’ functionality. Figure 4: SAP Fiori Apps Library   You can use automation tools to perform this mapping task directly inside of your SAP system. In addition, the Apps library provides you with implementation details of all applications. In the tab Implementation Information > Configuration, you can see the OData services as well as the pre-defined catalog and role that SAP delivers. Such templates enable you to test new roles in a sandbox environment without having to build out authorizations manually first. Before you implement app-specific authorizations, make sure that the frontend and backend components in your SAP system have the required patch level and that the relevant SAPUI5 Fiori applications and OData services are activated.

SAP Fiori Catalogs vs. SAP Fiori Groups

SAP recommends a role design for SAP Fiori authorizations based on the defined catalogs and groups in the Fiori Launchpad. Such a catalog usually contains a set of apps and services that are relevant for a specific user group. If a role has been authorized for one or more catalogs, the corresponding catalogs and groups are only displayed for the authorized users when the Fiori Launchpad is started. This ensures that each user only sees the apps they require. A catalog contains Fiori applications for a job function (e.g. Sales Manager) and is similar to a business role. A catalog can have one or more Fiori Apps. The group defines the view of the Fiori Apps in the Fiori Launchpad. The creation of groups is based on business requirements and could, for example, follow a task-based approach. You can create multiple groups per job function. A group contains applications from one or more catalogs. For example, the catalog “Sales Manager” contains four applications which are then separated into two groups (e.g. Reporting and Internal Sales, as shown in Figure 5). Figure 5: SAP Fiori Catalogs and Groups   You can build catalogs and groups on the frontend server in the Fiori Launchpad Designer. It is important to understand that in order to get authorized for the group “Reporting,” the end-users need to be authorized for the catalog(s) that carry the applications of the group “Reporting.” In the example shown in Figure 6, that means that you have to authorize the catalog “Sales Manager” which will also authorize two more cards which are not present in the group “Reporting.” The end-user will not see the cards on the Fiori Launchpad by default, but can find the cards through the so-called “App Finder.” Hence it’s important to understand that when you authorize a catalog, all the containing apps are being authorized regardless of whether they are in a group or not. When designing SAP Fiori groups, you can enable personalization for the end users, which means that when allowed, the end user can personalize the applications in the group (add, remove, move). The end user is only allowed to add or remove applications that he or she is authorized for through the catalogs. However, with the personalization enabled the end user can control the apps that are displayed for a group on the homepage. It is not always recommended to allow personalization as users might accidentally remove an application from the group and not know how to re-add.

Design Considerations for Catalogs and Groups

SAP recommends building groups that contain applications from a single catalog which means that in one group you only add apps from one catalog. SAP differentiates between Technical Catalogs and Business Catalogs. In the Fiori Apps Library, you can see the information for both catalog types. Technical catalogs start with the prefix SAP_TC whereas business catalogs contain the prefix SAP_*_BC. The asterisk is a placeholder that identifies the module the catalog is associated with. For example, SAP_FIN_BC would be a prefix for a finance catalog. SAP uses the technical catalog to group applications based on their component whereas the business catalog represents a job function. For example, the application “Create Sales Order” comes with the following catalogs:

• Technical catalog: SAP_SD_TC_T_X1
• Business catalog: SAP_SD_BC_FIELDSALESREP_X1

The technical catalog defines the applications which are from the same module, whereas the business catalog represents the job function Field Sales Representative and contains multiple applications that SAP groups for this very job. The business catalog might contain applications from various technical catalogs. When building your own catalogs (which is the recommended approach), you should always use the technical catalog as a reference and not the business catalog. Whenever possible, use the reference feature in the launchpad designer to make use of the pre-delivered configuration (learn more about how to reference applications in the next section, SAP Fiori Launchpad Designer). When building custom groups, always make sure that you include the apps from your custom catalogs and not from the SAP standard technical catalog. The best-practice approach to build custom catalogs and groups is to follow a job-based approach for your catalogs and then define the groups to display the applications on the users’ homepage. By doing that, you can specifically define what applications need to be authorized per job function through the catalog. Again, make sure that you add applications from one catalog into one group. On the other hand, if you design your catalogs as building-blocks (task-based approach), you increase the complexity in a similar way as you would when using composite roles in PFCG. For example, removing an application from a “building block” catalog that’s used in multiple groups impacts all of those groups — including those you might not even be aware of. Therefore, we recommend following a job-based approach for your catalogs and build the groups with applications from one catalog only.

SAP Fiori Launchpad Designer

The SAP Fiori Launchpad Designer is the main tool to create and maintain catalogs, groups, and cards up until SAP S/4HANA 2020. As of SAP S/4HANA 2020, the maintenance of technical catalogs will shift to the Launchpad App Manager (see next section). You can start the Fiori Launchpad Designer with transaction /UI2/FLPD_CUST. The Fiori launchpad designer is the standard tool for:

• Configuring the cards and its target mappings
• Creating pre-configured groups and catalogs
• Transporting the configurations (groups, catalogs, cards)

Within the Fiori launchpad designer, you can build and maintain your custom groups and catalogs. When building custom catalogs, always use the reference to the pre-delivered technical catalogs from SAP so that you don’t have to configure the application manually. To add applications to your custom catalog, simply drag & drop the applications from the technical catalog and create a reference. Note: The SAP Fiori Launchpad Designer, as well as the SAP Fiori Launchpad Content Manager, can be accessed in two scopes — cross-client configuration (conf), and client-specific customizing (cust) scope. In the CONF scope, the changes are done client-independent which requires a workbench transport, whereas the CUST scope requires a customizing transport as it’s client-dependent configuration. SAP recommends to perform the changes in the CUST scope and transport from one client to another, if required. In the view of authorizations, you build roles and authorizations client-dependent and hence we recommend to follow the same principle for the SAP Fiori content. As long as you don’t change the configuration of an application in your custom catalog, the reference to the original application from the technical catalog will remain intact. If you make a change, the reference will be broken which means that the application will still continue to work but you have to transfer potential changes to the application manually. SAP might change the configuration to the application in the technical catalog with the next support package which you then have to manually perform in your custom catalog. Therefore it’s recommended to keep the reference intact. If the reference is intact, the configuration will automatically be updated when a change to the technical catalog is being performed. Figure 6 shows an example of a technical catalog while creating a reference of an app. To create a reference simply drag & drop an application — left click with your mouse and hold so that the launchpad designer will show a pop-up dialog that allows you to create a reference. Figure 6: SAP Fiori Launchpad Designer — Create Reference   After adding the application to the custom catalog, you also have to reference the target mapping. Applications don’t work without the target mapping which holds the configuration of the application. To create the reference of the target mapping, simply go to the Target Mapping tab and select the one you want to use and choose Create Reference (Figure 7). Figure 7: SAP Fiori Launchpad Designer — Target Mappings   Interactive features, such as the ability to drag and drop elements, make the launchpad designer a straight-forward and easy-to-use tool for administrators. As a result, creating new catalogs or groups is as simple as entering a name (title) and a technical ID — similar to how you create roles in transaction PFCG. Once a catalog is created, you can easily add new applications through the referencing capabilities. Similarly, when defining groups you can select the applications from a catalog.

SAP Fiori Launchpad App Manager

As of SAP S/4HANA 2020, the maintenance of technical catalogs will shift to the Launchpad App Manager that you can start with transaction /UI2/FLPAM. The purpose of this tool is to manage all technical catalogs in one place, and supersedes the SAP Fiori Launchpad Designer. We will update this article as soon as the new tool has been released.

SAP Fiori Launchpad Content Manager

The SAP Fiori Launchpad Content Manager (Figure 8) helps you with the creation and adaptation of SAP Fiori launchpad catalogs. The content manager was introduced with release 1909 FSP01 and enhances the launchpad designer. You can use it to explore existing content and to create your own catalogs by copying existing ones and modifying them to fit your needs. You can start the content manager using transaction /UI2/FLPCM_CUST (client specific). In the content manager, you can check the catalogs for its services to make sure they are activated and properly configured. Figure 8: SAP Launchpad Content Manager   The content manager is a great tool when building business catalogs as it helps you to make sure all required services and configuration is available. You can learn more about the Fiori Launchpad Content Manager here.

SAP Fiori Rapid Activation

With SAP S/4HANA, SAP introduced the rapid content activation task list to dramatically reduce the activation effort of such an implementation. The SAP Rapid Activation Content SAP_FIORI_FCM_CONTENT_ACTIVATION is available as of release 1909 FSP01. If you are on a lower release, please check SAP Note 2834415. When implementing Fiori, you have to activate certain OData services which are being used by the UI5 applications. Historically, you activate services through transaction /IWFND/MAINT_SERVICE but SAP allows mass activation using transaction STC01 and tasks list SAP_GATEWAY_ACTIVATE_ODATA_SERV. In addition, you can use the task list SAP_BASIS_ACTIVATE_ICF_NODES to activate the several ICF nodes in one shot. You can learn more about the Rapid Content Activation here.

SAP S/4HANA Migration and Fiori Implementation

With the migration to SAP S/4HANA, SAP Fiori is no longer optional but often mandatory because SAP has moved tons of capabilities into Fiori. Especially when using SAP S/4HANA Essential (Multi Tenant) or Extended (Single Tenant), Fiori has become the standard user interface. Therefore, when migrating to SAP S/4HANA you have to adjust the authorization concept to include the new Fiori authorizations. SAP provides a “Simplification List” for each S/4HANA release that further details the replacement of legacy transactions with Fiori apps, or new ABAP transactions, web dynpros, etc. The Simplification List is a PDF document that contains several hundred pages and is, thus, difficult to digest. Therefore, we recommended using automation tools that simplify and automate the migration to S/4HANA. SAP Note 1682316 describes how organizations can automate the migration of roles to SAP S/4HANA, for example.

Impact on SAP Access Control (GRC) and Segregation of Duties (SOD) Considerations

When implementing SAP Fiori, it’s important to understand that SAP Fiori authorizations must be considered in the SAP Access Control (GRC) ruleset for risk analysis (critical access, segregation of duties, etc.). Having a ruleset in place that also covers SAP UI5 apps early on enables you to check new roles for SoD conflicts as you design roles to authorize users for those Fiori apps. If you do not have an updated ruleset, you should make sure that you do not over-authorize your end-users. That’s why we recommend avoiding asterisk (*) or broad value ranges in your authorization data when building the roles. Expert tools, like the one mentioned in SAP Note 1682316, can help you find missing authorization values and build compliance conform roles from the get-go. SAP Access Control (GRC) 10.1 Support Package 22 (initially introduced with SP19) and SAP Access Control 12.0 SP03 contain rulesets for SAP S/4HANA and SAP Fiori. If you are not on SAP Access Control 12.0 yet, please make sure you upgrade until the end of 2020. SAP’s support for SAP Access Control 10.0/10.1 will end on December 31st, 2020.

Conclusion

SAP Fiori in the 3rd generation is an exciting new user experience (UX) that becomes significantly more important when moving to SAP S/4HANA or SAP’s new cloud solutions. With the migration to SAP S/4HANA, SAP Fiori has to be part of the upgrade/migration project as its implementation might be required. That’s because some of the new or updated features are only available in Fiori. From a security point of view, Fiori demands an understanding of the architecture and how to build and authorize catalogs and groups. Luckily, you can build your roles and authorizations using the same tools you used in the past. We strongly recommend to follow the same authorization principles as for your traditional ABAP authorization roles including the use of the authorization defaults in transaction SU24. When implementing Fiori, also make sure to consider the Fiori applications in the SAP Access Control (GRC) ruleset to ensure seamless compliance.