Do many days pass from the moment you create a new transaction to when the end user finally is executing it?

Something in the test creation and release processes may have not worked as it should have.

How can you avoid this?

The authorization model is not clear to the involved players

In the worst hypothesis when a new SAP transaction is created, the standard assignment process follows this path: "Assign this transaction to user John Smith"

The correct way of assigning a transaction should pass through the identification of a Professional Figure to which you should assign the new transaction. This figure should come up from an analysis carried out by the company organization.

The problem above is usually presented when it is not completely clear to whom one should assign a transaction and how. The most common path of action is for the IT to just decide where to "assign" the transaction.

Authorization tests are run using real people's users in a test environment

One of the first notions on SAP security is that authorizations are additive.

This means that if a user already has roles assigned to them (roles that contain authorizations), the addition of a new role to the user will only entail that they will obtain the authorizations they already have, plus the new ones.

So, where's the problem here?

If the transaction found in the new role needs an authorization object found in the other roles assigned to the user, the result of the test will be positive.

When a new role will be assigned alone to the user, the error will occur.

Incomplete tests may bring to business interruptions in the productive system and apparently random authorization errors even after the tests. This is also a collective waste of time (both internal and external to the company).

It's not clear who has to do what

During a new transaction release there are many involved players.

• Requester
• IT analyst
• Developer
• Security
• Tester
• IT group for transport management

An analysis document for every transaction should be released. There are however parts of the process that are not clear cut from a player to the other.

The most common ambiguous part is populating the SU24 fields. This transaction is essential to configuring SAP authorizations and allows one to link a transaction to authorization objects.

Ideally the developer fills this link, so whoever is creating the roles (after inserting the transaction) will also find all authorization objects linked to the transaction. This usually does not happen, leaving grey areas that are not attended to or managed, so that the above parts are wrongly managed contributing to the decay of the system.

Exhaustive tests are not carried out (partial test) or negative test is not made

A useful approach, even though more costly if ex-post, could be to run an authorization trace when it's not clear which checks happen in a transaction.

This makes it possible, if the transaction is used fully, to trace every authorization check that need to be managed.

It's important to test the transaction in a positive way (the transaction allows the user to do what he needs to) and negative way (the transaction stops the user from doing what he shouldn't be allowed to).

The use of administration functions

It may happen that the authorization error came from missing authorizations on system administration functions. Read here more on how to manage SAP developments.

When does this occur? For example, when someone creates a custom transaction that writes or displays files, or that sends calls towards other systems. In these cases, there are administrative functions that can be used to do what was mentioned above. For these occurrences, authorization objects from the SAP basis area will be maintained.

The solution here, when possible, is to modify the developed program, substituting the administrative functions with user functions or other solutions that avoid the use of such functions.

What is transaction SU53?

Transaction SU53 is useful to display the last authorization error in SAP. However, some transactions have many authorization objects inside of them. This may cause a discrepancy in which the last authorization error is not the one that if fixed will fix the problem (OSS Note 1525134).

With OSS Note 1671117 - SU53 Enhanced function and Web Dynpro suitability it's possible to display not only the last authorization error, but the last one hundred in the last three hours.

The result can be similar to the image below.

Read here to learn what to do in case of OSS Note problems (2219873)

Do you want to understand the SAP security management during the application maintenance system? (AMS Security SAP)

Blog post originally translated from: https://www.aglea.com/blog/su53-sap-perch%C3%A9-gli-errori-autorizzativi-non-finiscono-mai