Authorization Groups allow us to secure access to various entities in the SAP landscape. The most common application of authorization groups is to secure tables but they can also be used to secure other objects like customers, vendors, accounts or materials. In fact authorization groups are represented by the authorization field BRGRU and they form part of quite a few authorization objects. However lets start our discussion with the example of table authorization groups. Table authorization groups are created through the SE54 transaction shown below.
To secure access to tables/views through authorization groups, we need to assign it an authorization group. We have the choice of using any of the existing authorization groups or create a new one for our table. Both these activities can be completed through the SE54 transaction as shown below.
Note that the figure above shows the existing auth-groups created in the system. The entry “S_TABU_DIS” appears at top of the screen as this is the auth groups assigned to the table needs to be maintained for the S_TABU_DIS object with the correct activity (02 – change, 03 – display, etc) in the users’ role to complete the process of securing table access. Another point to remember is the fact that a table without any auth group maintained for it, is considered to be linked to the &NC& auth-group. So for these tables, &NC& need to be maintained in S_TABU_DIS.
Now that we are done with the use of auth groups for securing table access, lets check out their use in securing other SAP applications. To better understand the subsequent use of auth groups lets start with a display of the BRGRU field (which represents them in authorization objects) in SU20. You will note that the BRGRU field has a length of 4 and has a check table TBRG. The TBRG table is the central repository of auth groups defined in the system. When creating new groups through the SE54 transaction, we are actually accessing this table filtered for S_TABU_DIS.
To create auth groups for use in other objects, we need to directly access the TBRG table. We can use SM30, SM31 or SE16 for creating new entries. The figure below shows this table being maintained through SM30. We create entries for the F_LFA1_BEK object which is used to secure access to vendor master records.
Now to secure vendors through the created auth groups, we need to update the vendor master (transaction FK02) as shown below with the same and maintain the same values in the F_LFA1_BEK object in the users’ roles.
Similarly auth groups can be maintained for customers as well through the XD02 transaction as shown below. In this case the TBRG entries are for the F_KNA1_BED object.
In all the previous articles on BW security, we have already looked the current method of BW security through analysis authorizations. However, even now its possible for customers to continue to use the old security concept using reporting authorization objects (customer created authorization objects of the RSR class). Since there are still quite a few installations that continue to run in the old model let us have a brief look at this concept of BW security.
The basic transaction for maintaining BW 3.5 security is RSSM. The initial screen of the RSSM transaction can be divide into two main areas as shown below. The upper area is used to create new authorization objects whereas as the lower area is used to configure the checks for authorization objects for the individual cubes.
It is here that we create the the RSR authorization objects. During creation we have the choice of adding any of the authorization relevant InfoObjects defined in the system. However note that since these are authorization objects ( as opposed to analysis authorizations), maximum number of fields are limited to 10.
Once created, the second step is to check the relevant authorizations for the individual infocubes. This activity is also performed through RSSM as shown below. Whenever a new Infocube is created in BW, by default all possible authorization objects ( these are the authorization objects which contain any of the InfoObjects defined in the cube) are shown to be checked for it. Its the security administrator’s job to un-check all the unnecessary objects.
Like Analysis Authorizations, checks for reporting authorization which occur during query execution can not be caught through the standard security trace (ST01). We use the transsaction RSSMTRACE to trace security checks for reporting authorization objects. For individual users to be traced, they need to be added to list below. A security trace is generated during query execution for all the listed users. Subsequently the trace can be displayed through the same transaction for analyzing possible security errors.
We have already come across LSMW for mass changes to SAP data. Let us not assume that LSMW is the only tool which can be used to update data in SAP. SAP provides quite a few number of tools, each with its unique features, to allow mass updation of data. In the current article I talk about the Transaction Recorder tool which can be accessed through the transaction SHDB. Like LSMW, SHDB is also used to record certain user actions in the SAP GUI for a particular transaction. These actions are used to create a recording which can be processed at a later time to upload data. Through SHDB it is also quite easy to generate an ABAP report from the recording and modify the generated code to read an input file with a list of records and upload the data though the program. In this article I demonstrate the entire sequence of actions though a recording to reset the password of a user through SU01.
We start the transaction SHDB and click the button for new recording. We give an appropriate name for the recording and input the transaction (SU01 in this case) which we are trying to record.
On clicking the check button, we are taken to the normal SU01 screen where we rest the password of any user id already created in the system (USER01).
On saving the new password and clicking the back button, we are returned SHDB where we can check the steps in the recording.
To test the recording we change the user id to “USER02” and save the recording. Now we can process the recording from SHDB.
On successful processing for the recording, we get a screen showing that password for USER02 was indeed changed.
Although its technically feasible to manually change the data in the recording and process them through SHDB, the generally accepted approach is to generate a program for the recording and update a list of records though ABAP code. SHDB main screen has options to generate a program from recording.
On selecting this option, SHDB prompts us for the attribute details for the program and generates a skeleton code for the recording. We can now update this skeleton code to read data records from a file into an internal table, and loop over each record to update data into SAP. I am not adding the final code in this example but the basic skeleton is given below.
As you can see from the above example, like LSMW, SHDB provides us with another alternate method of upload of data into a SAP system. Which method you finally chose depends a lot on whether you are more comfortable in writing code or creating a the LSMW script.
In the modern enterprises, its very common that dual responsibilities are performed by the same individual. For example a Line Manager in the Training department of an Organization needs access to certain infotypes (like org assignment, personal data, education, etc) for all employees as part of the process structure. In addition to the above, by virtue of his position in the org hierarchy as a Line Manager, he would also need significantly more access (like basic pay for instance) to the employees who report up to him. This is problem of contextual security and is can not be handled properly through the structures that we have covered so far.
Let us investigate further about the possible security solution in this case and try to understand why it might not meet the full requirements. We would need at least two roles for the training manager – on role with training infotypes and a second one with infotypes needed by the line manager. Further we also likely to have two PD profiles as well – on with access to all employees and the other with access to only the direct reports. When the 2 structural and general authorization profiles are assigned to the same person, like to the Training Manager in our discussion, we find that he has access to both sensitive and non sensitive infotypes for all employees. The sensitive access is not limited to only the direct reports as the security system has no way of understanding that access in the manager role needs to be restricted to only the direct reports (the people who are part of the manager PD profile).
The context solution introduced as part of SAP R/3 4.7 seeks to address this very gap in HR security. The context solution introduces new authorization switches and the corresponding authorization objects. To switch on checks for any of the new objects, the corresponding switches should be set to 1. Its also customary to switch off checks(value 0) for the non context authorization objects. The relevant switches are given below
AUTSW-INCON HR: Master Data (Context) for object P_ORGINCON
AUTSW-XXCON HR: Master Data – Enhanced Check (Context) for object P_ORGXXCON
AUTSW-NNCON HR:Customer-Specific Authorization Check (Context) for customer specific authorization object. The switch corresponds to AUTSW-NNNNN (HR: Customer-Specific Authorization Check) in the non context solution.
In addition to the three switches above there is a fourth switch used by the context solution. This last switch – AUTSW – DFCON – HR: Default Position (Context) – is analogous to ORGPD switch used in normal structural authorization as it controls access to non integrated personnel numbers (persons who are on a default position and as a result are not mapped to the organizational structure).
The fields for the individual authorization objects P_ORGINCON and P_ORGXXCON are given below.
Master Data Administrator
Time Recording Administrator
You will notice that new authorization objects differ from the corresponding old objects in a single respect. Both of these have the new field PROFL (Authorization Profile). The PROFL field is meant to store the value of the PD profile for which each general authorization is valid. In other words, the PROFL field serves to link the general authorization with the corresponding structural authorization. Context problems, like the one we discussed about the Training manager, can now be easily solved by maintaining the correct PD profile on the role.
The context solution is truly a welcome addition to the other security features of SAP HCM as it allows us to solve scenarios which couldn’t be solved with the means at our disposal till now. However it comes at the cost of increaded maintenance effort as now in addition the PD profiles assigned to the user, we need to maintain the correct PD profiles for the role as well. Also, we should remember that the context solution only addresses the context problems for accessing people (PA master data). There is still no context solution for PD data secured through PLOG.