Problem Statement

SoD (Segregation of Duties) Violation has been raised for many roles and that need to be remediated.

Proposed Solution- SAP Security Role Redesign

 DUPLICATE Roles and their User assignments need to be revisited.
 Roles Design and Assignment must be aligned with understanding of user/tasks/transaction-based
design and its Utilization
 Rationalize SAP role design based on business process flow and logical grouping of related tasks to
replace user/transaction-based role design
 SAP Security Architecture design that can be used as model for baseline roles and scalable for future
strategic business expansions in terms of Company codes, Plants, Storage Locations, Profit centers,
Warehouse Numbers
 Identify and restrict critical access based on Authorization Object, Cost Center, Document types,
Authorization groups 🡪 Tables, programs
 Elimination of Segregation of Duty conflicts within SAP roles

Benefits of SAP Security Role Redesign

 Cleaner SAP Roles– Removal of Duplicate Roles and removing unnecessary and unutilized
roles/tasks/permissions shall provide a clean Authorization environment with minimized SoD Risk
Violations.
 Fewer role change requests– Well designed security roles lead to fewer number of security role
change requests. A robustly designed and tested security model can reduce role change requirements
considerably. Optimized role ownership reduces the administrative and operational overhead and
ensures that role design continues to be in place even after the redesign effort.
 Faster security administration– Removal of redundant and unnecessary transaction codes from
security roles leads to faster and easier user role administration. Consistent and well-defined naming
convention supplemented by text descriptions that are intuitive and are attuned to the role contents
will facilitate faster and more accurate user access provisioning.
 Increased flexibility and scalability– A good security role design is flexible and can easily scale to
support future growth and merger and acquisition activities. As Customer continues to roll SAP out to
other locations, a scalable solution can be leveraged to reduce time spent on Security and ensure
access and SoD controls are maintained.

Guiding Principles
Some of the basic principles that will guide the role redesign process are:

 Use a task-based approach to develop simple roles that reflect the task performed. This requires less
maintenance effort and minimizes SOD conflicts within roles. (Example: Maintain PO, Display PO)
 Develop master and derived roles so that organizational level restrictions can be utilized. Derived
roles also allow for simplified role maintenance.
 Future maintenance should consist of minimal additions/removals of transaction codes to SAP roles.
Instead, if changes are necessary, the SAP to Business role mappings should be updated.

New Roles: Criteria & Methodology

Criteria
1. There should be no SOD conflict within a Task role. Activities that can cause SOD conflicts when
grouped together will be split into separate task-based roles.
2. Each transaction code should be in as few roles as possible. For example, instead of putting FK10N
(Vendor Balance Display) in multiple roles, this should be put into a separate task-based SAP role,
 such as Display Vendor Documents. This SAP role can then be mapped to multiple Business
roles/composite roles.

Methodology

1. Identify all transactions executed in past

2. Eliminate all transactions that have not been executed in past 2 years from scope
3. Break down the existing roles into task-based roles (in order to break down SOD conflicts)
4. Work with Business Analysts to identify the user to task based role mapping. Example- Jack will
need: Maintain PO, Maintain SA, Display Vendor

Parent & Derived Roles

The concept of parent and derived roles was introduced by SAP to simplify role administration tasks. It's
especially helpful while mapping security for large enterprises spread across multiple geographies or
divisions. A child's role derived from a parent role will have all the attributes similar to parent except the
Organizational Level field values. Therefore, maintenance is simplified at the derived role level. This also
makes sure that no mistake is made during the authorization of derived roles and even lessens the testing
effort.

Creating a 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 org.

The menu for a derived role cannot be individually maintained as all entries are inherited from the parent.

Now we maintain the values of the org levels 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 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's 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 a different
business process in its different subsidiaries.

Composite Roles
A single role is an integration of t codes and authorization objects. However, SAP also designs composite
roles that contain one or a few single roles. Let us explore the technical and business reasons for
exploring composite roles.

In the course of creating a role, the PFCG initial screen enables to select either a single or composite role.
Once designed, there is no chance of altering a single role to a composite or vice versa.

The below screen displays the role definition of the SAP_AUDITOR composite role that employs the
Audit Information System (AIS). One shall notice that the individual tabs differ from those of a single
role. Instead, we have the Roles tab and a menu tab.

Although transactions cannot be added directly to a composite role, however, it can have its own menu
structure that is displayed through the SAP Auditor role.

PFCG - Composite Role Menu

 Composite roles are used in many ways based on role design and strategies. Lets us take a look at
a few scenarios that are predicted using composite roles. This list provides an idea of the common
uses.
 Single roles are mapped to user tasks. As any typical user performs multiple tasks, the total user
access is represented through a composite role.
 Access is usually divided into transaction role and controller role. Entire access is represented
through a composite role.
 The entire system landscape comprises a number of separate SAP systems and users are directed
through a CUA. A user maintaining a role A in ECC will handle the corresponding role B in BW
and role C in CRM. This can be achieved through a composite role that links to the individual
roles in the various systems.

Checkout Our  Frequently Asked SAP Security Interview Questions

Transaction & Value Roles

The transaction and value/controller role concept deals with the design of individual transaction roles and
authorization objects. Authorization objects deal with the final transaction access. The transactional role
also handles the authorization objects. Authorization objects are manually added to the value roles.

During the assignment, both transaction and value roles need to be assigned to a user. In a typical
scenario, a transaction role might be created to map various jobs of an enterprise. After a transaction role
is set up, few broad value roles are designed with authorization objects. The number of value roles are
usually much lesser than the transaction roles and possess authorization objects.

Organizational Management in SAP-Security

Organizational management is meant to be a launchpad to our discussion on structural authorizations a

unique and indispensable part of HR security. We already have had a brief idea on Org Mgmt or OM
when talking about the PLOG authorization object. Let's 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
 Relationships
 Infotypes

Object Types: Objects that are used to create an organizational plan in Organizational Management.  The
following object types are available:

 Organizational Unit
 Position
 Job
 Work Center
 Task

Structure

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

Relationships

Relationships among objects create a hierarchy that mirrors organizational structure.

Use: In Detail Maintenance, you create relationships between objects by entering information in the
Relationship info type (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.

Structure: 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 info type record between the organizational unit and the position. You can check the
relationship in the Relationship info type 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 positions are A 003.

Structure of Relationships: A relationship between two objects can be structured:

 Hierarchically
 Laterally
 Unilaterally

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 the line supervisor to the lower placed
position (A 002) which reports to the position above.

A lateral or flat relationship, for example, relationship 041, is made with two jobs equivalent, which can
also be replaced. 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.

Integration

Inheritance is one of the most powerful aspects of 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

For example, positions always inherit the attributes of the job to which they are related. This concept is
fundamental.

Objects are placed below other objects in a hierarchical structure

The lower-level objects inherit the attributes of the higher-level objects unless you specifically provide
other attributes. (The Simple Maintenance tree structure, which illustrates this hierarchy, can help you
visualize how inheritance takes place.)

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.

Infotypes

Two Methods can be used in Maintaining Infotypes

  Organization and
 Staffing Transaction

Expert Mode.: Expert Mode handles details. Object Manager chooses the Individual objects. Infotype for
each object can then be upheld.

PP01 handles all the object types. Due to certain authorization restrictions, PP01, might not have access.
Instead, the below transactions are used to restrict access:

 PO01 Work Center
 PO03 Job
 PO10 Organizational Unit
 PO13 Position

Plan Version: Correct Plan Version ensures effective working, each time.

Object Information: Each object information is displayed at each end so that the user is aware of the
object being edited.

Status: Tab pages are utilized in selecting the status of the info type.

Infotype: Select the desired info type.

Validity Period: Beginning and ending dates specifies the period of object existence.

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 object types, Person, and 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).

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.

For In-depth knowledge on SAP Security click on:

 Miscellaneous Security in SAP-Security

 SHDB – Transaction Recorder in SAP-Security
 SQVI – Quickviewer in SAP-Security