SAP authorization testing with reference users

MateM · ‎01-05-2023

1 Use-case

This methodology is especially useful to perform SAP role redesign (small or large scale) where you choose to implement new SAP role(s) for your productive SAP entity, to replace an existing role concept with a new improved role concept and you are looking for a high-quality authorization testing strategy that will require low involvement of business users.

This methodology works well from basis release 7.4 onwards and is also useful if you would like to reduce wide access (like SAP_ALL) from system (or other technical) users and you choose to implement new role(s).

This methodology is not useful:

if you change an existing SAP role that is already assigned to users in your productive system

if you are running an SAP roll-out project (the new SAP entity is not yet in use in the productive system).

Prerequisites:

Your internal controls/ compliance team agrees to transport newly created SAP role(s) all the way to the productive system. This testing methodology is executed directly in production. At a first glance, this sounds risky, however, the risk of granting inappropriate access during the testing phase can be mitigated by various pre-checks.

Critical and/or unnecessary authorizations must not be added to your newly created roles. I guess if you are looking for a methodology like this you are already aware of a bunch of those. (If you use GRC -AC then you should be able to run a risk analysis on the newly created roles already in the development system and you can make sure that you only transport risk-free roles to production)

You have the STUSERTRACE (long-term trace) transaction available in your SAP system and you know how to use it. (This transaction is very well documented so you can easily get your head around it)

2 Summary of the methodology

The process steps are the following:

Design/ Implementation: create the new SAP role(s) as usual and transport them all the way to the productive system

Testing prep:
1. create reference user(s) (user type L) and assign the reference user to the “normal” SAP user ID(s)
2. assign the new role(s) to the reference user
3. set up a long-term trace for the “normal” user(s) (STUSERTRACE)

Testing: Analyze STUSERTRACE results and apply corrections

Go live (switch the roles of the reference user and the regular SAP user ID and remove the reference user)

Hyper care (in case something goes wrong for any reason you can still add back the reference user and analyze the root cause without stress)

Closure – remove the “old” roles and the reference users as necessary

Figure - 1 (picture was made by me)

Using this methodology, you can achieve very good test results for potential authorization issues without the user(s) even knowing that they are testing, and because everything is happening in the productive system this is real end-to-end, in-depth testing, and it does not require extra effort from the business.

3 Detailed explanation

3.1 Set up reference users

Once you are done with the role implementation in your development system and transported all the newly created roles to your productive system, you will need to continue creating users with user type “L- Reference”. Depending on the scenario you might need to create one dedicated reference user for each regular user, but it is also possible to assign the same reference user to multiple regular user IDs.

Figure - 2 (picture was taken by me)

It is not possible to log in with the reference user itself, so this does not mean that the “normal” users will have 2 user IDs. This is a technical user type that can only be assigned to the regular SAP user ID.

Luckily this has no impact on your license cost because the reference users are normally not counted by SLAW2 but better to be double-checked just to avoid any surprises.

3.2 Add reference users to regular SAP user IDs

You need to add the reference user to the regular user on the “Roles” tab in SU01/SU10:

Figure - 3 (picture was taken by me)

There is an entry in the PRGN_CUST table (REF_USER_CHECK) that controls the system behavior when you are trying to assign a user ID here which is not “L – Reference” type.

Figure - 4 (picture was taken by me)

In case you are using central user administration (CUA) then you will need to create the reference user(s) in all systems where the regular user is created, otherwise, the user segment of the USERCLONE idoc will fail for those systems where the regular user ID is created but the reference user not.

If you are using an SAP system under basis release 7.50 then the maximum number of profiles that can be assigned to a user is 312. The reference user does not have an effect on this limit meaning the regular user has a threshold of 312 and the reference user also have its own threshold of the same size.

3.3 Set up long-term authorization trace (STUSERTRACE)

One of the key elements of this testing methodology if you have the STUSERTRACE transaction code in your SAP system.

This transaction code is well documented in SAP and also there are good blog posts about it on SCN, for example, https://blogs.sap.com/2021/09/20/stusertrace-new-tracing-option-authorization-trace-for-user/

STUSERTRACE is collecting the data into a dedicated SAP table: (SUAUTHVALTRC) which sometimes makes the analysis easier and while you are running STUSERTRACE you still can use ST01 or STAUTHTRACE as usual.

To sum up:

you have created reference user(s) and assigned them to the regular SAP user ID

you assigned the new roles to the reference users

you have activated the long-term trace and set up the filter for the regular user IDs

At this point, you basically started the testing. You need to start the process of analyzing the trace results. In the authorization trace, you will see whether an authorization check was successful via the reference user or via the normal user or if it was not successful at all.

Figure - 5 (picture was taken by me)

The reason why this methodology works well is that SAP authorizations are checked in sequence. First, the system checks if the reference user has the right authorization if not, then the system checks if the regular SAP user has the necessary authorization, this is why you needed to add the new roles to the reference users and keep the old roles for the regular SAP user ID. So basically, in this way you can run a “what-if” analysis regarding what would happen if the regular user had the new roles only.

Figure - 6 (picture was taken by me)

3.4 Analyze results and fix issues

This is a bit weird but in this case, the lines which could be potential issues in STUSERTRACE are the ones that are successful without additional information (please see Figure - 5), because these authorization checks were successful with the authorizations of the regular user, so that is something which is missing from your new roles. Some of these values could be missing on purpose, therefore, those will be false-positive, this is something that requires careful analysis.

The lines which are successful with the additional information “Authorized Through Reference User” are those authorization checks which will be successful with your new roles.

The lines where the authorization check failed (either RC = 4 or 12) are cases where the access was already missing from the regular user (therefore from your "old" role) too.

You can run the analysis as long as you feel confident that there are no issues left. The main advantage is that the business users will not notice any difference, they are doing their day-to-day job just like before and you will get a very detailed in-depth testing result.

Once again just to state the obvious: it is important that not all failed authorization checks are issues, and not all passed authorization checks are OK, so when you apply this technical methodology, you need to know what you are doing.

4 A few drawbacks

This is a technical approach to authorization testing and even if it has some major benefits (high testing quality and low business involvement) there are also a few drawbacks:

You cannot apply this methodology for roles that are already assigned to users in your productive system and you cannot apply this methodology for entities which not yet live in your productive system.

You need to transport new roles all the way to prod. In some cases, this might not be possible, however, it worth a try to convince your internal controls team 😊

There are a few things that are not “added” from the reference user
This methodology is useful for testing ABAP authorizations, so any other element of your “old” role (for example role menu for Fiori or NWBC, role technical name-based workflow, or other bespoke implementations which are depending on the role technical name) might not be tested with this methodology
Also, you might not be able to test the access aspects related to user parameters and other user master data-related settings.

According to the documentation, a maximum of 1000 users can be traced at the time without performance impact. This number might be too low depending on the scale of your testing.

Technical issues: I did not face any technical issues however, I found some blog posts on SCN and a few SAP support notes, about the STUSERTRACE transaction and the authorization checks of the reference users. These most likely have been fixed by the later support packages, but you might check what is your SAP version/ release and you start with some investigation first.

5 Conclusion

Even if this methodology is quite technical and requires a bit more preparation than a usual test approach, I personally found it useful and effective. After a 3 month testing, while I only used this methodology there were only a very few minor issues after go-live.

Please ask/ answer SAP Access Control related questions here:
https://answers.sap.com/tags/01200615320800000796

Please follow/ comment SAP Access Control related topics here:
https://blogs.sap.com/tags/01200615320800000796/

Please share below in the comment section your thoughts, and ideas on this blog post.