Create your own authorization objects

SAP provides suitable authorization objects for almost every requirement. But sometimes the standard is not enough. In this case, you can create your own authorization objects and then integrate them into your roles. We will now show you how to do this.

Today we are working with an example from the HR area within the context-sensitive authorizations: We want to be able to restrict authorizations depending on the transaction. This means, for example, that clerks should only be authorized for a specific infotype when using PA30 (Maintain HR master data). In PA20 (Display HR master data), however, they can see all infotypes.

However, the P_ORGINCON authorization object cannot map this. Instead of transactions, it can only be restricted to such fields as personnel area, employee subgroup or group and so on. We therefore need another authorization object.

SU21: Create authorization object classes

To do this, start transaction SU21. You will see an overview of all available authorization classes. Each authorization object is assigned to an authorization class. We could therefore select the class for the HR objects for our new object.

Alternatively, you can create your own authorization class. To do this, go to the white sheet in the toolbar and click on the small triangle that opens the submenu. Now select “Create authorization object class”. In the next window, you must assign a name and a short text and save the whole thing.

SU21: Create authorization object

If you now scroll through the list, you will find your newly created authorization object class. Right-click to select the “Create authorization object” command. Enter the name and short text in the next window.

If you confirm your entries with Enter, free fields will open. Enter the authorization fields that your object should contain here.

In our example, we adopt the fields of the standard object P_ORGINCON:

  • AUTHC (authorization level)
  • PERSA (personnel area)
  • PERSK (employee group)
  • PERSG (employee group)
  • VDSK1 (organization key)
  • INFTY (infotype)
  • SUBTY (Subtype)
  • PROFL (Profil)

We also add the TCD (transaction code) field, which can later be used to restrict the authorization depending on the transaction.

Save your entries and fill in the object catalog details. If you do not specify a package here, the object is saved as a local object, but this makes no sense for productive use, as the authorization object must also be transported to the QAS and PRD system later.

After saving, the button with which you can open and complete the object documentation appears in the window with the object details.

Once you have done this, go back to the previous window and confirm your selection with the green tick. Your object is now created in your own authorization object class. You will find it in the list when you open the tree structure of the class.

PFCG: Integrate authorization objects into roles

To use your object, open a suitable role in the PFCG. In the Authorizations tab, select the “Manual” button in the menu bar and enter the name of your object in the new window – in our case “Z_ORGINCON”.

The object is added and you can define it. With this example, the user has full authorization.

If we now want to restrict this, we can copy the authorization and, for example, make one specification for transaction PA20 and another for transaction PA30. Here we can then specify that the user may only view and edit certain infotypes in PA30. This can be continued as required.

Please note: You can only delete objects that you have created yourself if they are not used in any role. If we want to delete our example object, we must first deactivate it in the role mentioned above. We can then right-click on the object in SU21 and select “Delete”. It is also only possible to change the fields of authorization objects if they are not being used.

Leave a Reply

Your email address will not be published. Required fields are marked *