...
It is recommended that a new package is created for customer-specific FAB development. This will be required when the FAB provided super class superclass is extended (inherited).
...
4.3. Users, roles and authorization objects
Certain authorisation 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 authorisations authorizations may be implemented as recommended below or to your own role and naming convention using PFCG.
4.3.1. Implementing App-Specific FAB Authorisation /IQX/FAB
App-specific authorisation 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 authorisation authorization object /IQX/FAB.
Authorisation Object: /IQX/FAB (SU21)
Allowed activities:
...
Functionality | /IQX/FAB-/IQX/ACTVT values | /IQX/FAB-BEGRU values |
Ability to Create, Change and Display FAB instances for Apps having Authorisation Group value of FI | 01, 02, 03 | FI |
Access to create Apps in the workbench | 11 | * |
Access to Edit and Display in the workbench for apps having Authorisation Group value of SD | 12 and 13 | SD |
Activity 11 is the main authorisation authorization required for a developer to have access to create an app
...
4.3.2.1. Backend
Role Name: /IQX/END_USER
Authorisation Authorization Objects defined for the role are:
...
Further restriction to the authorisation 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 Name | /IQX/FAB-/IQX/ACTVT values | /IQX/FAB-BEGRU values |
/IQX/END_USER_FI | 01, 02, 03 | FI |
/IQX/END_USER_MM | 01, 02, 03 | MM |
S_RFCACL (Trusted RFC) authorisation authorization value should be limited to the calling system which is the SAP Gateway system. Please refer to the SAP Note 1416085 for further details.
Services that users should be having access to, in addition to the /IQX/* services, must be added in the S_SERVICE authorisation authorization object values
Role template/upload file: https://bit.ly/2tzoGEf
...
Role Name: /IQX/END_USER_GW
Authorization Object object defined for the role is S_SERVICE.
Services that users should be having access to, in addition to the /IQX/* services, must be added in the S_SERVICE authorisation authorization object values
Role template/upload file: https://bit.ly/2yFTZTD
...
Where to assign: All systems installed with FAB with a limited validity period in Production the production environment
Role Name: /IQX/CONFIG
Same The same set of authorisation 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 activites activities for /IQX/FAB and this is the main reason why it should only be assigned for a limited period in Production the production environment.
Role template/upload file: https://bit.ly/2Iowq1e
...
Where to assign: Production environment where FAB is installed.
Role Name: /IQX/SUPPORT
Same The same set of authorisation authorization for Backend and Frontend systems. Critical authorization defined is /IQX/FAB and important TCODEs are /IQX/FAB_CONFIG and /IQX/FAB_ANALYSIS.
Authorisation Authorization for /IQX/FAB activity is limited to 03 (Display Instance) only
...
4.4. 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 authorisationauthorization/role implementation related to trusted RFC.
...