Authorization concept
Reference User
A mass rolling out of rolls is a very useful thing. It is also possible to use Excel-based data - as in the case of the outlined application case with eCATT - because it is a one-time action for the roles considered and SAP standard programmes are used in the background. However, ongoing maintenance of the permissions system, with continuous changes to roles and their detail permissions, requires the mapping of much more complex operations. An exclusive control over Office programmes should be well considered. This does not mean, of course, that there are not very good partner products for the care of roles. Simply verify that SAP standard procedures are used and that authorisation is managed in accordance with SAP best practices.
Define explicit code-level permission checks whenever you start transactions from ABAP programmes or access critical functions or data. This is the easiest and most effective defence to protect your business applications from misuse, because programming-level permission checks can ensure two things: Incomplete or incorrect validation of the executed transaction start permissions will result in compliance violations. Complex permission checks can also be performed adequately for the parameterized use of CALL TRANSACTION.
Permissions objects already included
With the introduction of security policy, it is now possible to define your own security policy for System or Service users. This way you can ensure that backward-compatible passwords are still used for these users. This eliminates the reason that password rules were not valid for System/Service type users; Therefore, the rules for the content of passwords now apply to users of these types. Password change rules are still not valid for System or Service type users. If you are using security policy in your system, you can use the RSUSR_SECPOL_USAGE report to get an overview of how security policy is assigned to users. This report can be found in the User Information System (transaction SUIM). In addition, the user information system reports have added selected security policies to the user selection. This change was provided through a support package; For details, see SAP Note 1611173.
If a transaction is removed from the role menu, the default permission is deleted when mixing. However, this only applies if no further transaction requires this permission and therefore uses the same permission proposal. This applies to both active and inactive default permissions.
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
When you create users in the SU01 transaction, do you want to automatically pre-occupy certain fields from a data source? Use a new BAdI for which we present an implementation example.
If role recording requires creating new transport jobs or tasks, you need permissions to the transport objects (e.g. S_TRANSPRT with TTYPE = CUST or TASK and ACTVT = 02).