In a large organization using structural authorizations, the PD profiles assigned to a user might return thousands of distinct objects. Evaluating the entire PD profile at run time to generate the object list, for each access to HR data, can lead to a significant degradation in performance of HR transactions. Since the performance penalty is mostly due to the evluation of the entire object list for an user during run time, the situation can be improved by storing the list of objects for a user.
SAP provides a table T77UU to store a index of all objects returned by the PD profiles for each user. However, since this is a static list of the objects we have to periodically regenerate the index for all user who are maintained in this table. If a user is not entered in this table, his PD profiles are evaluated at runtime to generate the object list. This will consume more time but will not adversely impact performance if the number of objects for the user is below a certain critical threshold.
The T77UU table is very rarely maintained manually. SAP provides two programs, RHBAUS02 – Check and compare T77UU (user data in SAP memory) and RHBAUS00 – Regeneration of INDX for Structural Authorization, to automate updation of the table and regeneration of the user indexes. The screen below shows, the selection criteria for the RHBAUS02 report. The report can be run for one or multiple users and for a certain threshold level of HR objects. The program evaluates the PD profiles for all the users entered in the selection screen and if the number of authorized objects returned is more than the threshold value updates the user in the T77UU table. Conversely if the number of objects for a user falls below the threshold, the user entry is removed from the T77UU table. Typically , a weekly batch run should be sufficient to take care of changing org structure and the profile assignment for users.
The RHBAUS00 program is generally run after the last run for RHBAUS02 has completed and hence finished updating entries in T77UU. The RHBAUS00 program re-generates the indexes, and hence the objects authorized for a user, for all users entered in selection whose entries also exist in T77UU. In a practical scenario the OM structure of an enterprise keeps changing from day to day. Since, the index only stores the objects that were effective during the last time when it was re-generated, RHBAUS00 should be scheduled to be run periodically. A daily batch run for the program is mostly sufficient to take care of the changing org structure however even in such cases, indexes of individual users might need to be specifically regenerated through the program or its linked tcode, S_PH0_48000110.
PD profiles can be assigned to users in two basic ways
Transaction OOSB can be used to assign one or more PD profiles directly to users. Adding entries to the T77UA table through SM30/SM31 has the same effect.
PD profiles can also be assigned to OM objects like positions through infotype 1017 (through transactions like PP01/PP03).
Also note that an user without an entry in the T77UA table would by default have the PD profile access which is assigned to the SAP* user in the table. SAP provides a standard program RHPROFL0, to read the PD profile values from IT 1017 for a position and create an entry in the T77UA table for the user assigned to the position. For SAP installations using indirect assignment of profiles, this program is generally scheduled to run in batch every night. A screen with the various options available for this program is shown below.
Assigning the PD profiles to the position instead of direct assignment in the T77UA table can potentially save a lot of effort in manual maintenance of profile entries and is the recommended practice.
PD profiles are created through the OOSP transaction. SAP provides a few standard profiles but to a large extent, PD profiles are created by individual customer depending on their requirements.
The definition of PD profiles is stored in the T77PR table. Lets have a look at the definition of the standard PD profile for “MANAGER”
Some features to note about the definition of the PD profile.
Each record in the table is independent of the other records and gives access to a certain number of objects.
Each record has values for PV (Plan Version), OT (Object Type ), Object ID, EvalPath (Evaluation Path), StatV (Status Vector), Depth, M (Maintenance Flag), Selection Period and Function Module.
PV denotes the plan version for which the profile is valid.
OT is the object type of the object id value.
Object ID gives the start object when an evaluation path is used in the profile or an individual object.
If evaluation path is maintained, the PD profile returns the object along the PD profile. maintaining an evaluation path will only work if a start object value is maintained explicitly or dynamically through Function Modules.
Status Vector is used to determine the status of the objects/relationships while creating the structure. A StatV of 12 for example will consider relationships of status Active (1) or Planned (2).
Depth determines the level of the hierarchial structure till which the evaluation path is constructed. No maintained value indicates that the entire org structure returned by the evaluation path will be constructed.
Maintenance(M) flag determines whether a person will be able to maintain the returned objects.
Period determines the validity period of the objects/relationships while creating the structure. A value of D creates the structure which is valid on that day. A blank value indicates that the structure is not limited by the validity dates for the corresponding relationships.
The function module field can be used to dynamically generate a start object. Efficient use of this option can greatly reduce the maintenance effort for PD profiles. Two standard function modules are supplied by SAP, RH_GET_MANAGER_ASSIGNMENT returns the org unit for which the user is a chief while RH_GET_ORG_ASSIGNMENT returns the org unit for a user. New function modules can be created by customers as per requirement.
Structural Authorizations as the name suggests are used to restrict access to a certain organizational structure. As such they are only used while accessing HR data. In general, structural authorizations serve two purposes
Restrict access to certain OM objects like Org Units, Jobs, Tasks, Qualification Catalogs etc.
In interaction with the access to authorization objects for PA master data, they can restrict access to certain set of persons in the enterprise.
While using structural authorizations, its important to note that
A person’s total authorization is a result of the interaction between his general authorizations (through roles) and his structural authorizations (through PD profiles).
Secondly, structural authorizations are always used to restrict access. You can never use structural authorizations to grant access. It can only be used to restrict access to a smaller set of objects or people than is already given though a general authorizations.
While using structural authorizations to restrict access, we need to ensure to add access to the corresponding objects are also added to the user’s roles through PLOG.
Since we have already extensively discussed, security roles and their assignment we will use the next few articles to describe PD profiles and their assignment.
An Evaluation Path is a chain of relationships between related OM objects in the Organizational Hierarchy. Different evaluation paths can be used to return different sets of OM objects even when all of the individual paths start from the same start object. As such, evaluation paths are used in a lot in OM reports and in structural authorizations.
Evaluation Paths are created/maintained through the transaction OOAW shown below. The standard SAP system ships with a number of pre-defined evaluation paths. Since the standard evaluation paths can only use the standard relationships and objects defined in SAP, it stands to reason that we need to create new evaluation paths to use our own relationships/OM objects.
As an example we select the evaluation path PERSON and see how its defined
The PERSON evaluation path is meant to return the OM objects used in staffing along a standard organizational hierarchy. As such it can be used to evaluate the reportees of a line supervisor and is used as such in the MANAGER structural profile. The definition of the evaluation path starts with an org unit. The path returns all positions (S) assigned to the start org unit (O) and the persons (P) linked to the said positions. Finally to build the entire org hierarchy the path continues to evaluate the sub-ordinate org units and positions (lines 30 and 40).
Once defined, the evaluation path can be used to return a particular view of the org hierarchy through the PPST transaction.
The report output shows the evaluated objects.
In the next article, we explore the use of evaluation paths in defining structural authorizations or PD profiles
This article about organizational management is meant to be a launchpad to our discussion on structural authorizations– an unique and indispensable part of HR security. We ave already have had a brief idea on Org Mgmt or OM when talking about the PLOG authorization object. Lets take the discussion forward to the next level.
OM deals with the representation of the personnel organizational structure within an enterprise within SAP HCM. OM uses the same data model as used by Personnel Planning. The data model uses object-oriented design and uses the concepts of
The data model can be represented by the following graphic. Note that object types, Person and Cost Center are shown as orange boxes instead of blue ones. These are External Objects and not created in the OM component. However, they have relationships with normal OM objects.
A typical org structure when represented by the same data model might look something like the graphic (transaction PPOC) shown below
In OM, each element in an organization is represented by a distinct object with individual characteristics. Relationships are used to link one object to another. The objects and their relationships can be created and maintained through standard transactions (like PP01). The network created by objects and relationships are flexible enough to facilitate personnel planning, projections and evaluations of the org structure. Customizing is used to enhance the existing object types or create completely new ones. Customizing also allows the creation of new relationships and maintenance of those relationships for existing or new object types.
Each standard object type is represented by a letter code (P = Person, O = Org Unit, S = Position, C = Job) while customized object types are represented by two letters like 9P. Relationships on the other hand are represented by a 3 digit code like 008 (belongs to), 012 (manages). Customer relationships are also 3 letters long but start with Z, like Z20.
The unique object id for an object type is stored in IT 1000 (table HRP1000)
while the relationship between two objects is stored in the IT 1001 (table HRP1001).
Finally, the org structure composed through these two tables is displayed through the PPOSE transaction as shown below
The authorization checks for PA master data (through P_ORGIN, P_ORGXX, P_PERNR, etc) while running HR reports are very involved and pose a significant performance penalty to the system. For each pernr selected in the report, the authorization system carries out a check for each of the infotypes being accessed.
The P_ABAP (HR Reporting) is used in such cases to simplify the authorization check for PA master data when running HR Reports based on the logical databases SAPDBPNP or SAPDBPAP. The fields available in the object are given below
Degree of Simplification of the Authorization Check
ABAP Report Name
The COARS field can two values corresponding to two different degrees of simplification.
COARS = 1. The authorization checks for the infotype/subtype combination and for organizational assignment are to be checked separately.
COARS = 2. The report is run without any authorization checks for PA master data.
In practice, P_ABAP can be used in two main cases. A value of COARS = 1 can simplify the authorization checks significantly reducing the time needed to execute a report. This is the case for a number of reports in the pay-time component of HCM. For example, an export of PA master data during a typical payroll run would have to read a large number of PA infotypes for all the employees in the enterprise. Using P_ABAP in this case would ensure that the report completes in a reasonable amount of time. Also since these reports are generally run by payroll staff who already have access to almost all user data, a detailed authorization check for all users’ infotypes is often unneccessary.
A second case for using P_ABAP appears when we want non HR users to be able to run some non sensitive reports on HR data without giving them direct access to P_ORGIN, P_ORGXX and similar objects. A value of COARS = 2 would enable these users to run the said report without any authorization check for PA master data.
Its important to note that a P_ABAP authorization is always restricted to particular reports as a value of * or SAPDBPNP would allow any reports on master data to be run without checking proper authority checks.
Personnel Development (PD) Data is part of the Personnel Planning (PP) Data model used in SAP HCM. The PP Data model is made up distinct HR object types like positions (S), Persons (P), Jobs (C), Tasks (K), etc. The main use of this data is in Personnel Development (PD), Organizational Management (OM) and the Training and Event Management sub-modules of SAP HCM. In contrast to the PA master data which essentially store data for persons, PD data mainly store the attributes of the different PP object types. Also, the allowed PP infotypes depends on the object type and is controlled through configuration settings. PD data is specially relevant for security as it used to define the Organizational Structure of an enterprise and Organizational Structure in turn is used for the position based security assignment and structural authorizations.
PD data is secured by the authorization object, PLOG (Personnel Planing). The fields of this objects are given below.
We can better appreciate the use of this object by looking at one of the basic transactions for maintenance of PD data – PP01.
In the initial screen of PP01, we can easily spot the fields for Plan Version, Object types, Infotypes and Planing Status (the tabs for Active, Planned, Submitted, Approved, Rejected). The buttons highlighted in the toolbar are for different activities on the infotype selected. The permissible activities for the object and infotype combination are contained in the PFCODE field of the authorization object. Among the huge multitude of possible values of PFCODE like INSE (create), disp (display), DEL (delete), CUTI (delimit), LISD (List Display), AEND (Change), LIST (List Display with Change), etc we discuss only the last two.
In the first example we select infotype Object (IT 1000) and click the change button. The infotype change screen allows us to change the name and abbreviation of the object (AEND)
In the second example, we select Relationship (IT 1001) and click the second button from right to get into the Overview Screen which shows all the “relationships” created for the Object. The access being tested is LIST. Also note, that accessing overview screen from a pure display transaction like PP01_disp would have checked for LISD (List display). IT 1001 is also one of the PD infotypes which can be secured at the subtype level. Each relationship record shown on the screen (like A002 – reports, B007 describes) is a separate subtype and is meant to link two different object types. The different relationships between these PP objects is actually used to build the entire Organizational Hierarchy of the enterprise.
In addition to the PLOG object, PP objects can be further secured through Structural Authorizations. I hope to cover a discussion of Structural Authorizations in a future article.
The SAP Query component in R/3 provides a way of generating simple reports without any actual coding. From this standpoint, it is similar to the Quickviewer (transaction – SQVI) but more powerful and correspondingly a little more difficult to master. A full description of this great tool is beyond the scope of this article. Instead, my intention is to concentrate almost entirely on the security features for SAP Query and demonstrate how we can use the basic concepts of security to segregate a process chain into clear roles and responsibilities. This is the basic job of an security analyst during the all important phase of security design.
Queries are reports which can be configured by mostly drag and drop operations though a graphical editor to retrieve data from the data dictionary tables. The SAP Query component consists of three main transaction – SQ01, SQ02 and SQ03. SQ01 is the transaction for Query maintenance. It allows us to create, update, delete, display or execute queries.
Queries are not directly defined on tables but use an intermediate object called an Infoset. An infoset can be defined to be a table join or as a logical database and contains the sum total of data which the query defined on it can potentially access. SQ02 is the transaction for infoset maintenance (and display).
The final link in the chain is SQ03 – the transaction for maintenance of query user groups. Unlike many other SAP components ( and like many other ones), security for SAP Queries is not entirely controlled through roles and authorizations. To access a query, an user and and the infoset for the query must be assigned to the same query user group. Please note that the user group for queries is in no way related to the user groups maintained as part of the user master record.
So now, that we have had a brief introduction to the SAP Query transactions, lets turn to the problem of securing this application. Security for the SAP Query application is controlled through the authorization object S_QUERY. The object as the single field Activity (ACTVT) with only three possible values, 2 (change), 23 (maintain) and 67 (translate). Of these activity 2 is needed to change queries, infosets, user groups while 23 is needed for maintaining user group assignment. Also access to SQ02 or SQ03 is not possible without access to 23. Finally, a person with 23 can actually access queries belonging to other user groups without having use SQ03. Its important to note that unlike most other authorization objects, S_QUERY doesn’t have activity 03 ( display) as S_QUERY is not checked during display or execution of queries. Other than S_QUERY a user would also require some form of basic access like S_TABU_DIS for checking access to the actual data retrieved from the tables, access to change layouts (S_ALV_LAYO), exporting retrieved data to excel (S_GUI), etc. In a typical enterprise we might want to segregate access to SAP query to three distinct business roles
Query Executor – These are the reporting users who will be responsible for actually running the queries and interpreting the results. These are normally business users and are not expected to update/change queries.
Query Creator – These are the power users who have the business knowledge to actually design/create queries and subsequently change them depending on user requirements. They might also need to maintain Infosets.They should also be able to execute the queries to check that the designed queries output correct data. However, since the query executor is still a business user, as security administrator we would not want to give them the responsibility of assigning user groups and control who gets what!
Query Administrators – These are the support personnel who are responsible for maintaining the user group mapping. These users would not be maintaining query design even executing queries.
With the above requirements in mind, let us design three roles for the three separate classes of people.
Query Executor – Need access to SQ01 but not S_QUERY. Also should have access to data they are trying to retrieve (S_TABU_DIS).
Query Creator – Access to SQ01 and SQ02 as well as S_QUERY (both activities 02 and 23). Should also have access to table data through S_TABU_DIS. Should not have access to SQ03.
Query Administrator – Access to SQ03 as well as S_QUERY(both activities 02 and 23). No need for access to table data.
Thus we have successfully mapped business roles to SAP roles. This is the final goal for all security analysts. The only problem is instead of a single authorization object and three tcodes we are working on thousands!
We have already come across PA (Personnel Admin) master data in our initial discussion of different types of the HR data. Out of the box, SAP provides three main authorization objects for securing PA master data, P_ORGIN, P_ORGXX and P_PERNR. Lets see how we can use each one of these in our security design landscape.
PA master data stored in different infotypes is essentially the attributes for the employees of the organisation. To store these attributes each employee is associated with an unique personnel number or PERNR. SAP HCM currently allows a person to have multiple pernrs as part of its extended configuration but that is beyond the scope of our discussion on basic HR security. The basic transaction for maintenance of PA master data is PA30. The first screenprint shows the initial screen of PA30 with the pernr and name of an employee.
In HR, the pernr similar in use to the system id used in the security system. In fact we use the infotype 0105 (communication), subtype 0001 to store the SAP system id corresponding to the pernr for an user. Later we will find that this link is mandatory for the use of the P_PERNR authorization object.
The first step in using any of the PA master data authorization objects is switching on the corrsonding authorization switches for them in the transaction OOAC. For ex, to switch on security checks for P_ORGIN and P_PERNR we need to set the authorization switches AUTSW-ORGIN and AUTSW-PERNR values to 1 respectively. Once switched on, any access to PA master data will check the user master for these authorization objects.
The most important infotype with regard to any discussion on PA master data security is the Organisation Assignment (0001) infotype. The screenprint below shows the IT 0001 screen with the different data contained in it. This infotype is important as the data fields of this infotype are also part of the general authorization objects and are checked during data access. For ex, Personnel Area, EE group, EE subgroup, Cost Center, Payroll Area and the three Administrator fields are all used in the authorization objects.
The three common authorization objects with their authorization fields are given below
P_ORGIN (HR: Master Data)
P_ORGXX (HR: Master Data – Extended Check)
Master Data Administrator
Time Recording Administrator
P_PERNR (HR: Master Data – Personnel Number Check)
Interpretation of Assigned Authorization
As you might have noticed, many of these fields were part of the org assignment infotype. Thus if a security concept is built around personnel area, employee group, employee subgroup we can switch on the check for P_ORGIN and use the auth object in our roles or if the security concept is based around the time, master data and payroll administrators we can use the P_ORGXX authorization object. In some rare scenarios we might even want to use both the authorization objects in our roles. A case where both of them might be used is a scenario where we have different master data administrators for a single personnel area. Here instead of creating of roles with all the different combinations for P_ORGIN (Personnel Area) and P_ORGXX (Administrators), we can reduce the number the of roles by separting out these two accesses into different roles. Finally a combination of the P_ORGIN and P_ORGXX roles will be assigned to a user to make up the total accesss of a HR rep. You would also notice that the standard authorization objects do not have any option to secure PA data at the level of the personnel sub area or cost center. A solution in such cases is provided by the Organization Key field. This is a 14 character field which can be configured to be derived from any of the IT 0001 fields or can be even manually entered by the administrator.
The P_PERNR authorization object is a bit different in functionality from the other two objects. The P_PERNR object provides one of the very few examples of negative authorization concept in SAP. The object is used to provide different authorization to an administrator when accessing his own PERNR. The most common example is of a compensation analyst having access to update the basic pay infotype. Though as part of his usual responsibility, hw would be expected to maintain the basic pay of other employees, we would not want him to give himself a raise. Its at this juncture that P_PERNR and its negative authorization comes to the rescue. The master data authorization of this person might typically be maintained as the following
AUTHC W, R, M
AUTHC W, D, S, E
In the above case, the P_ORGIN authorization gives the comp analyst access to maintain (AUTHC – W – Write) the basic pay (IT 0008) for others but when accessing his own pernr, the value of P_ORGIN is over-ridden by the access in P_PERNR. The value of PSIGN as E (Exclusive) denotes that while accessing IT 0008 for his own pernr, his access will exclude the values maintained for AUTHC (W, D, S, E). The only possible values for AUTHC which excludes the 4 given values are R (Read) and M (matchcode) and as a result the administrator only has display access to his own pay data.
Its very important to remember a few points when trying to use P_PERNR. Firstly P_PERNR can only be used to provide access to a person’s own pernr or personnel record. A corollary of this, is the requirement that for P_PERNR to work a valid system id should be maintained for IT 0105, subtype 0001. This is necessary as the SAP system needs to identify a personnel record with a user master record. Secondly, the only two possible values of the PSIGN field are E (Exclusive) and I (Inclusive). A value of * doesn’t make much in this case as by definition, a * value can be interpreted as either of the two possible values.