The concept of parent and derived roles was introduced by SAP to simplify role administration tasks. Its specially helpful while mapping security for large enterprises spread across multiple geographies or divisions. A child role derived from a parent role will have all attributes (transactions/ authorization object values) same as it parent except the values of the Organizational Level fields (plant, company code, sales organization). Thus maintenance is simplified as only the org levels need be maintained at the derived role level. This also ensures that there is no opportunity to make mistakes during authorization maintenance for the multitude of derived roles and also reduces testing effort for roles.
Creating the parent role follows the same process as creating any other single role. In the example below we create a global role “Z_CREATE_SO_GLOBAL” which allows the creation of Sales Orders (transaction VA01) for all company code, sales orgs.
With the parent already defined we create a child role “Z_CREATE_SO_US” which allows SO creation for the US companies. We maintain the parent role name as shown below.
The menu for a derived role can not be individually maintained as all entries are inherited from the parent.
Now we maintain the org levels values relevant for the child role. In the example below, we have used a dummy value of @ but in a production system the correct value for org levels should be used. The other other need not be maintained at this stage. Now we save the authorization entry for the derived role.
To populate the rest of the authorization values for the child role, we go into the authorization maintenance screen for the parent and click the button “push from gl”. This option pushes the non org level values from the parent to the child role and generates the profiles for both.
The most critical success factor for a parent-derived role concept is how well, the different business processes mapped by SAP roles are mirrored across the different divisions in an enterprise. In other words, a parent-derived role concept will not be very beneficial in case an enterprise follows different business process in its different subsidiaries.
Till now, all our discussion on role administration has been concentrated on creation and maintenance of single roles. A single role as we have seen till now is a collection of tcodes and/or authorization objects. However in addition to these, SAP also allows to create composite roles which contain one or more single roles. In this post, we will discuss the tecnical and business reasons for working with composite roles.
During role creation, the PFCG initial screen allows us to choose whether we create a single or composite roles. Once created, there is no way to changing a single role to a composite or vice versa. In the screen below, we look at the role definition of the SAP_AUDITOR composite role provided by SAP to allow the use Audit Information System (AIS). You will notice that the individual tabs inside PFCG are different from those for a single role. for ex, we do not have the common transaction or authorization tabs. Instead we have the Roles tab and also a menu tab. The roles tab allows us to specify any number of single roles that constitute the composite role as well as the system for the roles. This is important in a SAP system with CUA installed as a composite role defined in the central CUA system can point to roles defined in the child systems.
Even though transactions can not be directly added to a composite role, a composite role can have its own menu structure. We display the same through the Auditor role provided by SAP
Depending on role design or user assignment strategies, composite roles can be used in a number of ways. Lets look at a few scenarios using composite roles.This is not an exhaustive list in any way but just meant to give an idea of the common uses for composites
Single roles are mapped to tasks performed by users . Since a typical user performs multiple tasks, the total access for a user is represented through a composite role which includes the individual task roles.
Access is divided into transaction role ( which contain transactions but no authorization object access ) and value/controller roles (authorization objects but no transactions). Complete access is represented through a composite role with the transaction and value roles.
The entire system landscape consists of a number of separate SAP systems (like ECC, BW, SRM, CRM etc.) and users are administered through a CUA connecting the individual systems. A user getting role A in ECC will need the corresponding role B in BW and role C in CRM. This can be achieved through a composite role created in the central system which links the individual roles in the different systems.
The SU25 transaction is needed during the initial installation of SAP and during each subsequent upgrade. Its main utility is to copy the SAP provided check indicator defaults from the USOBT and USOBX tables to the corresponding customer tables, USOBT_C and USOBX_C. These two sets of tables are needed so that the customer changes are not over-written by SAP delivered values during a future upgrade. The initial screen of the tcode is shown below.
As can be noted, the SU25 transaction is organized as a sequence of actions which need to be executed in order during installation/upgrade depending on requirement. For example, the first step (1) is to initially fill the customer tables (USOBT_C and USOBX_C) is ONLY executed during initial installation of SAP. Executing this step during a future upgrade will over-write all customer changes to check indicators.
The next set of steps compare the customer values with SAP delivered values. We have the option of accepting one or more of SAP proposed values while keeping the customer values for the rest of the objects. Since any change to check indicators for a transaction will impact all roles with it, a change during SU25 should be thorough analyzed and backed up by rigorous testing of the affected transaction.
The SU25 initial screen also has options to transport the new values for the customer tables, modify and generate roles which are affected by changes made for check indicators or even branch to SU24. Its also a good practice to document all changes performed during SU25 to help in future decision making around security.
During installation or an upgrade, SAP delivers a set of default authorization objects which are checked for each t-code which are defined in the system. These default values delivered from SAP are stored in two tables, USOBT and USOBX. The delivered check indicators for a tcode can be displayed through the SU22 transaction the initial screen of which is shown below.
On clicking the execute button we are taken to the next screen which display the delivered values for the check indicators. We can even select an object and display the field values proposed by SAP for it as shown below.
Three unique combination of values are possible for each of the objects maintained in SU22.
Check Ind – Do not check, Proposal – No – The authorization object is not checked during the execution of the tcode. Checks for objects for the Basis and HR classes can never be switched off through this option.
Check Ind – Check, Proposal – No – The check for the authorization object depends on the ABAP code of the program which is being executed. In case an authority-check ABAP statement is present in the code for the object, the object would need to be present in the user buffer for a successful execution. However, since proposal is No, SAP doesn’t pull the object during authorization maintenance in PFCG if the tcode is added to the role. Typically these objects will not be checked during standard execution of the tcode but might be checked while following some of the many navigation options that are present inside a tcode.
Check Ind – Check, Proposal -Yes – The authorization object is checked ( through ABAP) during the execution of the tcode and is proposed (pulled into role) during authorization maintenance in PFCG.
Many a time, we need to change the SAP delivered values for the check indicators. This is done through the SU24 transaction which we will discuss in our next articles. The SAP defaults in SU22 sould never be manually changed by a customer. The SU22 values are only modifed by SAP (automatically) during initial installation or during a service pack upgrade.
SAP Business Information Warehouse or SAP BW or SAP BI is the Business Intelligence and Data Warehousing Product in SAP Netweaver Suite. Being an OLAP system, it has it own security requirements which are often different from a standard OLTP system like SAP ECC and hence this separate discussion. However, before getting into the nitty-gritties of BW security, let us first take some time off to discuss data warehousing in general and how SAP implements it the SAP BW solution.
A data warehouse(DW) is a database used for reporting. Its usually separate from a database used to store transactional data as the goals of reporting is significantly different from OLTP systems. While OLTP systems are optimized for preservation of data integrity and speed of recording of business transactions through use of database normalization and an entity-relationship model, OLAP systems are optimized for speed of data analysis. Frequently data in data warehouses are denormalised via a dimension-based model. Also, to speed data retrieval, data warehouse data are often stored multiple times—in their most granular form and in summarized forms called aggregates. Data warehouse data are gathered from the operational systems and held in the data warehouse even after the data has been purged from the operational systems.
Having a separate data warehouse system is beneficial in many respects
A data warehouse provides a common data model for reporting irrespective of the source of data. Its common that data from multiple operational systems are loaded into a central data warehouse.
A data warehousing solutions helps in the implementation of an efficient decision support systems where key users get access to key data about the enterprise to understand past histories and make future forecasts.
Its typical that reporting on historical data is time intensive. A separate data warehouse allows execution of complex queries without unduly affecting performance of operational systems.
The structure of the SAP BW solution can be divided into the four general layers given below. Each of these layers come with their own tools and will be discussed in the next article.
Extraction, Transformation and Load (ETL) layer is used for extracting data from one or more sources, applying transformation rules on extracted data and loading it into the Data Warehouse Area.
Data Warehousing layer consists of various SAP BW specific data structures (e.g. Data Store Objects, InfoObjects, InfoCubes, etc) to store information.
Presentation layer which comes with tools to analyze data stored in the data warehouse and allows creation and presentation of reports for end users.
Planning and analysis capabilities – In addition to reporting, the latest version of SAP BW provides capabilities for the user to create planning scenarios and perform tasks such as budget calculations.
A related development in the history of SAP BW was SAP’s acquisition of Business Objects (BO). BO has introduced a number of new presentation tools into the SAP Business Intelligence landscape like Crystal Reports, Xcelcius, InfoView. Other than Crystal Reports which introduces some new security concepts, most of the other tools allows the use of the current security model used for BW in general.
“Organizational Levels” (Org Levels) as opposed to authorization fields is another of the core concepts that we come across while creating roles in PFCG. We can access the organizational level values defined for a role by clicking the “org level” button in the main toolbar within PFCG.
In the role below, we see Org Levels like Company Code, Purchasing Org, Purchasing Group, Sales Org, Division, Plant, etc.
In the expanded view of the authorization data in PFCG, the org levels defined earlier appear side-by-side with the authorization fields. In fact, all org levels are also authorization fields but not all auth fields are org levels. For example, the org level Plant appears as an authorization field in two objects, M_LFPL_ORG and M_MATE_WRK. On the other hand the field Activity is not an org level. Once we maintain a particular value for an org level in a role, all authorization objects using the same org level as a field will automatically take the same value. Its technically feasible to break an org level, so that for a particular object, its value is different from its defined org level value but this defeats a the purpose of defining something as an org level.
Another difference between org levels and normal auth fields come to light while deriving a role from another master role. A normal auth field will be inherited by the child role with the same value as maintained in the parent but an org level can be maintained in the individual child roles.
Organizational Levels in most cases are intrinsically linked to the enterprise structure of an organization and largely determined during the customizing steps for the SAP systems. The below screen-shot from the SPRO transaction shows the options for configuring different org levels like company code, controlling area, purchase org, sales org etc. So its not really the security administrator who defines the org levels. He can only use the existing org levels defined during functional configuration.
Its possible to change an authorization field to an org level for the purpose of security by executing the program PFCG_ORGFIELD_CREATE. However, since this program impacts all roles which contain the org field it should only be run after a thorough analysis of all impacted roles. Also certain auth fields like Activity can never be changed to an org level.
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).
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.