If your organization has run an SAP system for three years or more, you probably suffer from what we like to refer to as “Deceiving Authorization Roles syndrome.”
Whether you’re familiar with this pesky problem or not, maintaining authorization roles for a few years, adding and removing activities and authorization objects, and creating new ones and deleting others all create situations in which authorization roles have names that incorrectly represent their content. This can lead to SAP admins unintentionally granting users with the wrong authorizations.
What Are Deceiving Authorization Roles?
The term “deceiving authorization role” describes an authorization role that possesses a name or description that incorrectly describes its content.
This situation is often caused by human error, due to the difficulties of maintaining authorization roles and attempting to oversimplify them. Oftentimes, the most efficient way to solve an authorization requirement is to add it to a role, without taking into account (or ignoring the fact) that its name does not reflect the new addition.
Examples of deceiving authorization roles in SAP include roles titled “VIEW” with authorization objects that allow “Change” or “Create” (ACTVT = 01, 02) and authorization roles with the description “Finance – handle assets” with T-Codes from logistics modules such as MM01.
In the image: T-Code PFCG displaying a “View” type rolw with an Authorization object that includes a “Change” activity
What Risks Do Deceiving Authorization Roles Pose to Your Organization?
The risk with deceiving authorization roles is clear: granting users with incorrect authorizations results in a massive security breach.
Let’s take an example in which the authorization role HR_VIEW_INFOTYPE_0002 accidently includes an authorization of type “Change”. If a user requires an authorization role to view employees’ personal information, for example, he is generally assigned the HR_VIEW_INFOTYPE_0002 role. With this role, he is also granted the ability to change employee data, resulting in unnecessary sensitive authorizations and making him a prime target for hacker hijacking in the future.
Furthermore, your organization will find itself facing some angry faces once this information is discovered during an audit, when it has to explain why there are “Change” permissions in “View” authorization roles.
Can Your Organization Prevent the Creation of Deceiving Authorization Roles?
This is a tricky question. Theoretically, your organization can avoid creating deceiving authorization roles by putting the proper policies in place and adding additional people into the process of changing authorization roles.
You might think that if more eyes see any changes before roles go to production, this will eliminate the chance for error. From our experience, this does not prevent errors and only lengthens the process.
In our experience, even the most organized companies have deceiving authorization roles in their role catalog. It’s only human nature to make mistakes – especially during the long lifecycle of authorization roles, where people get replaced and policies change. These factors make it easy to accidentally create deceiving authorization roles and result in the need for action to periodically locate and eliminate them.
How Can Your Organization Effectively Handle Deceiving Authorization Roles?
First, you’ll need to locate deceiving authorization roles and subsequently handle each one. Surprisingly, the first part is harder than the latter. When you find a deceiving authorization role, handling it is a simple task– but finding it between thousands or tens of thousands of roles can be like finding a needle in a haystack.
Start by using the following searches:
1. Roles with names that include the words ’VIEW’ or ’DISPLAY.’ You can do this by using T-Code ‘SUIM’ or by searching in table ‘AGR_DEFINE’ field ‘AGR_NAME’ using T-Code ‘SE16.’
2. Roles with descriptions that include the terms ‘VIEW,’ ‘DISPLAY,’ ‘DISPLAYING,’ etc.
3. Roles with names that include the terms “TEMP” and “TIMELY,” meaning they are temporary roles that, in most cases, shouldn’t get to the production environment.
The image above shows how to use T-Code SUIM to search for “display” roles
You’ll have to be cleverer to locate roles from “FINANCE,” which include T-Codes from non-finance modules, and roles with more than 90% T-Codes from one module and a few “sneaky” T-Codes from another module.
For these kinds of queries, you’ll need a software tool such as ProfileTailor Dynamics that can examine each role and perform a detailed analysis. Click here for a free demo.
Additionally, if your company includes organization objects in the role’s name, such as adding company codes to derived roles’ names – for example, Z_MM_PURCHASING_1100 (company code 1100) – this is a good place to find deceiving situations of included company codes inside. In this case, you’ll also need to rely on an intelligent software tool such as ProfileTailor Dynamics. Click here for a free demo.
What to Do with Deceiving Authorization Roles After You Find Them
Found some deceiving authorization roles? You now need to handle them individually. This is an easy task in most cases; however, it requires a few considerations.
If the role is ‘DISPLAY’,’ by name, but includes ‘CHANGE’ or ‘CREATE’ abilities: You should carefully examine the attached user accounts and determine what roles each account actually needs. If no accounts need the additional abilities, you can delete them from the authorization role. On the other hand, if some users do need the extra abilities, you can move the capability to another role. Whatever you decide, try not to leave the incorrect ‘DISPLAY’ title in an authorization role that includes other actions.
If a role is marked as ‘HR’ and includes financial T-codes, you should split it into two different roles or add users with the most appropriate authorization role from finance. Don’t forget to remove the financial T-codes from the HR role. To select the best option, you can also use “Role Replacer” in ProfileTailor Dynamics. Click here for a free demo.
Other situations, such as non-matching company codes or other organizational objects, should be solved individually, according to the situation and possible solutions.
Additional Examples of Deceiving Authorization Roles
Have additional examples of situations that result in deceiving authorization roles? We’d love to hear about them. Help the community and add your examples in the comments, below!