There are many creative ways, in addition to the standard SAP, to manage authorizations. 

Let us begin by saying what is the only recommended way. Authorization control using the statement ABAP AUTHORITY-CHECK.

What are other ways to manage SAP authorization controls? More importantly, why shouldn’t you use them? 

Support tables that govern who can do what 

Among the bad practices the method definitely most used is to create a custom table where users are inserted. 

Technically, in the program code (related to the SAP transaction) a user presence check is inserted (often in addition to certain other conditions) in the defined custom table, so that it is possible to continue. 

But why is this not right and what risks does it entail? 

• Each custom development has a cost (of creation and, above all, of management)
• There is  a standard way, the use of authorization controls (Authority-Check) why not use it? Eventually defining a custom authorization object 
• During troubleshooting it is not possible to use the standard debug or trace authorization tools as they are not useful 
• Who knows that process is certainly autonomous but a new resource that takes over or entrust its management to third parties may struggle to trace back to management.  Especially if there are many such cases. 
• If I delete an account, will the table be cleaned? 
• If a user moves from one direction to another? Is its user removed from the table? Or does it still fit?  
• Is there a custom table history? To find out who did what? 
• Is the table protected by an ad hoc authorization group?
• Is the table centrally managed by IT or is the maintenance directly delegated to the relevant departments? 
• IT maintenance often directly to functional applications, not to Security personnel n
• IT might lose control of that process if delegated to business over time 
• You are thinking of a system of identity Management or SAP GRC Access Control in the Access Request Management module. These systems do not support provisioning these additional custom tables. 

Which are therefore the advantages of using custom tables for authorization control?

How much does the conversion of these authorization models cost? 

Unfortunately, there is no unambiguous answer, depends on how much these situations are present in the processes.

For a few cases it can be relatively simple, for many even impossible.

Use of wired code roles

Not so common but still possible today. The insertion objects' technical names of objects into the ABAP code. 

For example: if the user has assigned at that time (maybe without even checking the validity of the attribution) a certain role (technical name) then you can perform a certain operation.

• It is never recommended to enter name/string at code level
• In case of removal or renaming of the role would serve to revise the code ABAP developed
• Also in this case, as in the previous standard, debugging tools would not help.

Use of hard coded userid

Similar to the previous one but this time directly on the technical user. If I am using a certain user, then I will be able to perform a certain operation. 

Bypass of authorization checks

What does it means? Here is a real scenario 

The user must run a certain functionality in background mode. During the submission of the activity the user is replaces by the program with a technical user.

The result is that a technical user is used to carry out a certain activity rather than the user of the person who actually carried out the operation.

In the case of accounting records, for example?

How can you discriminate if it is an action actually carried out by technical users or made by real users through technical users? During an audit this could be very important. 

A specific audit at the level of developed ABAP programs can bring out the above case studied.

Blog post originally translated from: https://www.aglea.com/blog/autorizzazioni-sap-10-cose-da-non-fare