The User Information System (transaction SUIM) is a set of reports on user-authorization data which allows security administrators to query on authorization data . SUIM is all the more important since standard table maintenance transactions like SE16 are restricted from many users in productive systems.
The initial SUIM screen shows us all the defined reports from which we can select and execute the ones needed for our analysis. We can query for users, roles, profiles, authorizations, authorization objects as well as on the change documents for any of these objects.
We take an example report, “Roles by Complex Selection Criteria” and search for roles with access to the transa ction SU01 and the authorization object S_USER_GRP.
The query results show all roles which match the selection criteria.
The Security Trace Tool (transaction ST01) provides a way to trace the complete sequence of security checks for transaction. Since all checks are displayed, this is a much more foolproof way to investigating potential issues.
The trace needs to be set in the same application server as the user before transaction start. We can check this through SM51 . From the initial screen of ST01, we enter appropriate filter conditions for our trace, mostly this is the user for whom we are checking access, and click the “trace on” button.
The user now executes the sequence of actions to replicate the error. At this point, we click the analysis button, select appropriate filter criteria for the trace file and finally display the trace file itself.
Troubleshooting security issues is one of the daily tasks of any security administrator. The first method of investigating authorization failures is the ubiquitous SU53 transaction. It involves us asking the affected user to run the step(s) to replicate the issue and immediately on getting the error, execute /nsu53 through the command window. The screen-shots below show the sequence of actions.
The user tries to create another user through SU01 and gets an authorization error
The user gets a pop with the message that he doesn’t have authorization to create user.
Many times clicking the help button can provide important information about the background of the error.
To get the SU53 screen, we execute /nsu53 from the command window immediately after getting the error. The SU53 window shows the last check for an authorization which has returned a non zero value (authorization failure) for the user.
The biggest limitation of SU53 is the fact that it only shows the last authorization failure of an user. In a typical transaction, there can be an entire sequence of authorization checks, any of which might fail. To view the entire sequence of authorization checks, we use the authorization trace tool (transaction ST01).
In our article on SU24, we saw the feasibility of selectively switching off checks for certain authorization objects. However, HR objects (objects for authorization class HR) can not be marked as “Do not check”. Howver, there is another option for selectively switching off checks for HR objects. This is done be setting the values of authorization switches (through transaction OOAC) or directly modifying the HR config table (T77S0). The available authorization switches are shown below.
You can look at the standard SAP documentation for the functionality of each of the switches but let me list a few of them
AUTSW – ORGIN – Switch on (1) or off (0) for authorization object P_ORGIN. This object is used to check for access to Personnel Admininstration (PA) master data through infotypes.
AUTSW – PERNR – Switch on or off check for P_PERNR object for an employee’s own personnel number
AUTSW – ORGPD – Switch off (0) or on (1,2,3,4) the structural authorization checks.
This post talks about the program level mechanism to implement a check for a particular authorization object. SAP Business applications are coded in the SAP proprietary language, ABAP. All transactions call ABAP programs at the back-end and it is this code which is responsible for checking security.
The security check for an authorization object is through the standard ABAP construct “AUTHORITY-CHECK”. The actual form of this statement is given below for checking display access (ACTVT 03) to a table belonging to particular table authorization group (DIBERCLS ‘SC’).
AUTHORITY-CHECK OBJECT ‘S_TABU_DIS’
ID ‘ACTVT’ FIELD ’03’
ID ‘DIBERCLS’ FIELD ‘SC’.
Copying a portion of the SAP code which is used to check for table access
This statement checks the user buffer of the person executing the program/ tcode to see if he has an authorization for S_TABU_DIS with actvt 03 and dibercls ‘sc’. Depending on the contents of the user buffer, the statement might return different values (the values of the sytem field SY-SUBRC)
0 signifies a succesfull check, i.e. user has the correct authorization
4 denotes user has the authorization object in the buffer but not with the correct values
12 denotes that the user has no authorizations for the specified object
The SU24 transaction is one of the most important transactions in security. Its used to maintain all the objects that are checked for the execution of a particular transaction. The check indicators as maintained in SU24 are stored in two customer specific tables USOBT_C and USOBX_C. The customer specific tables ensure that the values modified by a customer are not over-written by the SAP proposed values during a future upgrade. We can have a look at the SAP proposed values through the transaction SU22.
Each object can have three different status as given in the screenshot below
Do not check – These objectsare not checked during transaction execution. Authorization objects belong to Basis and HR components can not be marked as Do not checked.
Check , Yes (Check/Maintain in previous releases) – These objects are checked during transaction execution and also pulled into a role when the transaction is added to a role. We also have an option of maintaining default values of the authorization fields for these objects. For example, in the last post regarding role maintenance, we saw a number of authorizations which were pulled into the role with default values. These authorizations appear with status standard or maintained in role maintenance.
Check, No (Check in previous releases) – These objects are checked during transaction execution but are not pulled into the role even if the transaction is added to the menu.
Its important to note that the primary check for an authorization object during program execution happens at the code level. So adding a check in Su24 will have no impact to security unless the code is modified as well to include a check for the authorization object. We talk about the mechanism of the authorization check at program level in our next article.
In the last two section, we have looked at both SU22 (SAP delivered check indicators) and SU24 (customer maintenance of check indicators). We have also talked about how SU22 presents data from USOBT and USOBX tables, SU24 present data from the customer tables USOBT_C and USOBX_C tables. The natural question that arises, “if SAP only writes to former set of tables and we only modify the customer tables, how are the customer tables initially filled with data?”Actually, SAP provides a standard transaction SU25 for initially copying over SAP proposed values to the customer tables. We discuss this transaction in our next section.
SAP HR deals with private employee data much of which might be of sensitive nature. As a result the HR security is typically more stringent that security for the other SAP modules. In a lot of non HR applications, security is more geared towards prevention of wrongful entry of data into the system. However, in the case of HR, even the display of private data might lead to non compliance with prevailing laws and regulations.
Other than the overtly sensitive nature of HR data,another reason of separating it out into its own category on this site is to emphasize two unique provisions in HR.
Firstly, most of SAP security is based on positive authorization, i.e presence of a particular authorization in the user buffer gives access to new functionality. HR is one area where negative authorization can also be used in addition to the existing positive authorizations. Negative authorization in this case prevents an user from accessing some application due to the presence of a certain authorization in his user buffer.
Secondly, HR uses structural authorizations to restrict HR access to a certain hierarchy within an authorization independent to the general authorizations assigned through roles.
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.