A discussion of SAP security for a particular application area, like HR, FICO, SD, MM generally starts with an outline of the applications/transactions for the particular area and the authorization objects needed to secure them. This is fully justified as most of the time, security administrators are given a list of tcodes and asked to provide security for them. Starting from the t-code list we would normally look up the individual SU24 entries, look up the documentation for the linked authorization objects, determine if the default values of the linked authorization objects are enough to grant access, investigate whether the SU24 entries for the transaction should be changed and maintain appropriate values for the objects in the roles depending on requested access.
In the present article, we will adopt a slightly different approach for HR. Instead of the transactions that we are trying to secure, let us instead start with a discussion of the data we are trying to secure. SAP application security is remarkably consisitent while accessing the same data, even though data is accessed through different transactions. So once we get a hang of the authorization objects needed to secure a class of data, we can basically use the same objects to secure any transaction which use the same data. HR data, other than configuration data, are contained in three basic groups of tables.

Personnel Administration (PA) data consists of attributes for people, whether employees or applicants and is stored in the PA infotypes. We have already come across PA data in our introductory article on Infotypes. Each infotype in general is associated with a table in the Data Dictionary. Data for employees are stored in PA tables while data for applicants are stored in PB tables. For ex, employee addresses will be stored in PA0006 while applicant addresses is stored in PB0006. All PA and PB tables share a common authorization group PA. So unless we are prepared to modify the default authorization groups for each table, a person with access to PA authorization group through standard table maintenance transactions (like SE16, SM30, SM31), will have access to ALL the PA/PB tables. Due to the sensitive and private nature of PA data, this level of access is rarely given to any user in a production system. Instead access is given to individual infotype, subtype combinations. The authorization objects to secure PA data for employees are P_ORGIN (CON), P_ORGXX (CON) and P_PERNR while P_APPL is used to secure PA data for applicants.

Personnel Planning (PP) data store for “HR Objects”. These objects are identified by letter codes like Person (P), Position (P), Organization Unit (O), Job (C), Cost Center (K), Task (T), etc. These different HR objects are used for Personnel Planning, Personnel Development or Organizational Management. PP data is also stored in infotypes but the underlying tables are of the form HRPXXXX where XXXX = unique infotype id. (Ex Infotype Object (1000) is stored in table HRP1000. Some PP infotype like IT 1017 have both a corresponding HRP and HRT tables, HRP1017 and HRT1017. This is determined by the structure of the infotypes and deson’t impact security). Security for PP infotypes is controlled by authorization Object PLOG.

The final major type of HR data are contained in HR clusters. These are cluster tables PCL1, PCL2, PCL3, etc which store time evaluation results, payroll results, etc. Access to HR payroll clusters is controlled through the P_PCLX authorization object.

Now let us leverage our knowledge of the different types of HR data and the corresponding authorization objects to provide security for one of the most common HR transactions, PA30 which allows the maintenance of HR Master Data.Specifically we use the transaction to maintain the address of a user. The first screen shows the initial PA30 screen when we have selected the user to modify.

Now we select the address infotype and click the change button which leads us into the Address screen. We can update the address maintained for the employee. In addition PA30 allows us to save maintain text for an infotype entry by using the menu path Edit->Maintain text. An infotype with maintained text is indicated by the higlighted text icon in the infotype header as shown below.

In the sequence of actions above we update address (IT 0006) of an employee. Since address is an attribute of an employee we know that we are dealing with PA data. As a double confirmation, address data is stored in IT 0006 which falls in the range of PA infotypes (refer to the earlier post on infotypes for individual ranges). Hence we would need to provide update access (W = Write )to authorization objects P_ORGIN (CON), P_ORGXX (CON) and P_PERNR for infotype 0006. Which of these objects are actually checked are determined by the values of the authorization switches which we have already encountered in an earlier post. In addition to the actual address we also maintained some text for the infotype entry. This text however is not stored in the infotype table but in cluster tables. So an update access to P_PCLX is needed as well. The su24 entry for PA30 makes our job easy as it already provides the default cluster id which stores the text (clusters PC and TX). We are not updating attributes for any HR objects in the above sequence. So we do not need to be concerned with PLOG. However, there are other operations in PA30 which infact updates PD data. Hence, SU24 defaults for PA30, list PLOG as well.

The above analysis becomes specially useful when trying to secure obscure t-codes without correct SU24 defaults maintained. Once we understand what kind of data the t-code is accessing, we can predict what all security is needed to execute it.