Simplify testing of new roles

Testing new roles without providing extra resources and without interrupting the daily business? Yes! That´s possible with the productive test simulation (pTs) and its ability to simplify testing of new roles.

We all know what steps are required after building new roles. The newly created roles need to be tested thoroughly from a technical but also from a functional point of view. This also means – for better or for worse – that employees waste valuable time to do role testing in a quality system. Until now, there was no alternative to avoid testing in a quality system. Even though role testing is important for the role administrator to have stable roles, mostly testing is underestimated and not properly done by business people. That’s due to lack of time, as well as end-to-end testing requires more than an individual to thoroughly execute a process.

To wrap it up, testing does not only bother business and doesn’t add value, it also requires coordination effort and large communications if tests fail. Xiting Authorizations Management Suite (XAMS) with the help of the productive test simulation (pTs) changes that completely.

pTs enables testing new roles directly in the productive system without interfering business processes or providing extra resources. Business does not have to interrupt their work for testing, and they do not need a separate testing environment – daily business continues. Furthermore, it allows maintaining missing authorizations in the SU24 comfortably which reduces the effort of the role administrator.

Project Timeline with and without pTs

Testing roles in the productive system without process interruption also means a lot of time-saving. See a typical project break-down as follows:

The icon () means working manually without XAMS and pTs.

In the picture below you can see our approach in redesign projects. We create roles virtually within the Role Designer (stage: Role Design) and assign those created roles to a reference user to start the productive test simulation. Role assignments are only changed in the reference user; the “real” user remains untouched. The reference user then gets assigned to the “real” user to simulate the new roles.

pTs uses the reference user concept as authorization checks are always performed against the reference user first. If an authorization check fails for the reference user, SAP checks the authorization from the “real” users’ context. A reference user (user type: Reference) is a non-personal user that can be attached to another user to grant additional authorizations. To perform the productive test simulation the newly created roles are assigned to the reference user.

Once assigned, the reference user has the new roles and is strapped like a backpack to the dialog user. In doing so, the “real” user still keeps his role assignments but also gets the newly created roles indirectly from the reference user.

How does it work?

XAMS identifies whether the authorization check against the reference user was successful or not. If the authorization check fails against the reference user but succeeds against the “real” user, that means that the newly created roles lack authorizations that are required to successfully perform an activity. In the end, the role administrator sees precisely which object, which field and which value are missing in the new role and has the ability to add automatically to SU24.

The productive test simulation is an integrative process that takes place between the tools Xiting Times and the Role Builder.

You can see Xiting Times acts as a sessions manager, where you can start and stop the pTs for a large number of dialog users. When a session is activated for a dialog user, the “backpack” is strapped on the dialog user technically via an entry in SU01. You can check that from the Roles tab in SU01 of the dialog user, as follows:

After starting the PTS for the dialog user FI_DB_4,  you can see its reference user is added in the role tab of the dialog user.

What does the Role builder do?

The Role Builder helps authorization administrators analyze what authorizations are missing in the new role. The Role Builder Analyzer allows us to view the missing authorization values in a clear and precise report.

The execution of FB03 was successful, even though the new role didn´t contain those Objects and values. The dialog user FI_DB_4 could execute activity 03 for company code 0001 in the context of FB03 because the required authorizations were containing in the old role. That is indicated by the return code “0”. Return code “0” represents all the authorizations that are missing in the new role.

Return code higher than “0” (1 or 3) means that the authorizations hadn´t been in the old role either. Simply said, the dialog user FI_DB_4 tried executing a transaction that he wasn´t authorized for before.

When the employee calls a critical transaction, the entry is highlighted in red. All the critical transactions (SE16, SU01, PFCG, etc.) are added to a blacklist to raise more sensitivity for critical objects.

To sum up: the dialog user is doing his regular job as usually and doesn´t even notice the testing that is running parallel in the productive system. After the session, the protocol data (return code “0”) show us which authorizations are missing in the new role. If the missing authorization is critical, it is highlighted in red.

The Checkman

Another great aspect of the Role Builder is its Checkman. With the Checkman you can globally maintain authorizations in the context of a transaction in SU24.

About SU24: SU24 is the most important transaction in the field of SAP Security. Maintaining SU24 entries is a recommended best practice by SAP. In the long run, the traceability is guaranteed by the maintenance of SU24. If you don´t maintain the SU24, there won´t be a connection between the transactions a user has and the authorizations objects in the assigned roles. So, it won´t be possible to know why a critical object was assigned to a role.

Proof is required to show why certain critical authorization objects are assigned to roles. This proof, on object level, is not possible without the maintenance of SU24. See also the blog about SU24 Optimization.

The Checkman reports as follows:

In the picture above you can see that in the context of the transaction FB03 activity (03) display is missing. If FB03 was assigned to a role you would have to add the activity 03 in the object F_FAGL_LDR. Otherwise, the display transaction wouldn´t answer its display purpose.

When you maintain those values for transaction FB03 in SU24, they will be brought in automatically as soon as you add FB03 to the role. So you will save a lot of work and effort. In the Checkman you don´t need to open a new modus and switch to SU24 where you can maintain the values. By clicking on the blue arrow, you can maintain the missing values automatically in SU24.

Conclusion

The following advantages you gain with XAMS:

• Testing is performed in parallel to productive operation without process interruption all while providing better testing results
• Newly created roles are automatically tested in the background
• Faster turnaround times for redesign projects
• Simple and clear evaluation of the simulated test data
• Direct maintenance of the SU24 with appropriate suggested values from the test data
• Compliance with blacklist requirements
• Suggestions for missing authorizations by Whitelist function