Implementing Permissions Concept Requirements
WHY ACCESS CONTROL
In the SCC4 transaction, first check whether eCATT is allowed to run. Then start the SECATT transaction. As you get started, you can define and modify test scripts and test configurations. First, create a test script. Think of it as a blueprint or a flow rule for how to create new derived roles. The test script will contain your recording later. Give the script a talking name, such as Z_MASSENGERATION_DERIVATIVES. Then click the Create Object button. You will now go to the Attribute tab, where you specify the general frame data. Then click the Editor tab. Now it goes to the recording, in the eCATT language called patterns. Click the Pattern button and specify that you want to record the PFCG transaction by selecting the UIAncontrol and TCD (Record) settings. The system will propose to call the interface "PFCG_1"; You can simply confirm this. Confirmation of the dialogue will immediately start the recording; They therefore end up in the PFCG transaction. We want to record the creation of a single role derived from a reference role. Complete the appropriate steps in the PFCG transaction and try to avoid unnecessary steps - every step you take will make your recording bigger and less cluttered. Enter the name of the derived role - we can influence it later when playing with eCATT - and specify the role. Now assign the reference role. Note that the PFCG transaction is actually executed, so the role is actually created in the system! Now maintain the permissions and organisation levels. If possible, use organisational level values in the note, which you can find well in other numbers later on, i.e. about 9999 or 1234. After generating and saving the role, you will be returned to eCATT. There you will be asked if you want to accept the data and confirm with Yes.
The next step is to maintain the permission values. Here, too, you can take advantage of the values of the permission trace. When you switch from the Role menu to the Permissions tab, you will generate startup permissions for all applications on the Role menu and display default permissions from the permissions suggestions. You can now add these suggested values to the trace data by clicking the button trace in the Button bar.
Use the authorisation route to identify proposed values for customer developments
The SAP authorization concept protects transactions and programs in SAP systems on the basis of authorization objects. Authorization objects enable complex checks of an authorization that are bound to several conditions. Authorizations represent characteristics of authorization objects depending on the employee's activity and responsibility. The authorizations are combined in an authorization profile that belongs to a role. The administrator assigns the appropriate role to the employee via the user master record so that the employee can perform his or her tasks in the system.
Partners delivering their developments also maintain the proposed values for their applications in the transaction SU22. If customers are developing systems that supply other system landscapes than your system landscape and require different SU24 suggestion values per system, the proposed values in transaction SU22 will be maintained. The profile generator uses only the values of the transaction SU24 in your customer environment as a data base. To maintain the suggestion values, you can use both the System Trace data for permissions from the ST01 or STAUTHTRACE transaction and the data from the permission trace in the SU24 transaction (see Tip 39, "Maintain suggestion values using trace evaluations").
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
In the foreground, important SAP reports on the subject of role and authorization administration were presented.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
This is what enables users to work with the SAP system in the first place, but it can, under certain circumstances, unintentionally add up to conflicts over the separation of functions or even legally critical authorizations.