Implementing Permissions Concept Requirements
User master data
The system checks direct access to the contents of tables, for example, with transactions SE16, SM30, or SE16N with authorization checks on a table authorization group, object S_TABU_DIS. If there are no suitable authorizations for the table authorization group, the system checks the name of the table or view, object S_TABU_NAM. When making changes to client-independent tables, the system also checks the authorizations for object S_TABU_CLI. If you have configured line-based authorization checks in Customizing, the system also checks authorization object S_TABU_LIN. Assign tables or views to a table authorization group using transaction SE11 or SE54. You can also define table authorization groups using transaction SE54. If your customer development implements direct access to a table, use the VIEW_AUTHORITY_CHECK function module to perform the authorization check. For more information about generic access to tables, see SAP Note 1434284 Information Published on SAP Site and the online documentation for the authorization objects mentioned above.
An essential aspect in the risk assessment of a development system is the type of data available there. Normally, at least a 3-system landscape is used (development, test and production system). One of the purposes of this is to ensure that (possibly external) developers do not have access to productive or production-related data. Since developers with the required developer authorizations have access to all data in all clients of the system concerned, there should be no production-related data in a development system. Even a division into a development and a test client (with the sensitive data) within the system does not protect against unauthorized data access for the reasons mentioned above. In the following, it is assumed that no production-related data exists on the development system. Otherwise, extended authorization checks must be carried out in the modules and access to production-related data must be approved beforehand with respect to the production system by the respective data owners. Since developers, as described, have quasi full authorization through their developer rights, revoking the authorizations listed below can raise the inhibition threshold for performing unauthorized activities, but ultimately cannot prevent them.
Archive change document management for user and permission management
You have now successfully recorded the blueprint. Now the slightly trickier part follows: The identification of the values to be changed at mass execution. In the editor of your test configuration, at the bottom of the text box, is the record you have created: TCD ( PFCG , PFCG_1 ). Double-click the PFCG_1 interface. On the right, a new detail with the recording details appears. Now you have to look for your input a bit. For example, use the role name entered on the PFCG entry screen (field name 'AGR_NAME_NEW'). Now comes an important step: Replace the values you entered during the recording with a placeholder, a so-called input parameter. To do this, go to the VALIN line and type any parameter name, such as ROLLENNAME, instead of the role name you entered. Click Enter and you will be asked what type of parameter it is. Specify Import and confirm with Yes.
You can also use the SU53 transaction to centrally view failed permission checks. Open the transaction and go to Permissions > Other Users or F5 to the User Selection menu. Enter the user whose permissions have failed in the field with the same name. In the results list, you can see permissions that have failed for each user, as in our example, the missing permission to display the AGR_1251 table. You can see that more than one authorization object appears in this evaluation.
During go-live, the assignment of necessary authorizations is particularly time-critical. The "Shortcut for SAP systems" application provides functions for this purpose, so that the go-live does not get bogged down because of missing authorizations.
Therefore, SAP standard users such as SAP* and DDIC must also be considered, some of which have extensive authorizations and pose a danger without conceptually defined protection.
This verification of certificates ensures that no existing certificates are added in the template and that only one certificate is entered to an e-mail address.