After finishing the last post on SE16N and DEBUG, I realised that since this site primarily caters to the aspiring security consultants, some portion of its target audience might be at all familiar with ABAP debugging at all. The idea behind this post is to acquaint Security Consultants with the basics of debugging. This is certainly not meant as a guide on how to debug ABAP code as you would need to be familiar with ABAP syntax to actually debug code. However, I always consider that knowing ABAP is very helpful for any consultant, functional, security or basis. So if you have some free time you can always go through some of the free ABAP tutorials available on the web and the added knowledge would certainly come in handy the longer you stay with SAP. Continue reading “ABAP Debugger”
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.
The authorization checks for PA master data (through P_ORGIN, P_ORGXX, P_PERNR, etc) while running HR reports are very involved and pose a significant performance penalty to the system. For each pernr selected in the report, the authorization system carries out a check for each of the infotypes being accessed.
The P_ABAP (HR Reporting) is used in such cases to simplify the authorization check for PA master data when running HR Reports based on the logical databases SAPDBPNP or SAPDBPAP. The fields available in the object are given below
|Authorization Field||Long Text|
|COARS||Degree of Simplification of the Authorization Check|
|REPID||ABAP Report Name|
The COARS field can two values corresponding to two different degrees of simplification.
- COARS = 1. The authorization checks for the infotype/subtype combination and for organizational assignment are to be checked separately.
- COARS = 2. The report is run without any authorization checks for PA master data.
In practice, P_ABAP can be used in two main cases. A value of COARS = 1 can simplify the authorization checks significantly reducing the time needed to execute a report. This is the case for a number of reports in the pay-time component of HCM. For example, an export of PA master data during a typical payroll run would have to read a large number of PA infotypes for all the employees in the enterprise. Using P_ABAP in this case would ensure that the report completes in a reasonable amount of time. Also since these reports are generally run by payroll staff who already have access to almost all user data, a detailed authorization check for all users’ infotypes is often unneccessary.
A second case for using P_ABAP appears when we want non HR users to be able to run some non sensitive reports on HR data without giving them direct access to P_ORGIN, P_ORGXX and similar objects. A value of COARS = 2 would enable these users to run the said report without any authorization check for PA master data.
Its important to note that a P_ABAP authorization is always restricted to particular reports as a value of * or SAPDBPNP would allow any reports on master data to be run without checking proper authority checks.
Personnel Development (PD) Data is part of the Personnel Planning (PP) Data model used in SAP HCM. The PP Data model is made up distinct HR object types like positions (S), Persons (P), Jobs (C), Tasks (K), etc. The main use of this data is in Personnel Development (PD), Organizational Management (OM) and the Training and Event Management sub-modules of SAP HCM. In contrast to the PA master data which essentially store data for persons, PD data mainly store the attributes of the different PP object types. Also, the allowed PP infotypes depends on the object type and is controlled through configuration settings. PD data is specially relevant for security as it used to define the Organizational Structure of an enterprise and Organizational Structure in turn is used for the position based security assignment and structural authorizations.
PD data is secured by the authorization object, PLOG (Personnel Planing). The fields of this objects are given below.
|Authorization Field||Long Text|
We can better appreciate the use of this object by looking at one of the basic transactions for maintenance of PD data – PP01.
In the initial screen of PP01, we can easily spot the fields for Plan Version, Object types, Infotypes and Planing Status (the tabs for Active, Planned, Submitted, Approved, Rejected). The buttons highlighted in the toolbar are for different activities on the infotype selected. The permissible activities for the object and infotype combination are contained in the PFCODE field of the authorization object. Among the huge multitude of possible values of PFCODE like INSE (create), disp (display), DEL (delete), CUTI (delimit), LISD (List Display), AEND (Change), LIST (List Display with Change), etc we discuss only the last two.
In the first example we select infotype Object (IT 1000) and click the change button. The infotype change screen allows us to change the name and abbreviation of the object (AEND)
In the second example, we select Relationship (IT 1001) and click the second button from right to get into the Overview Screen which shows all the “relationships” created for the Object. The access being tested is LIST. Also note, that accessing overview screen from a pure display transaction like PP01_disp would have checked for LISD (List display). IT 1001 is also one of the PD infotypes which can be secured at the subtype level. Each relationship record shown on the screen (like A002 – reports, B007 describes) is a separate subtype and is meant to link two different object types. The different relationships between these PP objects is actually used to build the entire Organizational Hierarchy of the enterprise.
In addition to the PLOG object, PP objects can be further secured through Structural Authorizations. I hope to cover a discussion of Structural Authorizations in a future article.
The SAP Query component in R/3 provides a way of generating simple reports without any actual coding. From this standpoint, it is similar to the Quickviewer (transaction – SQVI) but more powerful and correspondingly a little more difficult to master. A full description of this great tool is beyond the scope of this article. Instead, my intention is to concentrate almost entirely on the security features for SAP Query and demonstrate how we can use the basic concepts of security to segregate a process chain into clear roles and responsibilities. This is the basic job of an security analyst during the all important phase of security design.
Queries are reports which can be configured by mostly drag and drop operations though a graphical editor to retrieve data from the data dictionary tables. The SAP Query component consists of three main transaction – SQ01, SQ02 and SQ03. SQ01 is the transaction for Query maintenance. It allows us to create, update, delete, display or execute queries.
Queries are not directly defined on tables but use an intermediate object called an Infoset. An infoset can be defined to be a table join or as a logical database and contains the sum total of data which the query defined on it can potentially access. SQ02 is the transaction for infoset maintenance (and display).
The final link in the chain is SQ03 – the transaction for maintenance of query user groups. Unlike many other SAP components ( and like many other ones), security for SAP Queries is not entirely controlled through roles and authorizations. To access a query, an user and and the infoset for the query must be assigned to the same query user group. Please note that the user group for queries is in no way related to the user groups maintained as part of the user master record.
So now, that we have had a brief introduction to the SAP Query transactions, lets turn to the problem of securing this application. Security for the SAP Query application is controlled through the authorization object S_QUERY. The object as the single field Activity (ACTVT) with only three possible values, 2 (change), 23 (maintain) and 67 (translate). Of these activity 2 is needed to change queries, infosets, user groups while 23 is needed for maintaining user group assignment. Also access to SQ02 or SQ03 is not possible without access to 23. Finally, a person with 23 can actually access queries belonging to other user groups without having use SQ03. Its important to note that unlike most other authorization objects, S_QUERY doesn’t have activity 03 ( display) as S_QUERY is not checked during display or execution of queries. Other than S_QUERY a user would also require some form of basic access like S_TABU_DIS for checking access to the actual data retrieved from the tables, access to change layouts (S_ALV_LAYO), exporting retrieved data to excel (S_GUI), etc. In a typical enterprise we might want to segregate access to SAP query to three distinct business roles
- Query Executor – These are the reporting users who will be responsible for actually running the queries and interpreting the results. These are normally business users and are not expected to update/change queries.
- Query Creator – These are the power users who have the business knowledge to actually design/create queries and subsequently change them depending on user requirements. They might also need to maintain Infosets.They should also be able to execute the queries to check that the designed queries output correct data. However, since the query executor is still a business user, as security administrator we would not want to give them the responsibility of assigning user groups and control who gets what!
- Query Administrators – These are the support personnel who are responsible for maintaining the user group mapping. These users would not be maintaining query design even executing queries.
With the above requirements in mind, let us design three roles for the three separate classes of people.
- Query Executor – Need access to SQ01 but not S_QUERY. Also should have access to data they are trying to retrieve (S_TABU_DIS).
- Query Creator – Access to SQ01 and SQ02 as well as S_QUERY (both activities 02 and 23). Should also have access to table data through S_TABU_DIS. Should not have access to SQ03.
- Query Administrator – Access to SQ03 as well as S_QUERY(both activities 02 and 23). No need for access to table data.
Thus we have successfully mapped business roles to SAP roles. This is the final goal for all security analysts. The only problem is instead of a single authorization object and three tcodes we are working on thousands!
We have already come across PA (Personnel Admin) master data in our initial discussion of different types of the HR data. Out of the box, SAP provides three main authorization objects for securing PA master data, P_ORGIN, P_ORGXX and P_PERNR. Lets see how we can use each one of these in our security design landscape.
PA master data stored in different infotypes is essentially the attributes for the employees of the organisation. To store these attributes each employee is associated with an unique personnel number or PERNR. SAP HCM currently allows a person to have multiple pernrs as part of its extended configuration but that is beyond the scope of our discussion on basic HR security. The basic transaction for maintenance of PA master data is PA30. The first screenprint shows the initial screen of PA30 with the pernr and name of an employee.
In HR, the pernr similar in use to the system id used in the security system. In fact we use the infotype 0105 (communication), subtype 0001 to store the SAP system id corresponding to the pernr for an user. Later we will find that this link is mandatory for the use of the P_PERNR authorization object.
The first step in using any of the PA master data authorization objects is switching on the corrsonding authorization switches for them in the transaction OOAC. For ex, to switch on security checks for P_ORGIN and P_PERNR we need to set the authorization switches AUTSW-ORGIN and AUTSW-PERNR values to 1 respectively. Once switched on, any access to PA master data will check the user master for these authorization objects.
The most important infotype with regard to any discussion on PA master data security is the Organisation Assignment (0001) infotype. The screenprint below shows the IT 0001 screen with the different data contained in it. This infotype is important as the data fields of this infotype are also part of the general authorization objects and are checked during data access. For ex, Personnel Area, EE group, EE subgroup, Cost Center, Payroll Area and the three Administrator fields are all used in the authorization objects.
The three common authorization objects with their authorization fields are given below
P_ORGIN (HR: Master Data)
|Authorization Field||Long Text|
P_ORGXX (HR: Master Data – Extended Check)
|Authorization Field||Long Text|
|SACHP||Master Data Administrator|
|SACHZ||Time Recording Administrator|
P_PERNR (HR: Master Data – Personnel Number Check)
|Authorization Field||Long Text|
|PSIGN||Interpretation of Assigned Authorization|
As you might have noticed, many of these fields were part of the org assignment infotype. Thus if a security concept is built around personnel area, employee group, employee subgroup we can switch on the check for P_ORGIN and use the auth object in our roles or if the security concept is based around the time, master data and payroll administrators we can use the P_ORGXX authorization object. In some rare scenarios we might even want to use both the authorization objects in our roles. A case where both of them might be used is a scenario where we have different master data administrators for a single personnel area. Here instead of creating of roles with all the different combinations for P_ORGIN (Personnel Area) and P_ORGXX (Administrators), we can reduce the number the of roles by separting out these two accesses into different roles. Finally a combination of the P_ORGIN and P_ORGXX roles will be assigned to a user to make up the total accesss of a HR rep. You would also notice that the standard authorization objects do not have any option to secure PA data at the level of the personnel sub area or cost center. A solution in such cases is provided by the Organization Key field. This is a 14 character field which can be configured to be derived from any of the IT 0001 fields or can be even manually entered by the administrator.
The P_PERNR authorization object is a bit different in functionality from the other two objects. The P_PERNR object provides one of the very few examples of negative authorization concept in SAP. The object is used to provide different authorization to an administrator when accessing his own PERNR. The most common example is of a compensation analyst having access to update the basic pay infotype. Though as part of his usual responsibility, hw would be expected to maintain the basic pay of other employees, we would not want him to give himself a raise. Its at this juncture that P_PERNR and its negative authorization comes to the rescue. The master data authorization of this person might typically be maintained as the following
AUTHC W, R, M
AUTHC W, D, S, E
In the above case, the P_ORGIN authorization gives the comp analyst access to maintain (AUTHC – W – Write) the basic pay (IT 0008) for others but when accessing his own pernr, the value of P_ORGIN is over-ridden by the access in P_PERNR. The value of PSIGN as E (Exclusive) denotes that while accessing IT 0008 for his own pernr, his access will exclude the values maintained for AUTHC (W, D, S, E). The only possible values for AUTHC which excludes the 4 given values are R (Read) and M (matchcode) and as a result the administrator only has display access to his own pay data.
Its very important to remember a few points when trying to use P_PERNR. Firstly P_PERNR can only be used to provide access to a person’s own pernr or personnel record. A corollary of this, is the requirement that for P_PERNR to work a valid system id should be maintained for IT 0105, subtype 0001. This is necessary as the SAP system needs to identify a personnel record with a user master record. Secondly, the only two possible values of the PSIGN field are E (Exclusive) and I (Inclusive). A value of * doesn’t make much in this case as by definition, a * value can be interpreted as either of the two possible values.
SAP delivers ECC 6.0 with more than 3000 authorization objects. Remembering even a tiny fraction of the total number is a daunting task. SAP help provides adequate documentation on the fields and use of most, if not all, the delivered objects. So instead of repeating existing information here, I would just mention a few of the existing authorization objects and their applications.
- Tables – Security for tables are controlled through three authorization objects, S_TABU_DIS (based on the table authorization group), S_TABU_CLI (security for client independent tables) and S_TABU_LIN (row level access to tables).
- Reports – Reports/Executable programs (Executable programs are just one of many different types of programs) can be protected through S_PROGRAM. S_PROGRAM checks if the executing user has access to the program authorization group maintained as a program attribute.
- Background Jobs – The basic object is S_BTCH_JOB. To administer jobs created by other users, users would also need S_BTCH_ADM. To schedule jobs with the access of another user would require S_BTCH_NAM.
- Spools – S_ADMI_FCD, S_SPO_ACT, S_SPO_DEVand S_SPO_PAGE. S_SPO_ACT can be used to give access to spools with specific authorization values. S_ADMI_FCD in addition to spools controls access to a lot of system administration/Basis function.
- User/Roles – A number of authorizations like S_USER_AGR, S_USER_AUT, S_USER_GRP, S_USER_OBJ, S_USER_PRO, S_USER_SAS. You can segregate the access for role administration with that of user administration by use of these objects.
- BDC Sessions – S_BDC_MONI. Batch Sessions are one of the possible ways of loading data intoSAP. Sessions are monitored through the SM35 transaction. S_BDC_MONI allows security on session names and the possible activites (process, lock, delete) on sessions.
- ABAP Work Bench – Access to ABAP development objects is controlled through S_DEVELOP. Controls are possible on object type, object name, activity, packages.
You might have noticed that all the above authorization objects begin with S as they deal with System Administration. I have purposely not included authorization belonging to the individual application components like MM, FICO, SD or HR as a discussion of these do nt make sense without discussing the applications themselves. So, we keep these for a later post.
Often a security administrator comes across requirements where the existing authorization objects delivered by SAP is not enough. Mostly these come during custom developments through completely new programs or enhancements to existing SAP programs. In such situations, SAP provides us with the option of defining completely new authorization objects. The names of these customer specific objects should begin with Y or Z and can be created through the SU21 transaction. If required we can define new authorization fields as well through the transaction SU20.
In the example below, we are set to create a new authorization field and use it in a new authorization object. First we go into Su20 and select the create option from the toolbar. We create a new field “ZBOOLEAN” which takes two possible values ‘X’ and ‘ ‘. The possible values for a field are controlled by the definition of the data element specified in the ABAP dictionary, in this case which is BOOLE_D. We might create our own data elements as well through SE11 transaction. On saving the new field we are prompted for a package for our new development. Packages are dictionary objects to group similar objects for transporting across development, quality assurance and production systems. We if do not plan to transport the new field we can select the local object (package $TMP) from the options.
Once the authorization field is created, its time to include it in a custom authorization object through Su21. We select the authorization class of the object and select the crate option. (Su21 also allows us to create our own authorization classes. Its a good practice to create at least one Z or Y authorization class to include our custom authorization objects).
We define the authorization field(s) for the new authorization object. Like the SAP delivered objects we are limited to a maximum of ten fields for custom objects as well. We should create some object documentation as well for future reference. On saving the new object we are again prompted for a package and we have the option of specifying a particular package or creating the new development as a local object. Typically at this point, the security administrator will contact the ABAP programmer to include a check for the new object in his code.
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.
The introductory article gave a glimpse of one of the thousands of SAP applications delivered as part of a SAP standard package. This article follows on from there and starts our journey on SAP security. It tries to answer three basic questions: What is security? Why do we need security? and How does SAP implement security?
Q. What is Security?
A. Security in the context of IT denotes giving access to users to only those sytem resources which they require to perform their jobs. in SAP, these resources generally take the form of either business application or administation tools through transactions, screens, tables, programs, reports, web services, etc.
Q. Why do we need Security?
A. SAP being an ERP solutions comes loaded with a huge number of applications which can be configured to map the business processes of an organization like procurement, manufacturing, sales, financial accounting, controlling and human resource mangement. It is imperative that only actual employees/business partners get access to the SAP system (Authentication). Further, each user using the SAP system should only have access to the applications relevant to their jobs (Authorization). For example, we certainly do not want an employee working on the shop floor to get access to see and update the bank details for other employees, a job typically reserved for the HR department.
Q. How does SAP implement security?
Authentication is ensured by having an unique user-id and password for each user maintained as part of the user master record. Any user trying to access a SAP system should have a valid User Master Record. In addition to the user id and password, a user master record also lists the user’s name, email, telephone and the roles which allow access to different applications.
Auhtorizations are implement through roles (or the older term activity groups) and typically assigned to users through their user master record. Each role also has one or more corresponding authorization profiles with different authorizations. Its the authorization profiles which actually give access to users.