Securing PA Data
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)
| Authorization Field | Long Text |
| INFTY | Infotype |
| SUBTY | Subtype |
| AUTHC | Authorization Level |
| PERSA | Personnel Area |
| PERSG | Employee Group |
| PERSK | Employee Subgroup |
| VDSK1 | Organizational Key |
P_ORGXX (HR: Master Data – Extended Check)
| Authorization Field | Long Text |
| INFTY | Infotype |
| SUBTY | Subtype |
| AUTHC | Authorization Level |
| SACHA | Payroll Administrator |
| SACHP | Master Data Administrator |
| SACHZ | Time Recording Administrator |
| SBMOD | Administrator Group |
P_PERNR (HR: Master Data – Personnel Number Check)
| Authorization Field | Long Text |
| AUTHC | Authorization Level |
| PSIGN | Interpretation of Assigned Authorization |
| INFTY | Infotype |
| SUBTY | Subtype |
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
P_ORGIN
INFTY 0008
PERSA *
AUTHC W, R, M
P_PERNR
INFTY 0008
PSIGN E
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.
Do you have any case studies of Structural Authorization being applied in ESS/MSS.
I have read some many books on HR Sturctural Authorization yey never understood as much as reading your notes.
Good job I give this explaination 5 ***** – Thank you…..
Sorry but I do not have a full case study of the use of Structural Auths for ESS/MSS. However, I can briefly share my own experience working on this ….
ESS shouldn’t need the use of structural auths as you are basicaly accessing your own personnel record. The only exception to this is a situation where every user using ESS is restricted to certain HR objects. I have not used struct auths with ESS.
MSS will on the other hand need structural auths in all but the simplest implementations. In MSS, a line supervisor is basically restricted to view his reports. Here in addition to the infotype access, the user can be assigned a PD profile which traverses the standard org hierarchy. SAP provides a standard Func Module RH_GET_MANAGER_ASSIGNMENT to evaluate the org hierarchy dynamically at run time. This allows a single PD profile be used for all managers. We used a similar design in our system.
Hey Aninda
What are the implications of having P_PERNR with authorization level set to *, infotype set to *, interpretation set to * and subtype set to *. Since Interpretation is set to * would the system consider it E or would it consider it as I? Thanks in advance
From a design standpoint, P_PERNR should never be used with interpretation set to * as * might be interpreted either as E or I depending on the SAP version. Also logically * in this field does not make any sense to me. I would also be skeptical about using * in the infotype field.
The way of explanation is awesome.
Usually everyone explains what activities in application level controls which data in DB level. This will only help to understand the basics.
On the other side to get control on the complete concept, one needs to understand the importance of security from data level to Application level.
Finally the explanation on each topic is excellent except some typo mistakes.
Thanks Venkat. You mentioned a very important point for understanding SAP security. Thankfully SAP is pretty consistent about securing data (not only HR data). Once you understand the objects being used to protect a particular class of data, security for individual transactions need not be investigated at depth. Data dictates security and not transactions.
Hi Aninda, I am implementing ESS/MSS for a client without structural authorisation. The problem I have come across with setting up the authoristion for ESS/MSS is that the webdynpro service for display of payslip checks the access to P_ORGIN, which will interfere with our backend payroll access. I have read that the check should be switched off in the portal. Would you agree on this, and how can this be achieved? The auth objects checked for webdynpro services do not appear in SU24. Thank you for sharing your knowledge so effectively.
Hi Yvonne,
I might be mistaken but I have not come across an situation where you could switch off checks for P_ORGIN for a webdynpro application. If the webdynpro is calling a report in the backend, you can investigate the use of the P_ABAP object.
However, if you are just trying to use ESS to view a person’s own payslip, P_PERNR should be enough. This object only opens up access to a person’s own personnel record so should not pose a problem to your existing payroll security.
Let me know how you end up solving the issue. This would new visitor to the site.
Regards,
Aninda
Aninda,
HR Security area is very well coverd here and personally it is quite helpfull for me to study HR Authorizations.
Hi
Question I have is simple, for structural AUTHS to work must we need to update table T77PR( user assignment to structural profiles). ?
Have been told we can assign structural AUTHS profile directly to a PFCG role using P_orgXX
The table t7PPR will slow everything down
The T77PR table holds the definition of the structural authorization while T77UA stores user assignment for PD profiles. There are ways to get away from maintaining this table but you would need to use an user exit to read the PD profile data from the roles. Just updating an auth object will not work. Thanks.
How do you go about this situation. You want payroll administrators to be able to maintain their bank details, personal info etc on ESS but not on the back end using PA30. How do you restrict this from happening.
Thanks and Regards
Auds
Can’t be done with standard security. You would need your development team to code in an enhancement for either the ESS application or for PA30