Authorization objects of the PFCG role
Analyze user buffer SU56
After successful implementation of your permission check, the new authorization object for your application must be maintained in transaction SU24. If your solution is distributed in other system landscapes, the authorisation proposals in the transaction SU22 are maintained. In addition, with the permission proposal value maintenance, you can make sure that the new authorization object is not forgotten in a role system, because it is now loaded automatically into the PFCG role when the application is called up via the role menu. In the final step, the permission administrator can create the PFCG role or must remix the existing PFCG roles.
The first line defines that access to all files is forbidden unless other settings have been made for them in the other lines. The asterisk (*) is in the first place here and in this case for all files and paths. If the asterisk is in a different position, it is interpreted as part of the file name, which is not allowed in Microsoft Windows, for example. In our example table, setting the switches FS_NOREAD = X and FS_NOWRITE = X for all paths prohibits reading and writing. This makes the table a white list. This is preferable to a black list for security reasons. SPTH, on the other hand, becomes a Black List if you remove the first line with PATH = * in our example or if you do not set any of the switches FS_NOREAD, FS_NOWRITE or FS_BRGRU. The second line with PATH = /tmp allows read and write access for all files starting with /tmp, similar to a permission value /tmp*, as an exception to the access ban defined in the first line for all files and paths. This setting is not limited to subdirectories, but includes, for example, all files whose name starts with /tmp-xy. The third line with PATH = /tmp/myfiles defines a permission group with FS_BRGRU = FILE, triggering the subsequent permission check on the S_PATH object. The SAVEFLAG = X switch defines that these files will be included in a backup procedure; however, this is not relevant for the permission award.
WHY ACCESS CONTROL
Are you using the result and market segment statements and need permission checks for combinations of characteristics and key figures not included in the standard? To do this, create specific authorization objects. You can define key figures and result objects (groups of characteristics) for the planning and information system in the result and market segment calculation (CO-PA). You may also want to control permissions by using these characteristics or key numbers. This cannot be reflected with the default authorization objects. Therefore, create authorization objects in the customising of the result invoice.
In order for these FIORI apps/tiles and groups to be displayed, the corresponding authorizations must be made on the basis of a group and catalog assignment. These are assigned via specific groups, which in addition to the normal authorizations (such as create, change, display cost centers) also assign access to the appropriate FIORI Apps.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
In SU56 you can see all the authorizations you have.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
Both parameters must be activated in order to ensure traceability at the user level as well as at the table level.