Fiori App Builder (FAB) and OneList - Roles and Authorization objects

Users, roles and authorization objects

Certain authorization objects are required on the Backend and Frontend servers in addition to the application roles required for the specific FAB app.  IQX has documented these for your reference.  The authorizations may be implemented as recommended below or to your own role and naming convention using PFCG. 

Implementing App-Specific FAB Authorisation /IQX/FAB

App-specific authorization can be invoked by the selection of the Authorization Checkbox on the Properties screen and providing a value in the Auth. Group field in the FAB Workbench.

This setting mandates checks to the FAB delivered authorization object /IQX/FAB.

Authorisation Object: /IQX/FAB (SU21)
Allowed activities:

01 – Create New Instance

02 – Change Instance

03 – Display Instance

04 – Delete Instance

11 – Workbench create

12 – Workbench edit

13 – Workbench display

Authorisation Group

Multiple values, free text entry, support wildcard entry patterns eg FI*

Sample implementations

Activity 11 is the main authorization required for a developer to have access to create an app

from the workbench (TCODE /IQX/FAB). This is implemented in the role /IQX/CONFIG (Section
4.3.3)

FAB Generic User Roles

Assign to who: All users that will use the applications generated by FAB

Where to assign: All systems installed with FAB

Backend

Role Name: /IQX/END_USER

Authorization Objects defined for the role are:

• /IQX/FAB
• S_SERVICE
• S_PERSONAS
• S_RFC
• S_RFCACL

Further restriction to the authorization object /IQX/FAB can be implemented. Depending on the security/access requirement, the role can be implemented multiple times and in separate roles having different combination values for /IQX/FAB.

Role template: IQX_END_USER.txt

Frontend

Role Name: /IQX/END_USER_GW

Authorization object defined for the role is S_SERVICE.

Role template/upload file: IQX_END_USER_GW.txt

FAB Developer / Cutover Roles (Install on GW and Backend)

Assign to who: Developers and consultants who will perform the configuration

Where to assign: All systems installed with FAB with a limited validity period in the production environment

Role Name: /IQX/CONFIG

The same set of authorization for Backend and Frontend systems. Critical authorization defined is /IQX/FAB and important TCODEs are /IQX/FAB, /IQX/FAB_CONFIG and /IQX/FAB_ANALYSIS.

The role has all activities for /IQX/FAB and this is the main reason why it should only be assigned for a limited period in the production environment.

Role template/upload file: IQX_CONFIG.txt

FAB Support Roles (Install on GW and Backend)

Assign to who: Users, usually developers/consultants, that will provide support in the Production environment

Where to assign: Production environment where FAB is installed.

Role Name: /IQX/SUPPORT

The same set of authorization for Backend and Frontend systems. Critical authorization defined is /IQX/FAB and important TCODEs are /IQX/FAB_CONFIG and /IQX/FAB_ANALYSIS.

 Authorization for /IQX/FAB activity is limited to 03 (Display Instance) only

Role template/upload file: IQX_SUPPORT.txt

OneList Admin role

Assign to who: Developer in Dev/UAT environment, Support users, Administrative users that support in Production environment

Where to assign: All systems with OneList

Role Name: /IQX/OL_ADMIN

The role contains set of authorization to access the following transactions: /IQX/OL_CONFIG, /IQX/OL_ENDPOINT, SM30 with Auth.Group OLIS, SU53.

Role template file: IQX_OL_ADMIN.txt

Trust relationship, set up and testing using SM59.

For a Hub deployment, a trust relationship is required between the BE and FE servers. This enables communication between the two servers. The trust relationship is achieved by setting up the same user in both the BE and FE servers and then testing the connection using SM59. Refer to section 4.3.2.1 for details on the authorization/role implementation related to trusted RFC.

First of all, you will need to create a user (in this case IQX_FABUSER ) to use in the Trusted Relationship. This can be done in transaction SU01. Then, you need to assign the authorization object S_RFCACL to this user.

Refer to detailed documentation in this link: https://wiki.scn.sap.com/wiki/display/ABAPConn/Create+an+RFC+trust+relationship+between+2+SAP+systems+-+A+step-by-step+guide

Suggested RFC connection name set up in BE server using SM59. Choose your own RFC name and add suffix ‘_FE’. Set Logon and Security to Current User. In Technical Settings set Target host to FE server.

Suggested RFC connection name set up in FE server using SM59. Choose your own RFC name and add suffix ‘_BACK’.  Set Logon and Security to Current User. In Technical Settings set Target host to BE server.

Do a Connection Test and a Remote Logon test.