HR Security

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 to 10 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	Long Text
INFTY	Infotype
SUBTY	Subtype
AUTHC	Authorization Level
PERSA	Personnel Area
PERSG	Employee Group
PERSK	Employee Subgroup
VDSK1	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 = E can 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, S and PSIGN = E.

Example of of Period Determination Using P_ORGIN

P_ORGXX  HR: Master Data - Extended Check
The authorization object HR: Master Data - Extended Check is used during the authorization check on HR infotypes. The checks take place when HR infotypes are edited or read.

• The SACHA, SACHP, SACHZ, and SBMOD fields are filled from the Organizational Assignment infotype (0001). Since this infotype has time-dependent specifications, an authorization may only exist for certain time intervals depending on the user's authorization. A user's period of responsibility is represented by all the time intervals for which he or she has P_ORGXX authorizations.
• In the administrator group, all administrators who are responsible for an organizational area in Personnel Administration or in Applicant Management are grouped together.
• In the standard system, the check of this object is not active. You can use the authorization main switch (transaction OOAC) to determine whether this check is to be carried out in addition to or instead of the HR: Master Data check.
• If the additive check is activated, an authorization check according to HR: Master Data takes place first. If this check is positive, the object is then checked according to HR: Master Data- Extended Check.  

P_PERNR   HR: Master Data - Personnel Number Check
You use the HR: Master Data - Personnel Number Check authorization object if you want to assign users different authorizations for accessing their own personnel number. If this check is active and the user is assigned a personnel number in the system, it can directly override all other checks with the exception of the test procedures.

• The following values are possible for the PSIGN field:
• I   =          Authorization for personnel number assigned, that is for own personnel number
• E  =          Authorization for all personnel numbers excluding own personnel number
• You can assign a user a personnel number using infotype 0105, subtype 0001 (in earlier releases using the V_T513A view).
• This check does not take place if the user has not been assigned a personnel number, or if the user accesses a personnel number other than his or her own. In other words, this check is completely irrelevant for personnel numbers that are not assigned to the user.

Example of P_PERNR

Authorization  for Payroll

• P_PCR - This authorization object is used by the authorization check for the payroll control record. This check takes place when the control record is displayed using transaction PA03, or when the control record is maintained. The check also takes place in particular during maintenance using the payroll menu.
• P_PYEVRUN - You can use this authorization object to control the actions possible for posting runs.
• The following specifications are possible for the Run type field:
  • AP    Posting tax/SI Austria
  • PP    Payroll posting
  • TP    Posting Third-Party Remittance
  • TR    Posting travel expenses
  • ZA    Payroll evaluation - South Africa
• P_PYEVDOC - You use this authorization object to protect actions on posting documents.
• P_TCODE - Access authorization to payroll schemas (transaction PE01) and personnel calculation rules (transaction PE02) is granted by authorization for the HR: Transaction Code authorization object.
• If only the employee entered as person responsible in the attributes of the schema or rule should be authorized to change a schema or a personnel calculation rule, you must activate the Changes only by person responsible field there. If the indicator is flagged, other employees are granted only read authorization for the schema or rule.
• This attribute can only be removed by the employee responsible or by running the RPUCTF00 report, Change attributes for schemas and personnel calculation rules.
  • Note: The authorization objects HR: Authorization for Personnel Calculation Schemas and HR: Authorization for Personnel Calculation Rules contained in the HR object class are not used in the standard system.

Create custom authorization – Customer specific object

• If you have requirements that cannot be met using the P_ORGIN and P_ORGXX authorization objects (for example, because you want to build your authorization checks on additional fields of the Organizational Assignment infotype (0001) that are customer-specific), you can include an authorization object in the authorization checks yourself.
• Create the authorization object using transaction SU21. Make sure you keep to the customer name range (Z/Y). To be able to use the new authorization object you have created in the master data authorization check, the object must contain the INFTY, SUBTY, and AUTHC fields. You can use any of the fields of the Organizational Assignment infotype (0001) for the other fields. You can also use customer-specific additional fields provided they are CHAR or NUMC type fields.
• After you have created the object, you must start the RPUACG00 report. This report overwrites the MPPAUTZZ standard include with the code that is needed to evaluate the authorization object you created. Note: Technically speaking, this involves a modification. However, SAP fully supports this procedure. And you should not have more maintenance work as a result of this modification.

Note: that if you use customer-specific authorization objects, you must maintain these objects in transaction SU24 (Maintain Assignment of Authorization Objects to Transactions) in the same way as you maintain the authorization objects P_ORGIN, P_ORGXX, and P_PERNR

Double Verificatin in HR Security

HR security TIP and Tricks

Structural Authorization