Use sap authority object to control permissions

Use sap authority object to control permissions

I have heard that sap authority object is relatively easy to use for permission control. I am lucky to practice it today.

The following is a simple but complete example of authority-check:

1.Create Data Element ------- (t-code SE11)

Name: z_ele_01

2.Create a domain ------- (t-code SE11) for z_ele_01)

Generally, you can use the existing domain. Here I use char04

<! -- [If! VML] -->
<! -- [Endif] -->

* If You Want To Configure permissions in the future, use the domain you created here. The specific method is as follows:

A. Create me11

 

B. Set field properties

 

C. Set optional values

 

3.Create authorization fields ----- (t-code su20)

Here you can make some settings, use this field as an option or make some settings for search help.

Field name	z_ath_fld_01
Data Element	Z_ele_01

<! -- [If! VML] --> <! -- [Endif] -->

4.Create an object class ----- (t-code su21)

 Multiple authorization objects are stored in an authorization class. In fact, the class is not only used to classify authorization objects. Therefore, you can add the authorization object to be created in the existing class. Of course, you can also create

 

object class	z_ath_cls_01
Text	Authorization class 01

 

5. Create authorization object ----- (t-code su21)

Multiple authorization fields are stored in an authorization object. After creating an object, you need to assign z_ath_fld_01 assign to it.

 

6.SetAuthorization object assign to T-code/edit authorization object

-----(T-code su24)

This step can be selected as needed, that isAuthorization object is not assigned to T-code.

<! -- [If! VML] -->
<! -- [Endif] -->

<! -- [If! VML] -->
<! -- [Endif] -->

In addition, you can useT-code su22 for management

<! -- [If! VML] -->
<! -- [Endif] -->

7.Create a role and set the role's authorization object ----- (t-code pfcg)

 In fact, basis is enough. As a coder, just create a role to test whether the assign is successful to the desired T-code.

 

8.Create TestProgram

Report zath01.

Data: zath_fld (20) value '01 '.

Authority-check object 'z _ ath_obj_01'

Id 'z_ath_fld_01 'fieldZath_fld.

Write:/zath_fld.

* This function can only determine whether a permission exists and cannot return the value set in the permission field.

 

9.Run the program

You must log out of the system and then log on to the system.

 

* Today, I spent a lot of effort to test permissions, because I forgot to inherit permissions and used an "unclean" account.

 

-------------------------------------------- PermissionArticle-----------------------------

Intuitively, permission is the combination of "someone can do something" and "someone cannot do something. In the SAP system, transaction codes (also called transactions) are used.Code, Or tcode, or transaction code) indicates what a user can do. For example, the tcode mm01 is used to maintain material data, migo is used to receive goods, and fs00 is used to maintain accounting subjects.

When you create an ID with su01, the default permission is blank, that is, the newly created ID cannot do anything, nor use any transaction code. In this way, you only need to assign the corresponding tcode to the corresponding ID to achieve "someone can do something". The supplement is "something someone can't do ".

However, we cannot directly assign tcode to an ID in su01. We need to use role to transfer the code. That is, a bunch of tcodes constitute a role, and then the role is assigned to an ID, and then the ID gets a bunch of tcodes.

The above are just the basic concepts of SAP permission control. To understand all SAP permission control, you must also understand the following concepts.

1. Roles, common roles, and local roles)

As mentioned above, roles, that is, role, are a collection of tcodes, of course, it also contains "permission objects", "permission fields", "allowed operations", and "Allowed values" necessary for tcode. We use pfcg to maintain roles.

To implement system testing and SAP implementation, roles are further divided into general roles and local roles ".

For example, it is easy to understand: A general role is like a "production order processor". A local role corresponds to "Great Wall International assembled a factory production order processor ". Therefore, the difference between a local role and a general role is that, with the same operation permissions (transaction code), the former has more specific restrictions. This restriction value may be an organizational structure restriction or a limitation on other services. For example, the ticket maker of a branch factory cannot maintain the ticket maker of a branch factory. The ticket maker of a branch factory can only maintain the document of type A, but cannot maintain the document of type B, and so on.

For details, refer to the following concepts.

2. Authorization object, authorization field, allowed activity, and allowed field value)

As mentioned above, the role consists of several tcodes. In fact, there is an intermediate concept "permission object" between role and tcode ":

The role contains several permission objects and stores the relationship between them in the transparent table agr_1250;

The permission object contains several permission fields, permitted operations, and permitted values. The relationships between role, object, field, and value are shown in the transparent table agr_1251;

There is a special permission object that contains several transaction codes. This permission object is called "s_tcode", and the permission field of this permission object is called "TCM". The value allowed by this field (Field Value) stores the transaction code;

A special permission field is used to indicate the operations that can be performed on the permission object. It allows creation, modification, display, deletion, or other operations. This permission field is called "actvt". The value allowed by this field stores the code that allows the operation. 01 indicates creation, 02 indicates modification, and 03 indicates display;

In other words, the permission Control Mechanism of sap can check whether you have the permission to maintain a field in a transparent table.

The SAP system comes with several permission objects and controls several permission fields by default (corresponding to some fields in the transparent table ). You can use the transaction code su20 to view the system's permission fields and su21 to view the system's default permission objects.

So we know the difference between the transaction code and the permission object. From the perspective of permission control, transaction code is a special permission object. During the execution of a transaction code, to determine whether an ID has the right to execute this transaction code, you may also check several other common permission objects. Use su22 to view the permission objects contained in a transaction code. In the transparent table usobx, the transaction Code corresponds to the permission object.

3. Custom permission object

The built-in permission objects and permission fields mentioned above can only meet limited requirements. The permission review logic is also hardcoded by the system, all we can do is whether to enable the check of a permission object (using su22 ). If you need to customize it, use su20 and su21 to define it. Add similar code to the program during the call:

Authority-check object 'z _ vkorg 'id' vkorg 'field 'rec _ VKORG-VKORG '.
If SY-SUBRC <> 0.
Message 'no authorization! 'Type '.
Endif.

Conclusion:

This article only gives a technical description of the system and does not integrate the actual business. However, we have outlined a general permission matrix, which is the operator (ID) in the vertical direction ), some permission objects are horizontally divided into several transaction codes, permitted actions, permission fields, and permitted values.

In actual business, whether the permissions need to be so detailed depends on the preferences of a leader, the law that cannot be jumped, and the internal rules and regulations of the enterprise.