PFCG – Authorization Objects and Authorization Fields

The foundation of ABAP/PFCG authorizations (either at NetWeaver or S/4HANA) is built by ABAP authorization objects. Those objects are being queried, if an (data) access is tried by a user. But how does the system exactly query if a user is authorized? Correct – by checking if the user has got the required authorization object and the correct field entries (more to that later). Users do get those authorization objects via roles (either a single role or a composite role).

At a glance: authorization objects are the core of ABAP/PFCG authorizations and do validate access.

Authorization Object Anatomy

SU21 Examination

To check an authorization object, use the transaction code SU21 (“Maintain Authorization Objects“) and search for your object you want to examine.

Example S_TCODE – this object is required to use a certain transaction

Then you double-click the found transaction to open it:

Within the display of the authorization object we find three main components that are the foundation of understanding those objects:

1. Object: this entry displays the objects name (which you usually searched for before)
2. Class: the class can be seen as the parent hierarchy node of an authorization object. It summarizes the functional-related authorization objects for better maintenance as well as for better visual distinction. The value of the class will be obvious, latest once you started to work with PFCG roles.
3. Authorization fields: this is where the real authorization work takes place. Here, you see which fields are available for an authorization object, when you use it within a PFCG role. In this example the field TCD allows the authorization expert to enter valid transaction codes. Those codes then will provide access to the users that do have the role with this pecularity.

How it works

As stated before, authorization objects are assigned to a user via roles. Within the roles, authorization objects are being “coined” – meaning their fields do get their characteristics that are needed for a required access.

So to access a certain transaction of query data, a lot of subsequent subroutines are getting started. The system checks first for the required authorization object within the users role(s) and then, if the object is existing, the required field entries. If the users role(s) contain all required information, then the users access is granted.

To put it short, the process can be described like this:

1. User initiates system connection
2. User authentication (different story than authorization)
3. System checks for required authorization within user role(s)
   • Roles contain required authorization objects with according field entries -> access granted
   • Roles do not contain required authorization objects with according field entries -> access denied

To see how PFCG roles are being built and how all this relates, check the PFCG role building blog entry.

Please let me know if this entry helped. Did you find what you looked for? Was the described content clearly structured and well readable?

Please let me know if this entry helped. Did you find what you looked for? Was the described content clearly structured and well readable?

Thanks for your feedback!