Show TOC

Editing Authorization Default Data (Development System)Locate this document in the navigation structure

Developers define, in transaction SU22, which authorization objects are required for their application. Transaction SU22 displays a list of authorization objects that the trace has logged for the selected application. Developers need to classify these objects by assigning the authorization default status.

Procedure

  1. Start the maintenance tool for authorization default data (transaction SU22).

  2. Specify the applications for which you want to edit the authorization default data, and choose Execute.

  3. Double-click an application under Selection Result.

    The system displays which authorization objects the authorization trace logged in the context of this application.

    The displayed list contains, among other things, objects that do not belong to your application, but which were called when testing the application. You therefore need to classify these objects by setting the default status, to identify those that are relevant for your application.

Manually Adding Authorization Objects

To include additional authorization objects in the list of objects, choose the Object button and then Start of the navigation path Object Next navigation step Add Authorization Object End of the navigation path.

To remove the assignment of a manually-added authorization object, select the line, choose the Object button, and then Start of the navigation path Object Next navigation step Remove Authorization Object End of the navigation path.

Do not remove authorization objects that have been automatically assigned by the authorization trace. The system will always reassign these objects.

Setting the Authorization Default Status of Objects

Authorization objects for which you have not yet maintained an authorization default status do not have an entry in the Proposal column.

To change a default status, select one or more lines on the Authorization Objects tab, and use the Proposal button to choose one of the following statuses:

  • No

    By setting this authorization default status, developers inform administrators that a user does not require an authorization for this object to execute the core functionality of this application. Do not confuse this with the check indicator for transactions with which the check is deactivated.

    For more information about check indicators, refer to the section Editing Check Indicators for Objects.

    If the administrator adds the application to a role, the profile generator does not place an authorization for this object in the role.

  • Yes

    By setting this default status, developers inform administrators that the user requires an authorization for this object to execute the core functionality of the application. If the administrator adds the application to a role, the Profile Generator adds an authorization for this object in the role. The consequence is that the Profile Generator includes an authorization for this authorization object in the role authorizations using the delivered authorization default values.

    The fields of the authorizations are predefined with the proposed values. If you do not specify any values, you can specify Yes, Without Values. Deliver default values for the fields of the authorization object for which you know which values will be checked in customers' systems. Leave fields with customer-specific content empty.

  • Yes, Without Values

    By setting this default status, developers inform administrators that the user requires an authorization for this object in order to execute the core functionality of the application. However, the developers cannot specify any values, since these are only determined in the customer system.

    If the administrator adds the application to a role, the Profile Generator places an empty authorization for this object in the role.

Guidelines for Setting the Default Status

  • Authorization objects that you explicitly check in your own code with AUTHORITY-CHECK usually receive the authorization default status Yes or Yes, Without Values.

  • If users cannot use the core function of an application without a particular authorization, you need to assign the default status Yes or Yes, Without Values for this authorization object.

  • If an authorization object is specified in transaction SE93 in the definition of a transaction as an additional start authorization check, you need to assign the authorization default status Yes to this authorization object in transaction SU22. As default values for the field values, set at least the values entered in transaction SE93.

  • Basis and HR authorization objects that are checked outside HR or Basis applications usually receive the authorization default status No.

  • The start authorization check is a special case and affects the authorization objects S_TCODE, S_START, S_RFC, and S_SERVICE. For technical reasons, transaction SU22 always includes the start authorization object associated with an application (for example, S_TCODE for transactions). You do not need to set the authorization default status Yes for these authorization objects. Since the Profile Generator automatically inserts a start authorization for your application into the role, do not enter the name of your application as the authorization default value. Leave the authorization default status set to No.

Editing Authorization Default Values

You have the following options:

  • To display authorization objects with the default status Yes, double-click the Yes field. Alternatively, select one or more lines in edit mode, choose the Default button and then the relevant status.

  • To start the trace evaluation tool, choose the Evaluate Trace button. The trace evaluation displays the recorded authorization checks including the checked authorization values. You can copy relevant values.

    You can use both the authorization and the system traces for this purpose. You can use both traces either locally or in a remote system. More information: Maintaining Authorization Default Values Using Trace Evaluation in Transaction SU22 or SU24 or in the system by choosing the information button.

Guidelines for Setting the Default Values

  • For fields that describe activities or other fixed values, enter the values that the system checks during the authorization check for your application.

  • For authorization objects that contain the activity field ACTVT, enter only activities that the developer stored as permitted activities in the definition of the authorization object.

  • Fields that describe organizational units are automatically filled with a corresponding variable, $VARIABLENNAME that the system later fills when a role is created. Leave this variable name unchanged.

  • Leave fields empty if they are to contain customer-specific data.

    If you transfer values into fields that customers should really fill with their Customizing, these fields are not highlighted when maintaining roles, because they are not empty. Customers will therefore not fill these fields with data that is appropriate for them. These authorizations are unusable for customers. Customers will only find them cumbersome, particularly for roles with many authorizations.

  • Never enter the asterisk (*) for full authorization. This is usually incorrect. The customer can easily assign full authorization for empty fields himself or herself in the profile generator.

    Only enter the asterisk (*) for full authorization as an authorization default if a user actually requires full authorization for the application. This is the case, for example, if the authorization check explicitly checks for the value asterisk (*). If you do not know what values will be checked in customer systems, leave the field empty. The Profile Generator highlights the empty field for the customer administrator during role maintenance, so that he or she can enter the suitable value for their purposes. The asterisk (*) for full authorization, on the other hand, means that the field is not empty, and that the Profile Generator does not highlight it during role maintenance. The customer will leave the full authorization in place, instead of entering discrete authorization values. This means that the customer unknowingly assigns unnecessarily extensive authorizations.

  • In the case of authorization object fields that are not used by your application that the system checks against DUMMY in the ABAP statement AUTHORITY-CHECK, enter the value ' ' with quotation marks or, for fields with a length of 1, a single quotation mark ( ').

  • Never provide empty authorization defaults or default values filled with the asterisk (*) for full authorization for start authorization objects ( S_TCODE, S_START, S_SERVICE, S_RFC). This leads to dangerously extensive authorizations in the customer system. If you are not entirely sure that you need to deliver an authorization default for one of these objects, assign the authorization default status No.

  • If you are not able to specify authorization default values for any field of an authorization object (for example, because the authorization object only has Customizing fields), set the authorization default status to Yes, Without Values instead of Yes. If an authorization administrator includes your application in a role, the Profile Generator places an authorization for this object in a role, but does not predefine any fields with a default value.

Editing Check Indicators for Objects

In the case of transactions, you can also control the authorization check with check indicators that are set for each authorization object.

To change a check indicator, select one or more lines on the Authorization Objects tab page, and use the Check Indicator button to choose one of the following statuses:

  • Check

    Default check indicator

  • Do not check

    The authorization check for this authorization object is deactivated. The system does not check whether the user has a suitable authorization.

    Applies for a particular authorization object for a transaction and means that the authorization check for this object is deactivated for this transaction and is therefore always successful. This means that the ABAP statement AUTHORITY-CHECK always returns sy-subrc=0, meaning that the authorization check has no effect. The check therefore does not determine whether the user has a suitable authorization. Therefore set this value only in exceptional cases. It is never permissible for Basis and HR authorization objects. If a transaction cannot be used without a specific authorization, it is usually wrong to assign the check indicator Do Not Check for this authorization object. Instead, leave the check indicator set to Check, set the authorization default status to Yes, and assign appropriate authorization default values. In this way, the users receive a suitable authorization if an administrator adds the transaction to a role. If you cannot specify any meaningful authorization default values, set the authorization default status Yes, Without Values.

Setting the Maintenance Mode for the Application

You can assign a maintenance mode for applications for which all default statuses and field values have been assigned for the authorization objects.

To do this, on the Properties tab page, choose one of the following modes in the Maintenance Mode field:

Caution

Note that if you set the mode I or O that you do not deliver any default values with this setting. If you make an incorrect setting here, it can cause problems for the customer when preparing role authorizations.

  • Empty field (normal maintenance (manual))

  • A (Automatic maintenance of all authorization objects)

    Authorization objects that are newly assigned to the application by the authorization trace automatically receive the status No authorization default values (previously “check”).

  • B (Automatic maintenance of only Basis authorization objects)

    Basis authorization objects that are newly assigned to the application by the authorization trace automatically receive the status No authorization default values (previously “check”).

  • I (irrelevant, application does not require any authorization default values)

    It is not possible or meaningful to deliver authorization default data for the application. You therefore do not need to maintain the authorization default data. This can be the case, for example, for very generic applications, for which the precise business purpose is not determined.

  • O (obsolete)

    The application is obsolete. It is therefore not meaningful to deliver authorization default data for this application and you no longer need to maintain the authorization default data.

Note

With modes A or B, the trace automatically sets newly-found authorization objects to the default status No. Set these values only for applications that have already been delivered in several releases with no changes and for which you therefore do not expect significant changes to the authorization default data.