What are Authorization Objects Authorization objects are composed of a grouping of fields.

The values in these fields will be used in authorization check. There can be a maximum of 10 fields defined on an authorization object. Basically we use this authorization objects to check whether the user is having an authorization to run particular transaction. We assign authorization objects to a role with specific ACTVT type. For example a user is authorized only to view, other could be authorized to modify and so on. IF your use rid not attached to specific role then contact your basis team to resolve the problem by sending SU53 screen shot. AUTHORITY-CHECK is the statement used in an ABAP Program to perform an authorization check against an authorization object. This statement will return sy-subrc is 0 if user has required authorization otherwise will return code will be other than Zero. Each return code will have different meaning. Example: 8 - User has to authorization. 12 - Too many parameters etc., Actions and the access to data are protected by authorization objects in the SAP system. Authorization objects allow complex checks that involve multiple conditions that allow a user to perform an action. The conditions are specified in authorization fields for the authorization objects and are AND linked for the check. Authorization objects and their fields have descriptive and technical names. An authorization is always associated with exactly one authorization object and contains the value for the fields for the authorization object. An authorization is a permission to perform a certain action in the SAP system. The action is defined on the basis of the values for the individual fields of an authorization object. A role is primarily a functional description; the technical realization of the role, in the form of concrete authorizations is achieved through the authorization profile associated with the role. What is a composite profile? A set of profiles which are included under a single profile name is called as a composite profile (SU02) How can you find missing authorizations? How can you solve? By running the SU53 transaction.Identify the authorization object where the required filed value is to be given and the do the same thru SU01 or PFCG.

Defining Authorization objects for custom database tables

Authorization Objects: Authorization Object, as the name itself suggests, is a method of restricting users to access any particular application created in the system. It could simply be: denying user for viewing confidential data onscreen or denying access to certain Transactions. Taking this feature into consideration, SAP gets the flexibility to decide at runtime whether a particular user is supposed to access a given application or not. To get an in-depth picture on the Authorization and the way it works, well look at an example which would demonstrate the use of Authorization Object and the way to use. Example: Requirement We have a few Z-tables in our system that consists of confidential data, which cannot be accessed by all users. Only authorized persons can have access to the data. So, incase these tables are being used in any program,

for display/write purpose, that program would be executed only by Authorized users. Please make sure to disable Table Entries, while creating tables, and not to create any Table Maintenance Generator also. Only this program would be used to perform read/write operations on the table. Resolution Well see, step by step, what all needs to be done in order to fulfill the mentioned requirement. Giving authorization to access (read / write) into z-tables Steps: 1. To begin with Authorization Object, well enter the Tcode: SU21. Here, we will create the following, in the order shown: I. II. Object Class Authorization Object

2.

On clicking the Object Class (as shown in the above screen shot), youll see the window shown below. Enter the Object class name, description & click on SAVE. You can also use available objects, to create your Authorization Object. Like incase of HR module, you can make use of Object Class HR, then you need not

create

one.

3.

Once you create Object class (E.g. Test), youll see a folder with that name in the list. Now your object class is ready. We will need this Object class to encapsulate the Authorization object that we will be creating. Click on the Object created, and then click on Create - Authorization Object (shown in the figure step 1). On licking, youll see the below shown screen. Give respective field name, in our case, PERNR (Employee Number), as shown in the diagram. We will be keeping a check on the employee number, and see if the employee has authorization to access the report (made to view z-tables) or not.

4.

Now, we need to create a Role, inside which we will attach our Authorization Object. Enter Transaction code: PFCG to create a role.

Select the Authorizations tab. And Click on the icon next to profile name, as shown in the figure above. On the click of that icon, the system will generate a Profile name and a description for the same. 5. Click on the Change authorization data as shown in the figure below:

Youll see a new screen with the Role Name on top left. Here you will have to add your Authorization Object that was created in SU21. 6. Click on the Manually button shown in the toolbar, to add the Authorization object, as shown in the figure below. Here you can add your Authorization object in the list and press enter.

7.

Now you need to add values (Employee numbers) in your object, for those who would be given authorization. In our case, we will put a * symbol (to allow the system to provide access to any employee, which is Assigned this role).

8.

Press Save and then Generate the profile by clicking on generate icon.

9.

Finally you come out of the screen pressing back button. And you will see the Authorizations tab with a Green symbol, meaning, Authorization object has been assigned and the role can be used.

10. After these steps, if you want to give authorizations to say Employee No.: 96. Go to TransactionSU01, click on the Roles tab and assign our role name, in our case : test_role.

This way, you can assign this role to all those users, who are supposed to be authorized to access the report (for data entry in the table). 11. Finally, in the main program, which has been created, we need to write a small code, as shown below, which will decide if that employee is authorized or not: REPORT ZCHECK_AUTH. DATA : L_PERNR TYPE PERNR_D. SELECT SINGLE PERNR INTO L_PERNR FROM PA0105 WHERE UNAME EQ SY-UNAME AND USRTY EQ '0001' AND BEGDA LE SY-DATUM AND ENDDA GE SY-DATUM. AUTHORITY-CHECK OBJECT 'Z_OBJECT1' ID 'PERNR' FIELD L_PERNR. IF sy-subrc <> 0. MESSAGE 'No authorization' TYPE 'E'. ELSE. **** Here you can have the Query to view the table or perform any **** action related to the Z-tables

MESSAGE 'Congrats! You are authorized' TYPE 'I'. ENDIF. If the user passes this authorization check, the return code SY-SUBRC is set to 0. Hence, users who are not assigned the Role, if they try to access this report; theyll not be able to do the same. This way, you can provide authorizations on any Z- objects. Introduction on Authorizations Authorization objects enable complex checks of an authorization, which allows a user to carry out an action. An authorization object can group up to10 authorization fields that are checked in an AND relationship. For an authorization check to be successful, all field values of the authorization object must be maintained accordingly. The fields in an object should not be seen as input fields on a screen. Instead, fields should be regarded as system elements, such as infotypes, which are to be protected. You can define as many system access authorizations as you wish for an object by creating a number of allowed values for the fields in an object. These value sets are called authorizations. The system checks these authorizations in OR relationships. Key Authorization object for HR P_ORGIN HR: Master Data This authorization is used to restrict access to personnel master data. The authorization level field specifies the access mode. The following authorization levels exist: Authorization Field INFTY SUBTY AUTHC PERSA PERSG PERSK VDSK1 Long Text Infotype Subtype Authorization Level Personnel Area Employee Group Employee Subgroup Organizational Key

R (Read) for read access M (Matchcode) for read access to input helps (F4) W (Write) for write access E and D (Enqueue and Dequeue) for write access using the Asymmetrical Double Verification Principle. E allows the user to create and change locked data records and D allows the user to change lock indicators. S (Symmetric) for write access using the Symmetric Double Verification Principle * always includes all other authorization levels simultaneously Problems can arise in some programs when write authorizations exist but no read authorizations. To avoid this, you should always specify R along with the authorization levels W, E, D, and S.

This applies for authorizations with PSIGN = I in the P_PERNR authorization object. In certain cases, it is appropriate not to enter read authorizations for authorizations with PSIGN = E. This is not an exception to the rule. PSIGN = Ecan be used to deny authorizations, which is, of course, allowed. This can occur, for example, if you have specified an authorization using P_ORGIN and authorization level *, and then use P_PERNR to determine that the user should be authorized to display his or her own data but not change the data. In this case, you would specify an authorization for P_PERNR with AUTHC = W, E, D, Sand PSIGN =E.