When SAP system transactions are executed, a large number of Authorization Objects are often checked, since the transaction calls other work areas in the background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users having more authorization than they strictly need. It also leads to an increased maintenance workload.
If you are using the Profile Generator, you can reduce the scope of the authorization checks (transaction SU24). When the Profile Generator generates a profile, it selects all of the authorizations associated with an activity. The generated profiles are not always complete (especially in older releases of the Profile Generator), meaning that you may have to add authorizations that are not contained in the profiles manually. (This is mainly the case with programs that call other programs, where the subprogram requires additional authorizations.) To simplify the administrative tasks with the Profile Generator, you could consider reducing the scope of the authorization checks in cases such as this.
If a user in PA calls a program that in turn calls an HR routine, the user requires the corresponding HR authorizations. If you have not installed the HR components, you may not want to assign all of the HR authorizations required for the PA report to the PA users. In this case, you can deactivate the authorization checks for HR authorizations in the PA transactions.
For an authorization check to be executed, it must be included in the source code of a transaction and must not be explicitly exempt from the check.
You can suppress authorization checks without changing the program code, as check indicators control authorization checks. You also use check indicators to control which objects appear in the Profile Generator and which field values are displayed there for editing before the authorization profiles are generated automatically.
SAP supplies defaults for check indicator and authorization field values, which you should copy. You can then edit these copied defaults. You should only do this once you have defined your company's authorization concept.
You can reduce authorization checks within a transaction or exclude an authorization object globally from the check. More information:
Authorization objects from the Basis (S_*) and Human Resource Management applications (P_*, PLOG) cannot be excluded from authorization checks. The field values for these objects are always checked.
For parameter or variant transactions, you cannot exclude authorization objects from a check directly, only using the authorization objects in the corresponding transaction.
As explained above, by reducing the scope of authorization checks, you simplify the administration tasks connected with the Profile Generator. You should carefully weigh-up which authorization checks you want to suppress. If you deactivate authorization checks, you permit users to perform tasks for which they are not explicitly authorized. You should possibly consider reducing the scope of authorization checks in the following cases:
● You do not use the authorization object connected with the authorization check (as in the example above).
● The authorization check for the object S_TCODE still protects the core transaction. (Note, however, that the S_TCODE authorization check only provides very general protection. This alone is not a reason to suppress an authorization check.)
● You want to avoid permitting all values for all authorization fields in the authorization object.
Instead of assigning the asterisk (*) as the placeholder value, you can suppress authorization checks for specific objects in specific transactions. You can use a standard authorization check for the same authorization object for other transactions.
If you reduce the scope of authorization checks, you allow users to perform activities without ensuring that the users have the required authorization. This can have undesired consequences. Consider very carefully before suppressing authorization checks.