Development
Conclusion
As the rolls pass, the value ranges for the field in question are searched within a role. Automatic cleanup occurs by writing both value ranges together in all fields. Therefore, you should clean up these entries before you start and create two different roles if necessary. The PFCG_ORGFIELD_CREATE report provides a test run that allows you to identify all the affected roles. The Status column provides an overview of the status of the permission values. If the status is yellow, there are different value ranges for the field within the role; the role must therefore be adjusted.
Different organisational fields are used in each module. Since there are many interfaces between the modules, the main organisational fields of the modules must be linked. However, there are also organisational fields that are only relevant for the respective module. All object fields used as organisational units are listed in the USORG table. You can call this table through the SE16 transaction. Alternatively, in the selection screen of the AGR_1252 table, the value help of the VARBL field also shows the corresponding name for the respective organisation fields.
Goal of an authorization concept
Finally, the check logic provides for a row-level check within a table if you want to restrict access to the table contents depending on an organisational mapping. For example, if you want a user to view only the data from a table that affects the country where their work location is located, you must configure it accordingly. To do this, you define and activate organisation-relevant fields as an organisational criterion (see Tip 62, "Organisationally restrict table editing permissions"). To keep track of which users can access which tables, run the SUSR_TABLES_WITH_AUTH report. This report provides information about which user or single role has the S_TABU_DIS or S_TABU_NAM authorization objects. The result list shows all the authorised tables, their permissions, and their permission values.
Confidential information from your SAP system can also be sent by email. Make sure that this data is only transmitted encrypted. Your SAP system contains a lot of data, which is often confidential. This can be business-critical or personal data or even passwords. It happens again and again that such data must also be sent by e-mail. Therefore, make sure that this information is always encrypted and signed if necessary. Encryption is intended to ensure the confidentiality of the data, i.e. that only the recipient of the e-mail should be able to read it. The digital signature serves the integrity of the data; the sender of an e-mail can be verified. We present the configuration steps required for encryption and provide examples of how to encrypt the sending of initial passwords. There are two ways to encrypt and sign emails in the SAP system: via SAPconnect, via a secure third-party email proxy.
Assigning a role for a limited period of time is done in seconds with "Shortcut for SAP systems" and allows you to quickly continue your go-live.
This must of course be considered across the board for the authorisation concept.
The recommendation is issued in the following categories: Security-relevant SAP information, information on performance optimisation, HotNews, information on changes in legal regulations, and notes on corrections in the ABAP system.