Parent & Derived Roles
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
Interested in mastering SAP Security Training? Enroll now for FREE demo on SAP Security Training Online.
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.
A single role as we have seen till now is a collection of t codes 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 technical 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
PFCG – Composite Role Menu
- 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 & Value Roles
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 ofseparate 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.
Check out the top SAP Security Interview Questions now!
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.
Organizational Management in SAP-Security
Organizational management is meant to be a launchpad to our discussion on structural authorizations- an unique and indispensable part of HR security. We ave already have had a brief idea on Org Mgmt or OM when talking about the PLOG authorization object. Lets take the discussion forward to the next level. OM deals with the representation of the personnel organizational structure within an enterprise within SAP HCM. OM uses the same data model as used by Personnel Planning.
The data model uses object-oriented design and uses the concepts of
- Object Types
Object Types: Objects that are used to create an organizational plan in Organizational Management. The following object types are available:
- Organizational Unit
- Work Center
An organizational object comprises:
- A short and long description
- An 8 digit ID number and a description
- A relationship, which defines the link between the object and other objects
- Various object characteristics
- A validity period and a time constraint
- A status indicator
These core tutorials will help you to learn the Organizational Management in SAP-Security. For an in-depth understanding and practical experience, explore SAP Security Training Videos.
By defining relationships between objects, you create a hierarchy of objects that mirrors your organizational structure.
In Detail Maintenance, you create relationships between objects by entering information in the Relationshipinfotype (1001). In Simple Maintenance, it is more straightforward. When you create a new object, the system creates that object’s relationships.
You use the network of relationships between objects to model the reporting structures of your organization.
There are many different types of relationships between objects in the component Organizational Management. It is the relationships between objects that give information its value. It is important to understand the syntax used to identify relationships and the structure of relationships.
Syntax Used to Identify Relationships
The standard syntax used to identify a relationship is A/B 000. A/B refers to the two different sides of a relationship, which you create when you link two objects. The system calls these sides passive (A) and active (B). They form the reciprocal relationship, and are vital in holding the relationship together. The three-digit numerical code identifies the relationship.
You assign a position to an organizational unit, to identify where the position is allocated. The system creates a relationship infotype record between the organizational unit and the position. You can check the relationship in the Relationship infotype screen in Detail Maintenance. This relationship is called 003. This means the position belongs to the organizational unit, which in turn incorporates the position. The organizational unit’s relationship record is B 003 and the position’s is A 003.
Structure of Relationships
A relationship between two objects can be structured:
For example, the relationship between a senior position in an organizational unit and another position in that same unit is hierarchical. The senior position (B 002) is line supervisor to the lower placed position (A 002) which reports to the position above.
A lateral or flat relationship, for example, is relationship 041, which names a situation where two jobs are equivalent, and can replace each other. One side of the relationship is A 041, the other is B 041, but the two sides have equal standing. A relationship between a job and a position is also a lateral relationship.
A relationship can be one-sided. For example, a relationship between an object (such as a position) and an external object type (a cost center in Controlling, perhaps), has only one direction and so is one-sided.
Inheritance is one of the most powerful aspects of the component Organizational Management. Inheritance is when an object automatically receives attributes assigned to another object. It occurs when:
The object concerned shares a special type of relationship with another object
Objects are placed below other objects in a hierarchical structure
Inheritance is particularly useful as a time-saver. In setting up your organizational plan, you create numerous objects with individual attributes. However, many objects share the same attributes. Entering the same attributes for each object takes a lot of time. Instead, inheritance does this for you.
- If you need to enter the working hours of 40 positions, you define the working hours for the organizational unit, and the positions inherit these automatically.
- Perhaps your company has employed 20 new consultants. Each of these positions inherits the attributes of the job consultant.
There are two Methods to Maintain SAP – Organizational Management Infotypes
- Using Organization and Staffing Transaction
- Using the Expert Mode.
The Expert Mode is an interface that is ideal for maintaining details. Individual objects are selected using the Object Manager. Infotypes for that particular object can now be maintained.
Transaction code PP01 can be used to maintain all object types. Due to authorization restrictions, you may not have access to PP01. Instead, you will have to use one of the following transactions, which restrict access to one particular object type:
- PO10 Organizational Unit
- PO03 Job
- PO13 Position
- PO01 Work Center
- Plan Version: It is important to ensure that you are working in the correct plan version at all times (for this you can also default the plan version in the user parameter
- Object Information:The object type, ID and abbreviation are displayed so the user can ensure that the right object is being edited.
- Status: Select the status of the infotype you want to maintain using the tab pages (select Active which has status = 1).
- Infotype: Select the infotype you want to maintain.
- Validity Period: Start and end dates specify the period during which the object exists in the plan version selected.
Organizational plans can also include organizational objects that come from components other than Organizational Management (cost center or person (employee or user), for example) or objects defined in customizing.
The data model can be represented by the following graphic.Note that objects types, Person ans cost center are shown as orange boxes instead of blue ones. These are external objects and not created in the OM component.
A typical org structure when represented by the same data model might look something like the graphic(transaction PPOC) shown below
While the relationship between two objects is stored in the IT 1001 (table HRP1001).
HRP1001- Relationships for a position
Finally, the org structure composed through these two tables is displayed through the PPOSE transaction as shown below