HR Security Authorizations

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.