Types of HR Data

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.

PA30 - Initial Screen
PA30 - Initial Screen

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.

PA30 - Update Address
PA30 - Update Address

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.

Infotypes

Infotypes or Information Types always form an integral component of any discussion on SAP HCM. In general infotypes are structures to stores related HR data. For example, address of an employee is stored in an unique infotype 0006. Similarly we have different infotypes storing personal data (0002), bank details (0009) , basic salary (0008), etc. Some infotypes are further sub-divided into subtypes, an example being the address infotype. An address entry can belong to the subtype permanent residence, temporary residence, emergency address, mailing address, etc. Infotypes are relevant from a security standpoint as SAP provides standard authorization objects which allow us to secure infotype, subtype combinations for users.

The first thing to note from the above examples is that all of them are attributes of a person. You store address of a person, salary of a person, bank details of a person. Howver, infotypes can just as well store attrbutes of HR objects like positions, jobs, tasks, etc. Depending on whether an infotype stores attributes for a person or a HR object, we can divide them into infotypes required in Personnel Administration (PA) or Personnel Planning (PP) respectively. The PP infotypes are also referrred to as infotypes for Organizational Management (OM)or Personnel Development (PD). The distinction between PA and PP infotypes is important for security as the two basic types of infotypes are secured by means of different authorization objects.

Another point to note from the above examples is the fact that each infotype is associated with an unique 4 digit number. This unique identifier might vary from 0000 to 9999 and is broken into sub-ranges depending on the type of the information stored as shown below

  • 0000 – 0999 – Personnel Administration (PA)
  • 1000 – 1999 – Personnel Planning (PP)
  • 2000 – 2999 – Time Management (PA)
  • 4000 – 4999 – Recruitment (PA)
  • 9000 – 9999 – Customer Specific (Can store either PA or PP information depending on infotype configuration

This preliminary introduction to infotypes would help us in our later discussions when we investigate ways to secure individual infotypes.

Security Tables

The names of most Security tables begin with USR, AGR or UST. Here are a few of the most common ones

  • USR02 – Users with logon data
  • USR04 – Users by authorization profile assignment
  • USR05 – Users by user parameters
  • USR10 – Profiles with authorizations
  • ARR_1251 – Authorization data for roles
  • AGR_1252 – Organizational data for roles
  • AGR_USERS – Roles assigned to users
  • AGR_PROF – Profiles defined for roles
  • AGR_HIER – Menu for a role
  • AGR_TIME – Change date/time for a role

Important Authorization Objects

SAP delivers ECC 6.0 with more than 3000 authorization objects. Remembering even a tiny fraction of the total number is a daunting task. SAP help provides adequate documentation on the fields and use of most, if not all, the delivered objects. So instead of repeating existing information here, I would just mention a few  of the existing authorization objects and their applications.

  • Tables – Security for tables are controlled through three authorization objects, S_TABU_DIS (based on the table authorization group), S_TABU_CLI (security for client independent tables) and S_TABU_LIN (row level access to tables).
  • Reports – Reports/Executable programs (Executable programs are just one of many different types of programs) can be protected through S_PROGRAM. S_PROGRAM checks if the executing user has access to the program authorization group maintained as a program attribute.
  • Background Jobs – The basic object is S_BTCH_JOB. To administer jobs created by other users, users would also need S_BTCH_ADM. To schedule jobs with the access of another user would require S_BTCH_NAM.
  • SpoolsS_ADMI_FCDS_SPO_ACT, S_SPO_DEVand S_SPO_PAGE. S_SPO_ACT can be used to give access to spools with specific authorization values. S_ADMI_FCD in addition to spools controls access to a lot of system administration/Basis function.
  • User/Roles – A number of authorizations like S_USER_AGR, S_USER_AUT, S_USER_GRP, S_USER_OBJ, S_USER_PRO, S_USER_SAS. You can segregate the access for role administration with that of user administration by use of these objects.
  • BDC SessionsS_BDC_MONI. Batch Sessions are one of the possible ways of loading data intoSAP. Sessions are monitored through the SM35 transaction. S_BDC_MONI allows security on session names and the possible activites (process, lock, delete) on sessions.
  • ABAP Work Bench – Access to ABAP development objects is controlled through S_DEVELOP. Controls are possible on object type, object name, activity, packages.

You might have noticed that all the above authorization objects begin with S as they deal with System Administration. I have purposely not included authorization belonging to the individual application components like MM, FICO, SD or HR as a discussion of these do nt make sense without discussing the applications themselves. So, we keep these for a later post.

Custom Auth Objects

Often a security administrator comes across requirements where the existing authorization objects delivered by SAP is not enough. Mostly these come during custom developments through completely new programs or enhancements to existing SAP programs. In such situations, SAP provides us with the option of defining completely new authorization objects. The names of these customer specific objects should begin with Y or Z and can be created through the SU21 transaction. If required we can define new authorization fields as well through the transaction SU20.

In the example below, we are set to create a new authorization field and use it in a new authorization object. First we go into Su20 and select the create option from the toolbar. We create a new field “ZBOOLEAN” which takes two possible values ‘X’ and ‘ ‘. The possible values for a field are controlled by the definition of the data element specified in the ABAP dictionary, in this case which is BOOLE_D. We might create our own data elements as well through SE11 transaction. On saving the new field we are prompted for a package for our new development. Packages are dictionary objects to group similar objects for transporting across development, quality assurance and production systems. We if do not plan to transport the new field we can select the local object (package $TMP) from the options.

SU20 - Create Field - Initial Screen
SU20 - Create Field - Initial Screen
SU20 - Define Authorization Field
SU20 - Define Authorization Field

Once the authorization field is created, its time to include it in a custom authorization object through Su21. We select the authorization class of the object and select the crate option. (Su21 also allows us to create our own authorization classes. Its a good practice to create at least one Z or Y authorization class to include our custom authorization objects).

SU21 - Create Auth Objects - Initial Screen
SU21 - Create Auth Objects - Initial Screen

We define the authorization field(s) for the new authorization object. Like the SAP delivered objects we are limited to a maximum of ten fields for custom objects as well. We should create some object documentation as well for future reference. On saving the new object we are again prompted for a package and we have the option of specifying a particular package or creating the new development as a local object. Typically at this point, the security administrator will contact the ABAP programmer to include a check for the new object in his code.

SU21 - Create Object
SU21 - Create Object

Organizational Levels

“Organizational Levels” (Org Levels) as opposed to authorization fields is another of the core concepts that we come across while creating roles in PFCG. We can access the organizational level values defined for a role by clicking the “org level” button in the main toolbar within PFCG.

In the role below, we see Org Levels like Company Code, Purchasing Org, Purchasing Group, Sales Org, Division, Plant, etc.

PFCG - Org Levels
PFCG - Org Levels

In the expanded view of the authorization data in PFCG, the org levels defined earlier appear side-by-side with the authorization fields. In fact, all org levels are also authorization fields but not all auth fields are org levels. For example, the org level Plant appears as an authorization field in two objects, M_LFPL_ORG and M_MATE_WRK. On the other hand the field Activity is not an org level. Once we maintain a particular value for an org level in a role, all authorization objects using the same org level as a field will automatically take the same value. Its technically feasible to break an org level, so that for a particular object, its value is different from its defined org level value but this defeats a the purpose of defining something as an org level.

Another difference between org levels and normal auth fields come to light while deriving a role from another master role. A normal auth field will be inherited by the child role with the same value as maintained in the parent but an org level can be maintained in the individual child roles.

PFCG - Org Levels vs Auth Fields
PFCG - Org Levels vs Auth Fields

Organizational Levels in most cases are intrinsically linked to the enterprise structure of an organization and largely determined during the customizing steps for the SAP systems. The below screen-shot from the SPRO transaction shows the options for configuring different org levels like company code, controlling area, purchase org, sales org etc. So its not really the security administrator who defines the org levels. He can only use the existing org levels defined during functional configuration.

SPRO - Enterprise Structure
SPRO - Enterprise Structure

Its possible to change an authorization field to an org level for the purpose of security by executing the program PFCG_ORGFIELD_CREATE. However, since this program impacts all roles which contain the org field it should only be run after a thorough analysis of all impacted roles. Also certain auth fields like Activity can never be changed to an org level.

Mass User Changes

As we have already seen in one of the earlier articles, individual user master records can be created/updated through the SU01 transaction. From time-to-time, a security administrator gets a request to create/modify a number of user master records. SAP provides us with a number of options to handle mass user changes. I will be covering a number of these options in the next few articles.

The easiest and quickest method for mass maintenance of user masters is provided by the SU10 transaction. The biggest limitation of SU10 is it that in one run, the same adjustments will be applied the entire set of user masters. Lets see how this transaction works when adding a role to a number of users.

SU10 - Initial Screen
SU10 - Initial Screen

Any operation with Su10 has two basic steps, User Selection and Modifying the selected user masters. The user selection area in the initial screen of SU10 allows the selection of users based on their existing address or authorization data. We can also manually add the user list in the initial screen. In the example below, we search for users of the form ” test0*”. The query returns a list of users satisfying the set criteria and transfer the user list for subsequent processing.

SU10 - User Selection
SU10 - User Selection
SU10 - User List
SU10 - User List

Once the user list is selected, we go into the change mode to add our mass changes.

SU10 - Mass Change
SU10 - Mass Change

SU10 allows mass modification of addresses, logon data, parameters, roles, profiles, etc. In the example below, we add the SAP role “SAP_ISR_PUR_PURCHASEORDER” and save the changes.

SU10 - Add Role
SU10 - Add Role

Once we save the changes, Su10 executes the specified actions and generates a log with the entries it has modified in the run.

SU10 - Change Log
SU10 - Change Log

Maintain T-codes with SE93

New t-codes can be created through the transaction SE93. In the example below, the t-code is created to call a program during execution. We can also create parameter transactions to which call standard sap transactions (like SE16 or SM30) or launch an ABAP query.

From the security perspective SE93 allows us to add a value for the authorization object field. This authorization object with the values specified for its fields, will be checked in addition to S_TCODE before the transaction is started.

Below we see the Se93 entry for the common HR t-code PP01. To start this transaction an user would need P_TCODE with TCD value PP01 in his user buffer, in addition to S_TCODE entry.

SE93 - Auth Obj for Transaction Start
SE93 - Auth Obj for Transaction Start

Data Browser

The Data Browser (transaction SE16) allows us to display (or maintain) transparent tables from the ABAP Data Dictionary. Its an invaluable tool for reporting as data from tables can be directly accessed without searching for reports which return this data.

In the example below, we use the table browser to display data from the “AGR_USERS” table which stores role to user assignment information.

SE16 - Initial Screen
SE16 - Initial Screen

The selection screen of the table, allows us to search on the basis of user id, role or/and validity dates. The selection options are basically controlled by the Settings menu.

SE16 - Selection Screen
SE16 - Selection Screen

The list output displays data filtered on the basis of entered selection criteria.

SE16 - List Display
SE16 - List Display

In many productive clients, SE16 is restricted from users as, if not restricted at the table level, it can give access to a lot of sensitive data. I personally believe in a compromise where certain technical users do have access to the t-code but restricted to display of the tables which is needed for their reporting needs.

SQVI – Quickviewer

Like the Data Browser (SE16) reviewed in the last article, Quickviewer (transaction SQVI) is very useful tool for quick and dirty reporting through Adhoc Queries. The advantage of using Quickviewer is it ability to perform table joins enables us to display data from multiple tables.

In the example below, we create a query to return the tcodes executable by an indivdual user. We name the query “Z_USER_TCODE” using table join.

SQVI - Initial Screen
SQVI - Initial Screen
SQVI - Query Definition
SQVI - Query Definition

On clicking the check button, we get to the design window shown below. We insert the three tables which we will be using for our report and add graphically add the join conditions as shown below.

SQVI - Join Conditions
SQVI - Join Conditions

Once the data sources and join conditions are set up, we need to check the fields appearing in the selection and list output. We have the option or changing the field order of both the selection and list screens or even the sort order of the resulting data.

SQVI - Selection & List Fields
SQVI - Selection & List Fields

We now save our query and click the execute button. In the example, we filter the query to return the tcodes for user “test_user”.

SQVI - Query Selection Screen
SQVI - Query Selection Screen

The output returns a list of tcodes that can be executed by the user and also the role which contains the tcode.

SQVI - List Output
SQVI - List Output