Show TOC

Define Authorization Objects for the Information System

In this IMG activity, you define objects which protect the CO-PA information system. Each authorization object can consist of up to 10 fields, which you define as you wish. These fields can be the characteristics which have been defined for the operating concern as well as value fields and elements of specific key figure schemes. All the characteristics and value fields which are not specified in the authorization object are allowed.

You can create a number of authorization objects which are linked to one another by selecting up to 10 objects several times. However, it is recommended that you create one authorization object with many fields instead of several with just a few fields. The "AND" relationship between the objects can lead to difficulties when you create authorizations for the individual users. See also "Example for the use of authorization objects".

The system checks the user's authorization before he or she executes a report. If the user lacks authorization for even one object, the system denies access.

You can define a user's authorizations from the main R/3 menu by choosing Tools -> Administration -> User maintenance.

If desired, you can activate characteristic derivation for the authorization check. In this case, the system checks the user's authorization for all the characteristics that can be derived. For the system to do this, the user must have authorization for the activity "B3" (Derive) in authorization object "K_KEPL_TC" (Sales and profit planning). In addition, the set/get parameter "RDA" must have the value "X" in the user parameters.

The following authorizations are allowed for objects:

This means that the user has authorization for all the values of the characteristic or all key figures. If intervals are defined in the form, the user needs the authorization "*" for these fields. It would be better, however, to use the "More" function and enter the individual values of the interval.
The user also needs the authorization "*" for all the drill-down characteristics in the list. If at the same time the user should only have authorization for some of the characteristic values, you need to use another characteristic. This characteristic must be used in all the reports and at least one authorization object.
This means that the user is only allowed to see total values for this characteristic.
This means that the user is not authorized for any values of the characteristic. That is, he or she can only see data records to which no value of that characteristic is assigned.

The following tables demonstrates how the system checks your entries against an authorization object:


    Field content   *           Y           #       does not exist



Authorization:



  *                 x           x           x           x



  (A,Z)             -           x           -           -



  X                 -           -           -           -



  #                 -           -           x           -



  :                 -           -           -           x

Note

Through creating an authorization object with the characteristics "Customer" and "Product", you can prevent reports which could slow down your system significantly:

1. Customer *
Product 01000000 to 01900000 (or the valid characteristic values)

2. Customer 04500000 to 04800000 (or the valid characteristic values)
Product *

These two authorizations let the user create a list of products for the selected customer and a list of customers for the selected product. However, he or she cannot create a single list of all the customers and products, something which would load down your system significantly.

The authorization object consists of the fields "Product" and "Element of the key figure scheme".

User X is to have authorization to look at the values of the key figure scheme ZZ up to contribution margin I for product 00001000. Element 2000 of the key figure scheme contains this value. In order to do so, the user needs the following authorizations:
Product 00001000
Elem. of key figure scheme ZZ0001,ZZ2000
User Y is authorized to see all the data of key figure scheme ZZ for all products. He has the authorizations:
Product *
Elem. of key figure scheme ZZ*

An example of how you can use one object instead of two.

A user is supposed to execute two reports: one report on the company 1000 broken down by company codes (which belong to this company), and one report on the company code 0001 broken down by business areas. However, the user is not allowed to execute a report for any random company code.

1st case: You created an object with the fields "Company" and "Company code" and another object with the fields "Company code" and "Business area".

User X has the following authorizations:
Company 1000,:
Company code *
and
Company code 0001
Business area *
The user cannot run the first report on company 1000 broken down by company codes, even though he has authorization for the first object, because this report also requires him to have authorization for company code "*" and business area ":" in the second object. If the user had this, however, he or she could run reports on any company code.

2nd case: You created only one authorization object with the fields "Company", "Company code", and "Business area".

The user has the following authorizations:
Company 1000,:
Company code *
Business area :
and
Company :
Company code 0001
Business area *
Here the user can execute a report on company 1000 broken down by company codes and a report on company code 0001 broken down by business areas.

By combining the three fields in the same object, you can achieve greater control than if you create more than one object.

Activities

Define your authorization objects for the information system.