Access to SAP system are assigned to users through roles maintained in their user master. In this article, we explore how access to the SAP system is extended to users through roles. We also talk about the related concepts of authorization objects and authorizations.
The transaction to create/maintain roles is PFCG. Lets create a role in PFCG and try to understand the various options available to us therein. We name the new role “ZTEST_HR_ACCESS” and click the “Single Role” button. (Note that you can follow any naming convention for your roles as long as they do not begin with SAP or /).
Inside, PFCG, there are again a number of tabs which need to be filled with data as part of the role creation process. We start with maintaining role name and description. There is also the option of specifying a parent role as shown in the diagram below. A child role inherits all tcodes and authorizations from its parent except the organizational levels (we will discuss org levels in a later article). The Long text field might be used as an audit log to track the background behind creating the new role.
In the menu tab, we maintain the tcodes that the role will have access to. In addition to tcodes, we can also add reports, queries and URL. There are lots of options to build the menu of a role. You can copy from an existing area menu defined in SAP, copy from another role or import from a text file.
Once we have maintained the menu for the role, we go into the Authorization tab. We have an option of generating a profile name or following our own naming convention. I would suggest following a naming conventions of our own (even though I have used the generated profile name in the example) as the profile name can help in subsequent reporting on authorizations. We save the new profile and click either of the two highlighted buttons, Change Authorization Data & Expert mode for profile generation to get into authorization data maintenance.
The next screen is for maintenance of authorization data. The different color codes define distinct security specific objects/concepts. Lets discuss these below
- Blue Line – Role – In our case its the new role which we have just created “ZTEST_HR_ACCESS”.
- Pink Line – Authorization Class – These group Authorization Objects which protect similar application components.
- Green Line – Authorization Object – Though called an object, an authorization object is more akin to an OOP class. Its a template or structure with a number of fields each of which needs to filled up with appropriate data to allow access.
- Yellow Line -Authorization – This is an unique instance of an authorization object with values specified for its different fields. Carrying the OOP analogy forward, an authorization is actually similar to an object.
- Off-white Line – Authorization Field – These are the unique fields within each authorization object. Different authorization objects will have different sets of authorization fields.
To understand how security works at the application level, we take the example of the S_TCODE object. To start a transaction, a user needs this authorization object in his user buffer with the the transaction maintained as a field value. In the example below, a user with the new role would be able to start transactions PA30, PA40 and SU53. However, starting a transaction is only the first level of check, any number of different authorization objects can be checked at each step of the transaction. These checks are for presence of individual authorizations in the user buffer.
During role maintenance, we maintain all the open field values (marked by yellow triangles) so all authorizations become green. Once finished we generate the role, by clicking the button with the a circle and red and white quadrants. This final step is the most important step in the entire process as this creates one or more authorization profiles for the role. It is actually the authorization profiles present the user buffer that give access to SAP applications. The role is just helps in easier maintenance of authorization profile. Even now, its technically feasible to directly modify authorization profiles but is strongly discouraged from SAP. Once generated, the role can be assigned through PFCG itself or through SU01.
In the next article, we discuss the link between transactions and authorization objects. This will in turn help us to understand how the authorization objects are pulled into the role during maintenance.