Standard authorisation
Handle the default users and their initial passwords
The assignment of roles does not include any special features. Therefore, we only deal with the topics of time-space delimitation and logging. Time-space validation is implemented as an additional filter that runs after the usual permission checks. This additional filter logic works as follows: The first step is to check whether the user is entered in the tax verifier table (Table TPCUSERN, Configuration with the transaction TPC2). Only then will the further tests be carried out. If not, no additional checks will be carried out. The programme is then checked to see if it is included in the table of allowed programmes (table TPCPROG, configuration with the transaction TPC4). If the check is negative, the system cancels with a permission error. The time-space check is performed against the valid intervals in the table TPCDATA (configuration with the transaction TPC6). The time-space check works in context: In addition to the supporting documents of the audit period, older supporting documents are also included if they are still relevant for the audit period, such as open items that were booked in previous years but only settled in the audit period. Records that do not fall into the valid period according to the logic described above are filtered out.
The S_RFCACL authorization object is removed from the SAP_ALL profile by inserting SAP Note 1416085. This notice is included in all newer support packages for the base component; This affects all systems down to base release 4.6C. The reason for this change is that the S_RFCACL authorization object, and especially the expression "total permission" (*), is classified as particularly critical for its fields RFC_SYSID, RFC_CLIENT and RFC_USER. These fields define from which systems and clients or for which user IDs applications should be allowed on the target system. Thus, the overall authorisation for these fields allows the login from any system and client or for any user and thus creates significant security risks.
Compensating measures for segregation of duties conflicts
Run the System Trace for Permissions (ST01 or STAUTHTRACE transaction) to record permission checks that you want to include in the role (see Tip 31, "Optimise Trace Evaluation"). Applications are logged through the Launch Permissions checks.
The same applies to the concept of data ownership. Here, a person takes responsibility for the data of a certain scope (e.g., SAP system X or system landscape Y) and looks after it as if it were his own precious possession. He or she conscientiously answers questions such as "May data be changed / viewed / deleted?", "How is action taken in the event of a data leak?", "Who may access the data and how, and what may be done with it?".
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
Once the data in this table is available, you have the option to maintain the proposed values.
Before creating PFCG roles, it is useful to maintain the suggested values for the transactions used.