Moving to a new organization from May so its very possible that I do not get time to update this blog for sometime. Please know that I am still around and will get back once I land on my feet……Regards, Aninda
The idea for this post was suggested to me by one of the visitors of this blog, who had put in a comment around the use of value roles in security design. I though that the question was general enough to merit its own post instead of a reply to the comment. Let me first begin with a confession, though I have worked in a few set ups using this concept, I have never understood their effectiveness in security design. For me, value role create more problems than they solve. I agree that my views are colored by the projects that I have worked on and elsewhere, their use might make a whole lot of design sense. If any of the visitors have any experience in innovative use of value roles which really simplified security design, please feel free to comment. A healthy discussion on the subject will help everyone of the readers including myself!
The transaction and value/controller role concept revolves around creation of separate roles for transactions ( with S_TCODE) and authorization objects with org level values. The latter are the value roles as the individual values for the org levels are maintained therein. Elsewhere they are also known as controller roles or enablers, as they control the final access to a transaction. The transactional role in addition to S_TCODE also contain the authorization objects which do not have org level values. Since the value roles do not have transaction in their menu, the authorization objects are manually added to them. During assignment, both transaction and value roles need to be assigned to a user (sometimes via a composite role). There is no hard rule around the number of transaction or value roles. In a typical scenario, a transaction roles might be created to map the different jobs defined in the enterprise. A possible starting point of such a design will be provided by the user-transaction matrix. After the transaction roles are set up, a few broad value roles are created with authorization objects needed for a functional area (SD, MM, HR, FICO etc). The number of value roles generally will be much lesser than the number of transaction roles and will have all or most of the authorization objects belonging to the functional area. We can also have separate value roles for display and update and also different ones for the different ones for the various divisions in the enterprise.
I believe the initial logic behind adoption of the value/controller roles was reduction in maintenance effort. For example, instead of maintaining tcodes and authorization objects in all roles, we just add the tcodes to the single transaction role and the authorization objects to the value roles. In fact, since SU24 entries are not involved (authorization objects are manually added to the value roles), value roles will be only be need to be updated for a new authorization object (i.e. an object not used in the transactions being already used). Some people might also consider it to be a cleaner design, to keep the transactions and authorization objects separate.
After knowing the background of value roles, lets explore the problems created by their use. For me the biggest casualty of the value roles, is the loss of all information contained in the SU24 entry for the transaction as transactions and the objects needed for its execution are present in different roles. Without strong documentation practices, we can often end up with a situation where no one has any idea why a particular authorization object was added to a value role. A direct result of the above problem, is the fact that most value roles have more authorizations than are needed for execution of the transaction present with a user through a transaction role. A further problem arises because in many cases SAP allows us to jump to different transaction screens by following navigation options in the menu for a tcode i.e. moving from a display to the corresponding update transaction. Even though SAP would normally check for update activity in such a case, a S_TCODE check might not be enforced. Hence, user would get access to an update transaction through the value role even though transaction role only allows the display version. There might be many other such cases, where access present in the value roles might open up extra access with the tcodes present in the transaction roles. Finally the security testing effort is also increased a great deal as without the use of SU24 to guide us, the only way to determine the complete access needed for a tcode is run a trace for each new transaction and check each of the value roles to ensure that they contain required access.
I have already mentioned my skepticism for the value role concept for security design. In fact, I am even unwilling to accept the argument about less maintenance effort for value roles as the same can be realized with a parent-child role based design. However, there is overwhelming majority of security installations which continue to use value roles. If any senior security experts are currently reading this post, I would sincerely request their comments on the same as its extremely probable that I am missing something about the potential benefits for value roles.
In the last article we have already looked at the process of indirect role assignment through OM objects. SAP provides another option to achieve indirect assignment of security through the org structure of the enterprise. This method involves indirect assignment of authorization profiles. Though much less common now-a-days as most companies have moved to a system where access is based on roles instead of authorization profiles, there is really nothing preventing its use in even a role based system.
The basic concept of indirect assignment remains the same. Instead of creating B007 relationships, between the user’s position and object type AG, we maintain infotype 1016 for the position with the profile names. An example screen-shot is given below. Through configuration, its also possible to maintain IT 1016 for other org objects like jobs, org units, tasks, etc.
To copy the profiles from HR objects to users, the report RHPROFL0 is used with the options shown below. This report can also be scheduled to run in the background everyday at midnight to sync up user access (both PD profiles and general authorization profiles) with a changing org structure.
We have come across the Organizational Management (OM) component while talking about SAP HCM. The OM component in SAP is used to map the Organizational Hierarchy of an enterprise by means of HR objects and Relationships between these objects. In this post we will discuss about the possibility of using OM to simplify some of the user-role assignments tasks that need to be handled by a security administrator.
Lets start with an sample org hierarchy created in PPOME transaction as shown below. We start with a root org unit ( HR obj O) “IDES Root” with “IDES India” and “IDES Bangalore” under it. ” IDES India” includes the position (HR obj S) of “Director – India” which is also set as the Line Manager for it. The position is filled by person (HR obj P) “Mister Director”. We make the basic assumption that the SAP access for a user corresponds to his position in the org structure of the enterprise.
Consider the access for “Mister Director”. In the case of direct role assignment, any role would be assigned to the user id for “Mister Director” through SU01 or PFCG. Now lets consider, that “Mister Director” get promoted to be the CEO of “IDES Root” and a new person comes to take his place. However, since the roles for the India Director were directly assigned to his user id, he will continue to keep his old access even in his new position. Also the new person filling the position of “Director – India” will have to be manually assigned with enough access to enable him to do his job. This same situation will repeat for every transfer, promotion, demotion (and most other org changes in general) that takes place in an enterprise. For an enterprise with more than a few thousand employees, the effort involved in keeping user access in sync with the org hierarchy is substantial. In addition to the monetary cost of the effort, their is a time penalty as users would need to wait for the User Admin team to adjust their security before they can start using SAP. Indirect role assignment comes to the rescue in such situation and if configured correctly can reduce the routine maintenance effort appreciably. In indirect assignment, instead o directly assigning the roles to user id for “Mister Director” we assign the roles to the position “Director India” (The standard SAP configuration allows role assignments to the OM objects – Position, Org Unit, Work Center, Task and can be used depending on business cases) such that any user occupying the position would automatically get the access needed for “Director India”.
There are four technical prerequisites for the use of indirect role assignment through Org Mgmt
- An active planning version must be defined in the system. Roles/profiles are assigned to the OM objects defined in the active plan.
- The User and Personnel masters are linked via the IT 0105 (communication) subtype 0001 (system id). This translates to maintaining the SAP user id for a user in IT 0105, 0001 for the user’s personnel number with an active validity date.
- The HR_ORG_ACTIVE customizing switch is set to YES in the PRGN_CUST table either as the default value or as an entry in the table.
- The evaluation path US_ACTGR is defined and suitably adjusted in the system. The evaluation path is actually used by SAP to assign roles to the users during user comparison and is the last and the most vital cog in the wheel. The screen-shot below shows the default definition of the evaluation path in OOAW.
Once the above prerequisites are met, we can just go ahead and create indirect role assignments between roles and HR objects. Indirect role assignment through PFCG can be accessed through the “Organization Management” button shown below. The blue lines correspond to indirect role assignments.
Clicking the Org Mgmt button opens the below screen where we can check the existing assignments for the role (both direct and indirect). New role assignments can e created using the highlighted button
Roles can also be assigned through PP01. An indirect role assignment is a relationship between object type AG (Activity Group or Role) and HR objects like positions, org units, etc. Below screen shows a new assignment (relationship B007) between the users’ position and the role object (object type AG)
The final step in the process of indirect role assignment is to copy the roles from the HR objects to the users. One of the most common way to achieve this is to execute the PFUD transaction with the option for HR reconciliation checked. In productive systems, this program is normally scheduled to run everyday at midnight to sync user access with a changing org structure.
The critical success factor for indirect role assignment is to understand how correctly your org hierarchy mirrors the roles/ responsibilities of your users. Some of the questions that need to be discussed with your business owners, functional consultants and security team are
- What is the correlation between the roles/responsibilities users and their position in the org structure?
- Who will be responsible for maintaining the org structure and how frequently?
- Will users need their old access even if they move to a new position?
- How will contractors be given access? Contractors are normally not part of the org structure and don’t occupy a position. So do you continue to directly assign roles to contractors or do you link them to the org structure in some way (for example through positions/jobs/tasks)?
- Are you only concerned about a central ECC system or are there other systems in the landscape (BW, CRM, SRM, APO, etc)? Will the roles assigned in these other systems also be determined by the users’ positions in ECC?
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.
Transaction variants allows us to selectively mask certain fields in SAP transactions/screens. Though strictly not a security tool, transaction variants can have applications in security by helping to prevent users from updating fields which are not protected through authorization objects
Transaction Variants are created trough the SHD0 t-code. The initial screen SHD0 is given below. To create a transaction variant we mention the name of the parent transaction, give a name of the variant and click the create button.
In our example below, we create a transaction variant ZSU01 for the very common SU01 tcode. The transaction variant allows an administrator only to reset passwords and hides all other functions of SU01. Each transaction variant contains of one or more screen variants depending on the number of screens being called in the entire transaction flow. We don’t have to manually keep track of the screen variants when we are working with transaction variants. As we move from one screen to the next, SHD0 automatically creates and appends a new screen variant to the sequence.
On clicking the create button for ZSU01, we are taken to the standard SU01 screen. We enter a user name and click the change password button. A pop-up window appears with a list of the screen fields. This window contains the attributes of our first screen variant. Its here where we enter a name of the screen variant and can selectively mark screen fields to invisible/output only/required, etc.
The screen variant window has a button for “Menu Functions” where we can selectively hide/de-activate menu items or toolbar buttons. Since our intention is to disable everything except password change options, we end up with below screen.
On clicking the check button from the screen variant we are taken to the next screen and need to save our entries for the password change screen.
On clicking, the save and exit button we are taken to the overview screen for the transaction variant. As shown below, this screen gives the definition of the individual screen variants which form part of the transaction variant. On saving our entries, we are taken to the SHD0 initial screen which shows the transaction variant and the screen variants defined under it.
SHD0 provides a test button here we can check if the newly created transaction variants works as per our requirement. Once tested we create a new Z transaction (ZSU01) for the transaction variant by following the menu path Goto>Create Variant Transaction.
Once set up, this new transaction can be assigned to a user’s role just like a normal transaction. Executing, ZSU01 display a modified form of SU01 screen with all functions other than change password button is disabled.
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.
The PRGN_CUST tables contains entries for a number of switches which can affect the default behavior of various security transactions. To move away from the default behavior, we need to create the entries for the switches with the appropriate values. The list of allowed entries keep on changing depending on the version of SAP being used. Hence, the best way to find the allowed list of values for your system is to open up the table in SM30 and try to enter a new entry. A search for the possible entries will display the allowed entries and also the SAP notes which describe their use.
The screen below, gives some of the possible entries for a system on SAP R/3 4.7.
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.