The authorization administrator often does not know which authorization objects are checked in predefined functions (business transactions).
This question cannot be answered with technical means.
A)
Please refer to the Customizing Implementation Guide. In the system, choose:
Rel. 2.1 or 2.2
---------------
Tools -> Customizing -> Implementation guide -> Complete version. Select the SAP application you are interested in with F2 (or double-click).
Example in SD: F2 on Environment -> Authorizations -> Define profiles
Example in MM Purchasing: F2 on Materials management -> Purchasing -> Environment data -> Maintain users -> Maintain authorizations
Example in FI Accounting: F2 on Financial accounting -> Financial Accounting -> Environment -> Employees -> Maintain user master records -> Maintain authorizations
Rel. 3.0
--------
Tools -> Customizing -> Implem. projects -> Display complete IMG.
Select the SAP application you are interested in with F2 (or double-click) and proceed as described under Rel. 2.1.
In newer Versions of 3.0:
Tools -> Business Engineering -> Customizing -> Enter -> F2 on the application in question -> ... Subchapter 'Maintain authorizations' Example: F2 on 'Initial Project Accounting (FI/AM/CO)' -> click on 'Financial Accounting' -> click on 'Basic settings in FI' -> click on 'Authorization management' -> Double-click on 'Maintain Authorizations'.
========================================================================
B)
As of Release 3.1G the so-called profile generator exists.
The administrator defines a so-called "position" or "plan position" and, in the process, chooses a set of application components which the system uses to determine the affected transactions. At the same time, an authorization profile is generated for that type of (work center) position that contains the authorization needed for the transaction chosen. When the administrator allocates this position to a user, the system automatically writes the newly generated authorization profile to the user master data.
========================================================================
C)
For individual cases, you can use the trace function to determine which objects are validated within a transaction.
Release 2.1 and 2.2
-------------------
Transaction SE30 -> enter the transaction to be traced -> Execute. Then carry out the transaction and return to SE30. Analyze -> Group hit list and scroll all the way to the end to DIVERSE. There you can find the authority checks and determine the name of the authorization object with double click on the relevant line. This trace determines checks only within a transaction without validating TSTCA, and displays only the names of the authorization objects.
Release 3.0
-----------
The authorization trace is done within the system trace.
Transaction ST01 -> Switch, edit -> click on check box Authorization check. Then click on the arrow next to General filters and enter your user name -> Back. Choose Write options and select To disk -> Back. Choose Trace switch -> Save -> in active system.
Now you can carry out any number of transactions.
To analyze the trace, go back into transaction ST01 and choose Stop.
Then choose Trace files -> Standard options. There, select only Trace for authorization checks and enter your user name in field User.
Choose Accept -> Trace files -> Analyze standard. Double click on the trace file to display a list with all authorization objects that were checked and their values.
=======================================================================
D)
When a user runs into a message, such as "You have no authorization...", he or she can call up transaction SU53 to display the authorization object and values.
In releases 2.1 and 2.2 this requires setting the system parameter
auth_check_value_write_on =1. Please note that this may affect system performance.
In Release 3.0 the parameter
login/auth_check_value_write_on
is no longer needed and the tracing does not affect performance.
========================================================================
E)
Table TSTCA contains only those authorization checks that are carried out by the dynpro processor directly at the start of a transaction.
In most cases, however, additional authorization checks are done in the ABAP/4 coding. These are not contained in table TSTCA.
There will possibly be another table in 3.0 which will contain all authorization objects directly checked by each transaction.
No comments:
Post a Comment