09. Checking Assignment of Authorization Groups to Tables

Checking Assignment of Authorization Groups to Tables

You can also assign authorization groups to tables to avoid users accessing tables using general access tools (such as transaction SE16). A user requires not only authorization to execute the tool, but must also have authorization to be permitted to access tables with the relevant group assignments. For this case, we deliver tables with predefined assignments to authorization groups. The assignments are defined in table TDDAT; the checked authorization object is S_TABU_DIS.

Analyze Authorization check SU53

1.     Choose the menu path System -> Utilities -> Display Authorization Check or transaction code SU53. You now can analyze an error in your system that just occurred because of a missing authorization.

2.     You can call Transaction SU53 in all sessions, not just in the session in which the error occurred. Authorization errors in other users' sessions, however, cannot be analyzed from your own session.

3.     In the below example, user Bob calls Transaction VA03 (display sales order). The message "You do not have authorization for Transaction VA03" appears. User Bob now chooses transaction code /nSU53 and the system displays the authorization object that was just checked and, for comparison purposes, the values of the object that user Bob has in its user master record. In this case the user Bob don’t have VA03 assigned to any of his role.

4.     Transaction SU56 allows the user to see what current authorizations are in his buffer

Authorization Trace ST01

You can analyze authorizations as follows: Choose Tools -> Administration -> Monitor -> Traces -> SAP System Trace or Transaction ST01.

Choose trace component Authorization check and pushbutton Trace on. The trace is automatically written to the hard disk.

To limit the trace function to your own sessions, choose Edit -> Filter -> Shared. Enter your user ID in field Trace for user only in the displayed dialog box.

Once the analysis is completed, choose Trace off.

To display the results of the analysis, choose Goto -> Files/Analysis or the pushbutton File list Select the required file and choose Analyze.

The results of the authorization check are displayed in the following format: <Authorization object>:<Field>=<Tested value>

The return code shows whether or not the authorization code was successful. ST01 Return Code

0 Authorization check passed

1 No Authorization

2 Too many parameters for authorization check

3 Object not contained in user buffer

4 No profile contained in user buffer

6 Authorization check incorrect

7,8,9 Invalid user buffer

System Profile Parameters for Managing Users and Authorizations

Parameters directly affecting the user management functions are as follows:

1.     login/fails_to_session_end : Indicates the number of times that a user can enter an incorrect password before the system closes the logon window. The default value is 3, but you can set it to any value between 1 and 99.

2.     login/fails_to_user_lock : This parameter sets the number of times a user can enter an incorrect password before the system automatically locks the user out. If this happens, the user is automatically unlocked at midnight. The default value is 12. Possible values are from 1 to 99.

3.     login/system_client :  Sets the default system client. This client is automatically filled in the client field of the logon screen, although users can overwrite it.

4.     login/min_password_lng. Specifies the minimum password length. Default value is 3, but you can specify any value between 2 and 8.

5.     login/password_expiration_time : Indicates in number of days the period of validity for passwords. When the expiration time arrives, the user is asked to enter a new password.

6.     login/no_automatic_user_sapstar : Disables special properties for user SAP* when this parameter is set to a value greater than 0.

7.     rdisp/gui_auto_logout : Specifies the number of seconds a user session can be idle before being automatically logged off by the system. This parameter is deactivated by setting the value to 0. A user session is considered in an idle state during the period of time in which its terminal process (SAPGUI) does not transfer or communicate with the application server. By default, this option is not activated.For example, developers working in the ABAP editor for a long period of time can be considered idle to the system if they do not perform any function other than editing.

8.     auth/no_check_in_some_cases : This parameter is set to switch off special authorization checks by customers, and is the main parameter for activating the Profile Generator tool. Values can be either Y (yes) or N (no).

9.     auth/no_check_on_tcode : If this parameter is set to value Y (yes), then the system does not perform an authorization check on object S_TCODE.

To make the parameters globally effective in a SAP system, set them in the default profile,

To make them instance specific, you must set them in the profiles of each application server in your SAP system.

08. Authorization Checks

Authorization Checks

When a user starts a transaction, the system performs the following checks:

1.    The system checks in table TSTC whether the transaction code is valid and whether the system administrator has locked the transaction.

2.    The system then checks whether the user has authorization to start the transaction. The SAP system performs the authorization checks every time a user starts a transaction from the menu or by entering a command. Indirectly called transactions are not included in this authorization check. For more complex transactions, which call other transactions, there are additional authorization checks.

3.    The authorization object S_TCODE (transaction start) contains the field TCD (transaction code). The user must have an authorization with a value for the selected transaction code.

4.    If an additional authorization is entered using transaction SE93 for the transaction to be started, the user also requires the suitable defined authorization object (TSTA, table TSTCA).

5.    If you create a transaction in transaction SE93, you can assign an additional authorization to this transaction. This is useful, if you want to be able to protect a transaction with a separate authorization. If this is not the case, you should consider using other methods to protect the transaction (such as AUTHORITY-CHECK at program level).

6.    The system checks whether the transaction code is assigned an authorization object. If so, a check is made that the user has authorization for this authorization object.

The check is not performed in the following cases:

1.    You have deactivated the check of the authorization objects for the transaction (with transaction SU24) using check indicators, that is, you have removed an authorization object entered using transaction SE93. You cannot deactivate the check for objects from the SAP NetWeaver and HR areas.

2.    This can be useful, as a large number of authorization objects are often checked when transactions are executed, 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. You can therefore deactivate authorization checks of this type in a targeted manner using transaction SU24.

3.    You have globally deactivated authorization objects for all transactions with transaction SU24 or transaction SU25.

4.    So that the entries that you have made with transactions SU24 and SU25 become effective, you must set the profile parameter AUTH/NO_CHECK_IN_SOME_CASES to “Y” (using transaction RZ10).

All of the above checks must be successful so that the user can start the transaction. Otherwise, the transaction is not called and the system displays an appropriate message.

07. SAP Authorization Concept Modules

SAP Authorization Concept Modules

The SAP authorization concept modules are color-coded in the hierarchy display.

The basic SAP authorization concept terms are displayed below, before you specify the authorization field values. The colors of the SAP authorization concept modules are the standard colors in the following hierarchy display.

Explanation of terms:

Object class	Object classes have an orange background in the hierarchy display. Authorization objects are divided into classes for comprehensibility. An object class corresponds e.g. to an application (Financial accounting, etc.) The SAP authorization concept object classes are under Tools > Administration > User maintenance > Authorizations.
Authorization objects	Authorization objects have a green background in the hierarchy display. You may need several authorizations to perform an operation in the SAP System. The resulting contexts can be complex. The SAP authorization concept, based on authorization objects, has been realized to provide an understandable and simple procedure. Several system elements which are to be protected form an authorization object. An authorization object allows complex tests of an Authorization for multiple conditions. Authorizations allow users to execute actions within the system. An authorization object groups up to ten fields that related by AND. For an authorization check to be successful, all field values of the authorization object must be maintained in the user master. You get the authorization object documentation by double-click on an authorization object. The documentation describes how you maintain the authorization values.
Authorizations	Authorizations have a yellow background in the hierarchy display. Authorization fields are light blue and their values are white. An authorization enables you to perform a particular activity in the SAP System, based on a set of authorization object field values. The programmer of a function decides whether, where and how authorizations are to be checked. The program determines whether the user is authorized to perform an activity by comparing the specified authorization object field values in the program with the authorization values in the user master record. T_9092029701 is an authorization for the authorization object F_KNA1_BUK with the following values: *for company code and 01,02activity Use of an authorization: Specifies permissible authorization object field values. Contents: One or more values for each field. Authorizations allow you to specify any number of values or value ranges for a field. You can also allow all values, or allow an empty field as a permissible value. Changes: All users with this authorization in their authorization profile are affected. You can maintain authorizations manually with reference to the authorization object documentation or by double-click on a value field in the following dialog box: You can select individual field values or choose Full Authorization.
Profile	User authorizations are not usually assigned directly to user master records, but grouped together in authorization profiles. Authorizations can be collected in authorization profiles to reduce the maintenance effort which would be required to enter individual authorizations in the user master record. Access authorization changes affect all users with the profile in their master record. You can create profiles manually, but you should use the Profile generator. Use: Specifies authorizations in user master records Contents: Specific access rights, identified by an object name and a corresponding authorization name. Changes only take effect when the user next logs on. Users who are logged on when the change takes place are not affected in their current session. In the example, T_58000097 is an authorization profile containing company code authorizations.
User Master Record	These enable the user to log onto the SAP System and allow access to the functions and objects in it within the limits of the specified authorization profiles. Changes only take effect when the user next logs on. Users who are logged on when the change takes place are not affected in their current session. In the example a user whose user master record contains the profile T_58000097 can perform the activities in the profile authorizations.

When a transaction is called, a system program makes various checks to ensure that the user has the appropriate authorization.

Is the transaction code valid? (table TSTC check).

Is the transaction locked by the system administrator? (table TSTC check).

Is the user authorized to call the transaction?

The authorization object S_TCODE (call transaction) contains the field TCD (transaction code). The user must have an authorization with a value for the selected transaction code.

Does the transaction code have an authorization object? If so, a check is made that the user has authorization for this authorization object.

If one of this checks fails, the transaction is not called and the system sends a message.

If the transaction is called, it calls an ABAP program which makes further authorization checks with the AUTHORITY-CHECK command. The programmer specifies an authorization object and the required values for each authorization field.

AUTHORITY-CHECK checks whether a user has appropriate authorization. To do this, it searches in the specified authorization profile in the user master record to see whether the user has authorization for the authorization object specified in the command.

If the authorization is found and it contains the correct values, the check is successful.

Authorization check scenario contains an example of the use of the AUTHOR