What changes in authorizations with SAP S/4HANA

SAP S/4HANA brings with it various new processes and technologies that did not previously exist in this way in SAP ERP. In addition, there are also differences in the authorization concepts between SAP S/4HANA and previous ERP versions from SAP that must be taken into account to ensure smooth user access.

Overcome the challenge of SAP S/4HANA authorizations with us

Authorize users in the frontend and in the backend

In SAP ERP, users use SAP GUI interfaces to launch the transactions they need to complete their work. The corresponding authorizations are assigned to them via SAP single and composite roles. This is a fairly simple scenario that has been used for authorizations in SAP for many years.

With SAP S/4HANA, two different layers have to be considered with regard to authorizations: the backend and the frontend, whose Fiori applications represent a significant difference to SAP ERP. In the backend, the user must be authorized as usual with SAP single and composite roles. In addition, however, he also needs access to the frontend server in order to use the Fiori interfaces. This access is controlled via Fiori roles.

The user must therefore be maintained in two places in SAP S/4HANA with different authorizations. It is possible to analyze the current situation in advance of the SAP S/4HANA conversion using an authorization check and to derive findings for the future authorization system. Companies should definitely address the issue of Fiori authorizations at an early stage when the switch to SAP S/4HANA is imminent.

Simplified illustration of authorization concepts in SAP ERP and SAP S/4HANA

From transactions to apps

SAP ERP groups transactions and other authorization objects into corresponding roles that are assigned to users. In SAP S/4HANA, transactions are still available. However, this is supplemented by a large number of Fiori apps that take over functions that were previously mapped in transactions on a one-to-one basis or bundle several functionalities from different transactions. The roles must be maintained in SAP S/4HANA in the backend and in the frontend. In addition, the default values become more important with SU24. In addition, the service authorizations of the frontend applications must also be represented in the backend. A translation table is available as a tool for this.

What used to be combined in one SAP GUI transaction may now be split across different Fiori apps, which requires a corresponding process design and has an impact on authorizations. Conversely, multiple functionalities from different SAP GUI transactions may also be combined into one Fiori app – again with implications for authorizations.

Three types of Fiori apps

New functionalities are no longer created as transactions in SAP S/4HANA, but as SAP Fiori apps. There are now about 2,000 different Fiori apps, which can be divided into three groups:

• Transactional apps for performing actions in business processes such as create, change and delete

• Analytical apps for visualizing complex data and topics

• Object pages (fact sheets) with information about objects including contextual navigation between objects

Legacy apps are apps that have the Fiori design but were not developed in SAP UI5. Currently, there are about 8,000 SAP Fiori legacy apps. In addition, a search function (SAP Fiori Search) is also available in SAP Fiori Launchpad. This can be used to search across all business processes and applications for business partners or materials, for example. There is still a wealth of transactions in the backend that can be executed via SAP GUI. However, certain functions are only available via SAP Fiori in different applications.

Type of conversion determines the extent

Given the many innovations that come with SAP S/4HANA, companies cannot avoid revising and adapting their authorizations as part of the SAP S/4HANA implementation. How extensive this task turns out to be depends, among other things, on whether companies introduce SAP S/4HANA in the greenfield, brownfield or greyfield approach.

Since the greenfield approach involves a new implementation of the system and the processes, the authorization concept must also be set up from scratch. This offers the opportunity to get rid of legacy issues from SAP ERP. Process participants must be given the authorizations they need to perform their tasks in SAP S/4HANA. Ideally, the new authorizations are derived from the SAP standard. However, the SAP standard is defined quite generously, so that one role may well be associated with access to 50 to 100 Fiori applications. However, such far-reaching authorizations are not necessarily desirable from the company’s point of view. Therefore, it is important to make the necessary adjustments as required. In general, authorizations should be set up at an early stage.

The greenfield approach requires a complete reset of authorizations.

If a company chooses the system conversion (brownfield approach) to introduce SAP S/4HANA, the existing roles in the backend will continue to exist. However, various transactions that are contained as authorization objects in the roles will be replaced by apps, so they will have to be removed from the roles. Furthermore, the Fiori roles are newly added, which allow the use of the corresponding apps in the frontend. For the necessary clean-up work, there are helpful tools that can be used to determine the transactions that need to be deleted from the existing roles.

Brownfield approach: While the roles in the backend continue to exist, the Fiori roles for the frontend are newly added.

The adjustments to processes, selective data migration and any merging of legacy systems in the greyfield approach also have an impact on authorizations. For the roles in the backend, transaction clean-up is required, as in the brownfield approach. Likewise, new Fiori roles must be designed to assign the appropriate permissions to users. Again, the transaction detection tools can be used for this purpose. In addition, care must be taken to adapt the authorizations to the changed processes and process participants. It may also be necessary to remove data from authorizations, for example company codes or cost centers that no longer exist.

A particular focus of the greyfield approach is to adapt the authorizations to the changed processes and people involved.

Making adjustments using SAP tools

The main reason for the need to adjust authorizations is the new technologies that SAP S/4HANA brings with it. The user exists in the backend and the frontend, accordingly it should have the same ID. Authorizations need to be assigned in the frontend and backend roles. It may also be necessary to remove transactions from the previous roles. In addition, the default values (SU24) need to be adjusted. This may also apply to organizational values such as company codes, cost centers, etc.

SAP provides various tools for adapting the authorization concepts. For example, the simplification list shows which Fiori apps in SAP S/4HANA replace which transactions from SAP ERP. There is a separate simplification list for each of the various SAP S/4HANA releases, as innovations are constantly being made and additional Fiori apps are added. Due to the volume of the simplification lists alone, which can comprise several hundred pages, it is advisable to start with the authorization concept early on in the SAP S/4HANA project.

IAM solutions support SAP S/4HANA implementation

Solutions from SAP Identity & Access Management (IAM) can also effectively support companies in making authorization adjustments with regard to SAP S/4HANA. One example is the use of SAP Access Control to perform a SoD check for segregation of duties when roles are created and changed. And with the help of SAP Identity Management, users and authorizations can be distributed directly. SAP Single Sign-On and SAP Cloud Identity Authentication (IAS) are available for authentication and access to applications.

The introduction of SAP S/4HANA affects an existing SAP Identity Management (IdM) or SAP Cloud Identity Provisioning (IPS). This affects existing ABAP connectors, for example. SAP IdM and SAP IPS are able to create business partners if no SAP SuccessFactors Employee Central is in use. With SAP IdM 8.0 SP08, an additional SAP S/4HANA connector is available. Both solutions also support role model changes, perform automated role assignment and enable simplified workflows.

With regard to SAP Access Control and SAP Cloud Identity Access Governance (IAG), SAP S/4HANA may make it necessary to adapt the connectors. Furthermore, the target systems must be kept in sync with regard to authorizations. It is necessary to adapt SoD risks and mitigations to SAP S/4HANA needs. Roles can be checked for separation of duties risks at an early stage, ensuring that new or changed roles are low-risk or risk-free. After the redesign, role-specific changes must also be made in SAP Access Control. Business roles can be used directly for user lifecycle management to assign new authorizations to users and revoke authorizations that are no longer needed. The assignment of roles can be automated based on HR information. For new roles in the SAP S/4HANA environment, there is the option of performing SoD checks and identifying and, at best, eliminating functional separation conflicts.