When Should You Use Enabler Roles in SAP?

The enabler role concept is a non-standard approach to role design. Its origins are based on the assumption that you cannot create a role that can display all items but only change a subset.

Technically, this impossibility 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.

This blog post describes a simple example of an enabler role for Transaction FK03 (Display Vendors) in SAP. The single role contains the transaction (a transactional single role), and another single role contains the organizational values (the enabler role).

The transactional single role contains Transaction FK03 with all its authorization objects and values, as shown in the figure below. The organizational level (BUKRS in this example) for object F_LFA1_BUK is left empty, or the authorization object is deactivated.

A second role, the enabler role, contains the organizational values for authorization object F_LFA1_BUK only, as shown below. No other authorizations—other than the objects with organizational values—are maintained in this enabler role.

When the two roles are assigned to a user, you can check the user buffer to see the totality of assigned authorizations. In the user buffer (Transaction SU56), shown below, you’ll see the two authorization profiles assigned to the user, with two instances of the authorization object F_LFA1_BUK Notice how the ACTVT value 03 comes from the transactional single role, but the company code comes from the enabler role.

Since the two authorizations are in different authorization profiles, the authorization check does not succeed. This failure is because, when the kernel performs an authority check, it checks the values of one authorization instance. As shown in the following figure, the user can still successfully launch Transaction FK03 but is missing the authorization for company code 0001.

At this point, the user can successfully execute the transaction but cannot view vendors in company code 0001, even though the enabler role contains the company code. Since the kernel checks the activity and the company code in the same authorization instance, the authorization check was unsuccessful. Therefore, you cannot have activity in one role and the organizational field in another and expect that the check will be successful as a whole.

To counter this issue, you must authorize your enabler roles with the activity fields that control the company code. In this particular case, you must ensure that authorization object F_LFA1_BUK is restricted to display access (ACTVT = 03) because, otherwise, you’ll overauthorize these users. This potential issue is a main concern when using enabler roles since your enablers tend to carry far-reaching authorizations that may cause critical access and SoD conflicts.

Another downside to this approach is the fact that, in typical enabler concepts, the enabler roles contain almost every authorization object that has organizational fields. Since many critical business authorization objects within SAP contain organizational fields, often all these fields are added to the enabler role, since the goal of the enabler concept is to keep the number of enablers low.

In addition to this complexity, enabler role designs can also lead to several other issues, such as the following:

• You’re breaking with the SAP standard. Transaction SU24 is used to propose required authorization objects into Transaction PFCG. Breaking this standard and manually inserting objects will impact upgrades, security patches, complexity, where-used list reporting, and more.
• You must use manually inserted objects with enabler roles instead of relying on solid Transaction SU24 proposals for the activity type of fields. As a result, authorization objects and values in the role profiler are not related to an application. You cannot use the where-used list to see why the authorization object was added in the first place. Over time, as role requirements change, typically obsolete authorization values become a mess that no longer matches their original intention to “enable” the transaction.
• Maintenance of roles after creation is typically more labor intensive than a derived role design due to the lack of automation. The number of enabler roles can explode such that there are more roles than there are users in the system.
• You cannot run SoD analysis on the role level with governance, risk, and compliance (GRC) tools like SAP Access Control or check on S_TCODE and the related authorizations of other objects. If transactions, activities, and organizational authorization objects are separated, you would need to simulate the correct pairing of roles to have the full set of authorizations 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 use composite roles for role assignments, in this way adding the additional disadvantages of composite roles on top of enabler roles.
• Enabler role designs increase 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 (SAP ID Management) or SAP Access Control, a requestor must both understand the concept as well as identify and find matching pairs of roles.
• Role testing becomes exponentially more complex since you’ll need to test pairs of roles. This effort continues to be required as an organizational structure changes and roles must be tested again to ensure they reflect these changes.

Most of these issues arise because of missing Transaction SU24 content for what the application needs. Over time and by necessity, manually inserted authorization objects become obsolete, become incorrect, and overauthorize users. Since manually inserted objects are not attached to a transaction, no easy way exists to identify to which transaction they belong and why they were added to the enabler role in the first place. In the long run, maintaining and upgrading these roles is a nightmare.

If composite roles are additionally used for user assignments, then a cascading problem occurs, and changing an enabler role is nearly impossible—thus, administrators typically must create more new enabler roles to compensate.

Editor’s note: This post has been adapted from a section of the book Authorizations in SAP S/4HANA and SAP Fiori by Alessandro Banzer and Alexander Sambill.