User Interface Client Permissions
Deleting versions
Do you want to automatically monitor the security settings of your systems and receive convenient evaluations? We will explain how to use configuration validation. If you have a large SAP system landscape in use, the control of the many different security settings can be complex. You define your security requirements for the entire SAP system landscape; they concern, for example, the settings of the profile parameters, the handling of safety instructions or critical permissions that may only be assigned to emergency users. You can define these requirements in the SAP Solution Manager Configuration Validation application and evaluate compliance with these requirements in all systems.
The use of suggestion values not only brings advantages when creating or maintaining PFCG roles, but also when maintaining permissions as a rework of an upgrade. Furthermore, these values can be used as a basis for risk definitions. Before creating PFCG roles, it is useful to maintain the suggested values for the transactions used. However, you do not need to completely revise all of the suggested values that are delivered by SAP.
Maintain batch job suggestion values
When you mix roles, either after upgrading or during role menu changes, changes are made to the permission values. You can view these changes as a simulation in advance. As described in Tip 43, "Customising Permissions After Upgrading," administrators may see some upgrade work as a black box. You click on any buttons, and something happens with the permissions in their roles. For example, if you call step 2c (Roles to be reviewed) in the SU25 transaction, all roles will be marked with a red light, which requires mixing based on the changed data from the SU24 transaction. Once you call one of these roles and enter the Permissions Care, the permission values change immediately. Using the Alt, New, or Modified update status, you can see where something has changed, but you cannot see the changed or deleted values. A simple example of how to play this behaviour without an upgrade scenario is changing the role menu. Delete a transaction from a test role and remix that role. You are aware that certain authorization objects have now been modified and others have even been completely removed, but can't all changes at the value level be replicated? Thanks to new features, this uncertainty is now over.
The SAP authorization concept must generally be created in two versions: for the ABAP stack and for the Java stack. Which roles are required, which role may call which SAP functions, and other conceptual issues are identical. However, there are fundamental differences between the two versions.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
On www.sap-corner.de you will also find useful information about SAP basis.
At the end there is a list of objects.
To store all the information on the subject of SAP - and others - in a knowledge database, Scribble Papers is suitable.
For the ABAP stack, authorization profiles can be created either manually or by using the profile generator.