Comparison of SAP Role Design Concepts

This article compares three different SAP role design concepts and explains the pros and cons of each approach. These are single roles, composite roles, and enabler role concepts. Each of the concepts can either follow a task- or job-based approach to authorizing end-users. We base our recommendations on a decade-long experience with modern sustainable concepts, accepted opinions from experts in the SAP community, and statistical data collected from past role redesign projects.

SAP Role Design Concepts

Single Roles

A single role contains all the authorization objects and field values (organizational and non-organizational) required for the transactions that the role contains. In SAP, authorization objects are represented by two types of fields – the so-called activity field and organization value field. Technically, you cannot separate the two fields, because the SAP kernel evaluates them together during an authority check, and hence they must be in the same role. However, a single role can have multiple individual authorization instances, to depict different combinations of the field values when these cannot be merged into one authorization instance to be evaluated by the check. So a single role can also be a composite of authorization instances.

Typically, when someone talks about a “Single Role” concept, they are referring to a job/position-based role design. In such cases, it contains all required authorizations for a user’s job/position in a single role. They might, however, have more than one job/position. So, more than one single role, such as purchaser but also contract manager, but each authorization set to complete the transactions are contained in each of the two single roles such that they are functional on their own. There are no dependencies.

However, many “single role” designs do not contain all of a user’s required authorizations. It is not uncommon to create a “basic authorization” role that contains transactions and authorizations that are common for all users. For example, the ability to print, or to get to SAP Office Mailboxes, etc. Likewise, some employees might have additional authorizations to execute special tasks. As a result, such employees may get a “special task” single role assigned to them. For example, the ability to close accounting periods or approve purchase requisitions.

Derivation of Single Roles

You can also use single roles for role derivation. Derived roles consist of a so-called master or parent role and additional child roles that differ from the master and each other only in their organizational values. Please note, that there are limitations of this approach. If you try to promote non-organizational fields to organizational fields then, in this case, the values must all be the same within one role, regardless of which authorization object is using the field. In other words, you should not use different non-organizational fields in combination with derived roles as the values across all child roles will always be the same as the master role and will affect all objects.

Composite Roles

A composite role is a collection of single roles that you can group into a common composite role menu. As a result, you can indirectly assign multiple single roles to a user by assigning only the composite role that contains the single roles. That makes the temptation greater to build smaller single roles without considering required user assignments while building them.

Many SAP customers leverage composite roles to reduce the number of single roles that are assigned directly to users. However, this often leads to less transparency, a higher effort of maintaining more roles and an increased risk of cross-pollination from one single to multiple of composite roles. With composite roles, the ability to change the single roles rapidly reduces and as a side effect you have more single roles. 

Technically, a composite role is a bundling of single roles to map a task level single role, or in worst-case, a single role per transaction to a composite role. The aim is that the assignment to the user can be a functional unit or position in the organizational structure. In addition to the number of single roles which result from this, the organizational structure and its changes also play a role in the choice of concept.

Enabler Roles

In recent years, we have seen role concepts that break the SAP standard. These concepts are often called enabler or value role concepts. In these concepts, you separate the organizational authorization values from its functional authorizations. As a result, users need two roles to successfully execute a transaction.

In these concepts, the functional role gets all the authorization objects and values, but not the organizational values. An additional enabler role that contains the “missing” organizational values completes the users’ authorization.

The driver behind enabler roles is mostly the belief to isolate the organizational fields and simplify the user assignments when it comes to organizational distinction.

However, any organizational type of field, which also has an “activity” field in the same authorization object, cannot be separated and put into a different role.

That is almost always the case in SAP authorization objects. Because of this absolute disadvantage, enabler roles cannot work as they are sometimes described. The typical result is a proliferation of the authorizations in the enabler roles and the number of enabler roles, which often exceeds the number of users.

An enabler role concept sometimes looks tempting on PowerPoint presentations, and some customers might expect enabler roles to behave similarly to the organizational management in the HCM module. However, you cannot apply it to authorization objects and role-based authorization concepts nor to the modern menu based visibility access concepts such as Fiori applications and Portals / BW reporting.

Comparison of different role design concepts

The following table gives a detailed overview of the pros and cons of each role design concept. The table is a product of years of experience and best-practice by SAP Consulting. The traffic lights show how well each concept supports the listed requirements. (●) means well-supported, (●) means partly-supported, (●) means not supported, and (●) means not applicable.

As you can see, single roles (with optional derivation) are considered best-practice for SAP roles designs. They offer the greatest flexibility, transparency and broadest support of requirements and changes with upgrades. On the other side of the spectrum, we have enabler roles, which are the least flexible and have several design and maintenance disadvantages.

Why not use Enabler Roles?

An enabler role concept is a non-standard approach to role design. Its origin often comes from the assumption that it is not possible to create a role which can display all items but only change a subset. Technically, this is because an authorization object with two or more fields will check all of them and require that they are present in the same role authorization.

Let’s have a look at a simple example of an enabler role for transaction FK03 – Display Vendors.

The transactional single role contains transaction FK03 with all its authorization objects and values. The organizational level (BUKRS in this example) for object F_LFA1_BUK remains empty.

A second role, the so-called enabler role, contains the organizational values for object F_LFA1_BUK only.

In the user buffer (transaction SU56), we can see the two authorization profiles assigned to the user.

We learn that the two authorizations are in different authorization profiles. Each time the SAP Kernel performs an authority check, it checks the values in one authorization profile. Let’s see if FK03 works for the user who has both roles assigned.

The user can successfully execute the transaction but is unable to view vendors in company code 0001, even though the enabler role contains the company code. However, since the SAP Kernel checks the activity and the company code in the same authorization profile, the authorization check is unsuccessful. Therefore, it is not possible to have the activity in one role and the organizational field in another and expect that the check will be successful as a whole.

Issues with Enabler Roles

This type of enabler role design also leads to several other issues:

• You are breaking with the SAP standard. SU24 proposes mandatory authorization objects to PFCG. Breaking this standard and manually inserting objects will impact upgrades, security patches, complexity, where-used-list reporting, etc.
• With enabler roles, role administrators have to use manually inserted objects instead of relying on solid SU24 proposals for the activity type of fields. However, applications need SU24 proposals, and they are visible in the user’s menu. Over time when the role requirements change, this typically leads to obsolete authorization values and a mess which no longer matches their original intention to “enabler” the transaction.
• Post maintenance of roles is typically more labor intensive as opposed to a derived role design due to the lack of automation. The number of enabler roles explodes such that there are more roles than what there are users in the system.
• You cannot run a segregation of duties (SoD) analysis on role level as most available tools (e.g., SAP Access Control (GRC)) check on TCODE and AUTH object level. If the transactions, activities and organizational authorizations objects are separated, you would need to simulate the correct pairing of roles to have the full set of authorizations that is going to be assigned to a user. Please note, that SoD conflicts matter the most when assigned to a user. At this point, enabler role concepts are tempted to additionally use composite roles for the assignments, in this way bringing in the additional disadvantages of composite roles on top of the enabler roles.
• It increases the complexity of role mining during the user provisioning process. For a requestor who has to request access, finding two roles is significantly harder than finding one. Especially when using tools like SAP Identity Management (IDM) or SAP Access Control (GRC), as it forces the requestor to not only understand the concept but also to identify and find the matching pair of roles.
• Role testing becomes exponentially harder as it requires one to test a pair of roles. That is especially true if the organizational structure changes and the testing roles must reflect the changes.

Most of these issues arise because of missing SU24 content to what the application needs. Over time and by necessity, the manually inserted authorization objects become obsolete, wrong and over-authorize a user. Since manually inserted objects are not attached to a transaction, there is no identification to which transaction they belong. Also, you don’t know why they were added to the enabler role in the first place. This results in a nightmare to maintain and upgrade the roles in the long run.

If you use composite roles additionally for user assignments, then a cascading of the problem occurs. This results in nearly impossible maintenance of the enabler roles – so the administrators typically create more new enabler roles.

What impact does a system upgrade have on my roles and authorizations?

Due to new requirements and improvement, system landscapes change over time. Nowadays many customers are planning to migrate to S/4HANA. Others are upgrading to the latest enhancement packages (EHP). Every upgrade comes with new and enhanced authorizations and requires roles to be adjusted accordingly. When implementing new value proposals via SU25 into SU24, you need to update your roles to include the latest changes. When using fewer single roles which are closer to job functions, the SU24 upgrade and impact analysis on the roles can be performed without any problems. For instance, a standard transaction gets a new organizational object that is required to use the transaction successfully. When performing SU25 and upgrading your roles from SU24, the role will get the new organizational object proposals automatically. Also, the roles carry the where-used-list of an authorization object. This is especially important when performing SoD remediation tasks as it shows you which authorization object belongs to which transaction. Not having the where-used-list lets you only guess to which transaction the authorization object belongs.

However, if you are using enabler roles, that can be a formidable task as you have no where-used-list references. In addition, you typically have at least 100 times more roles than you need.

Conclusion

Xiting has implemented authorization concepts of all sizes and complexity around the world. These are typically re-implementations combined with upgrades to SAP S/4HANA systems. The information shared in this article stems from the experience of executing such projects and best practices.

Julius von den Bussche, Director SAP Security at Xiting, SAP Community Moderator and SAP Mentor alumni, said: “Historically SAP authorizations is a troublesome topic as the decision makers were far away from the administrators at the time and the consultants are typically gone after the implementation. Implementing a simplified single role concept with fewer roles is easily maintainable, easily upgradable and easily extendable to new organizational requirements and technology changes. The Xiting Authorizations Management Suite (XAMS) also offers a migration tool for such single roles to convert them to SAP S/4HANA compatible roles with a minimal effort in administration and testing. Xiting also offers attractive operations support for security, if the concept to be supported was implemented in a best practice approach with XAMS.”