SAP Permission Object Anthology

SAP Permission Object Anthology

SAP's permissions are controlled by authorization objects, and all transaction codes, roles, etc. are ultimately reflected in the system as authorized objects. When you run the transaction code in SAP, the system first checks to see if the S_tcode has the specified transaction code in this authorization transaction, and if so, you can use this tcode. But after this, does not mean that you can do the operation of the business to complete, in different places, the system will also check other authorized objects, such as the operation to the accounting voucher of the company code related transactions, the system will check F_bkpf_buk this authorization object, only after this check passed, can continue to go down.

The code for the System check authorization object is generally:

Authority-check OBJECT F_bkpf_buk for user Zhangsan01
ID ' ACTVT ' FIELD Act_hinz
ID ' Bukrs ' FIELD bkpf-bukrs.
IF SY-SUBRC NE 0.
MESSAGE e083 with Bkpf-bukrs.
ENDIF.


This statement examines whether Zhang San (zhangsan01) has permission to f_bkpf_buk this authorization object, and if not for user Zhangsan01, checks the current user's permissions.
Note that only the authorization object is checked, there is no single role and no composite role, that is, although we assign a lot of roles to the user, the system ultimately checks the authorized objects of those roles, and is the authorized object that does not divide the roles. This creates a situation where permissions overlap.

For example, Zhang San has a company credentials to view the rights, and B Company vouchers to post the rights, if he also has s_tcode:fb01 authorized objects, this time he is a, b two companies posting and viewing permissions. So, you have to pay attention when assigning permissions.

Use transaction code SE93 to view permission objects;
The authorization object is not brought out after the transaction code is added, because the permission object is not included under this transaction code

When you create a new ID with SU01, the default permissions are blank, that is, the new ID cannot do anything, and you cannot use any transaction code. This will only need to assign the corresponding ID to the corresponding Tcode, you can achieve "someone can do something", its complement, is "something that someone cannot do."
But we can not directly in the SU01 to give an ID to the Tcode, to pass through role to relay a bit. That is, a bunch of tcode make up a role, then assign the role to an ID, and the id gets a bunch of tcode.
Above, just the primary concept of SAP permissions control, to understand all of SAP permissions control, you must also understand the following concepts.
1. Roles (role), composite roles
It says that roles, role, is a collection of tcode, and of course contains the tcode necessary "permission objects," "Permission fields," "Allowed actions," "allowed values," and so on. We use PFCG to maintain roles.
A composite role can contain multiple individual roles.
See the following concepts for details.
2. Permission objects (Authorization object), Permission fields (Authorization field), allowed operations (Activity), allowable values (field value)
Some of the tcode that make up the role are roughly described above. In fact, between role and Tcode, there is also an intermediate concept "permission Object":
The role contains several permission objects, and the relationship between them is stored in the transparent table agr_1250;
The Permission object contains several permission fields, allowed actions, and allowable values, which embody the relationship between role/object/field/value in the transparent table agr_1251.
There is a special permission object that is used to contain several transaction codes. This permission object is called "S_tcode", the permission field of the permission object is called "TCD", the field value allowed (field value) is the transaction code;
There is a special permission field that indicates what actions can be made against the permission object, which is allowed to be created, modified, displayed, deleted, or otherwise. This permission field is called "ACTVT", which allows the value (field value) to be stored in the code that allows the operation, 01 for creation, 02 for the modification, 03 for display, etc.;
The permissions control of SAP is controlled to the field level, in other words, its permission control mechanism can check whether you have permission to maintain a certain field of a transparent table.
The SAP system comes with several permission objects, and the default controls several permission fields (corresponding to certain fields of the transparent table). You can use transaction code SU20 to see what permission fields the system has, and SU21 to see what default permission objects the system has.
So we know the difference between the transaction code and the Permission object. From the scope of permission control, transaction code belongs to a special permission object; During execution, a transaction code may examine several other normal permission objects in order to determine whether an ID has permission to execute this transaction code. Use SU22 to see which permission objects are included in a transaction code. In the transparent table USOBX, the correspondence between the transaction code and the permission object is stored.
3. Custom Permission Objects
As mentioned above, the system's own permission object and the permission field can only meet the limited needs, and the logic of its permission auditing is also hard-coded, and all we can do is to check whether a permission object is enabled (using SU22). If you need to customize, you can define it by SU20, SU21.
The difference of SY-SUBRC return value after Authority-check also represents a different meaning, here a little which comes:
0
Permission Check succeeded
4
The user has no such permission
8
Specify too many IDs (up to 10) when writing ABAP Authority-check
12
There is no such authority object in the user information
16
There is no such profile in the user information
24
The specified fild name does not match the field required by ID in Authority-object
28
Incorrect user information
32
Incorrect user information
36
Incorrect user information
1.su20 Creating a Permission Object Field example: ZPOWERFLD1
Create a Permission object field (stored in the AUTHX table) that specifies the data element in the table.
2.su21 creating Permission object classes and Permission Objects Example: Object class: Select the default WG Retail object: ZPOWER1
Create a Permission object category (stored in the TOBCT table)
Click on the object category to create a permission object (stored in the Tobj table), generate Sap_all, the creation of the time required to fill in the Permission object fields, but also can be added ACTVT,ACTVT there are many values, such as 02 modifications, 31-like display permissions
Need to take effect immediately, click on the upper left corner Sap_all
3.SU01 generating a parameter file example: Zautoprof
Environment-Maintenance parameter file Enter the parameter filename, click Create parameter file's workspace-Enter after new-enter permission object and permission (own name, example: Zautho), double-click Zautho, you can set the value of the permission field under the Permission object (the value entered in the program is in this domain), Note activation
4.PFCG assigning permissions to a role example: Zrolea
Create a new permission role, the second column is a menu, you can add a transaction code (you can choose 1. Add Standard or 2. Report, this example 2), the third column for permissions, enter the parameter file just created, click Change authorization data, you can also see the value of the set, the last click Generate (i.e.: Ball), 4th Enter the user you want to set permissions for, and specify the validity period.
5.su01 adding parameter files and roles to the user
Parameter label input parameter file, role tag enter the newly built role.
6. Examples of writing in the program: Z_authority_test
Add similar code to the program:
Report Z_authority_test.
DATA:L_STR (+) TYPE C.
Selection-screen BEGIN of BLOCK B3.
Selection-screen COMMENT 1 (Ten) TEXT-003.
Parameters:p_carrid like Spfli-carrid.
Selection-screen END of BLOCK B3.
At Selection-screen.
"Su21 the ZPOWER1 authorization object under the new WG object class, Su20 the ZPOWERFLD1 created to the authorization object
Authority-check OBJECT ' ZPOWER1 '
"Su20 ZPOWERFLD1 Authorization Object field, corresponding to the Spfli-scarr
ID ' ZPOWERFLD1 ' FIELD p_carrid.
IF SY-SUBRC <> 0.
Concatenate P_carrid ' You don't have permission! ' Into L_str.
MESSAGE l_str TYPE ' E '.
EXIT.
ENDIF.
7.su24 to find the authorization object for a transaction
Add a Permission object to the transaction code in SU24, and the permission object typically added in Se93 will appear automatically after you click the transaction code
If the transaction code has more than one permission control object, it needs to

In the project, it is unavoidable to use a custom permission object, such as the profit center of the inspection, looking for a long time, did not see, so, I built a
At first do not understand, everywhere search information, divided into several steps, as follows:
1.su20
Create a Permission object field (stored in the AUTHX table)
2.su21 Creating a Permission Object
Create a Permission object category (stored in the TOBCT table)
Click on the object category to create the permission object (stored in the Tobj table), generate the Sap_all
This is created when you need to fill in the Permission Object field, you can also add a lot of values in ACTVT,ACTVT, such as 31 as the display permission
Need to take effect immediately, click Sap_all
3. Writing in the program
Add similar code to the program:
Authority-check object ' V_vbka_vko '
Id ' vkorg ' p_vkorg
Id ' ACTVT ' 03 '.
4.su24
Add a Permission object to the transaction code in SU24, and the permission object typically added in Se93 will appear automatically after you click the transaction code
If the transaction code has more than one permission control object, you need to manually add additional permission objects yourself.

There are four identities in a permission object:
？ U C CM
Control is valid when the permission object corresponds to C or cm. The difference between them is that CM is automatically brought out when PFCG assigns permissions, and the C tag needs to be manually assigned.
5.PFCG Assigning permissions to roles
This is part of the basis, but developers need to know. Select the permission role that needs to be modified, the second column is the permission, you can add the transaction code, and then in the change user permissions, click on the Authorization object, then the previous CM tag permission object will appear, marked C will not appear, you need to manually assign.
6. Pending analysis, Se93. Se93 is mainly used to allocate the program's transaction code, this place is worth noting that the general report program selects the second item ... Otherwise, when the program runs, click on the execution, the interface will disappear ~ ~ There are also assigned permission objects, but can only fill one, do not know how to handle.



Some references: http://silverw0396.**.com/blog/90671

SAP Permission Object Anthology