Restricting Access - Authorization Concept of the SAP NW AS 

Not every user is to be able to execute all functions, nor is everybody to be able to see or change any data on the database. Therefore, it is necessary to restrict access to data. The SAP NW Application Server does not use the authorization checks of the database for this. An SQL command in an ABAP program does not trigger an authorization check in the database system and you can thus, in principle, access any data on the database using Open SQL or Native SQL statements.

The SAP NW Application Server has its own technique for ensuring that you can restrict access to data as required. This is necessary firstly because the entire SAP Application Server works on the database with a single user. Secondly, the granularity of the mechanisms provided by the database is not fine enough for SAP requirements.

The basic concept in the SAP NW Application Server is that specific authorizations are assigned to users in their master data (transaction PFCG). In actual fact, authorizations are grouped into (composite) roles or profiles, which are then assigned to users, but that is irrelevant with regard to the basic concept.

In a program, you can then check whether a user has a specific authorization. If yes, the return code SY-SUBRC has the value 0, otherwise it does not. Authorizations are always instances of authorization objects. An authorization objects has up to 10 fields and serves as a template for the possible instances and combinations of the relevant authorizations. The large number of authorization fields is required so that authorizations can be instantiated with very fine granularity. For example, a user is to be able to see all data for Lufthansa flights, but not that of any other airlines, while another user is able to change the data. You create authorization objects in transaction SU21 after creating reusable authorization fields in transaction SU20.

In general, you enter a Dictionary reference for the authorization field input help. For example, if you use the Dictionary table T001 for a company code field, this ensures that only valid company codes are suggested as possible values when managing authorizations.

The same applies to authorizations or authorization objects and their fields. Note that the sole purpose of the used Dictionary objects is to ensure the fine granularity of the check and to specify what is to be checked and thus happen in the program if the check is successful.

The authorization check for fields of the table SPFLI, for instance, knows nothing about what happens in the program after a successful check. As a programmer, you must make sure that what happens in a program after an authorization check is precisely what was queried in the check. There is no automatic procedure in a program that checks, for example, that no MM data is displayed after a CO object query in your program. However, there is also no mechanism to prevent you naming a program for customer display “Schedule Creation”, for example.

Authorizations are comparable to keys that are assigned to users. There are locks at specific points in the program, and only users with the correct keys can open these. The key types – such as car, house, or bicycle keys – correspond to the various authorization objects, while individual keys correspond to the different authorizations, the position of the notches on the keys to the fields of the authorization objects, and the form of the notches to the field values. A bunch of keys is comparable to a role.

Since authorization checks can be very complex, it is a good idea to encapsulate them away from application programmers. For example, you could store your SQL query in a method, which in turn calls a further method that executes an authorization check before the actual SQL call takes place. In this case however, the programmer of the method that checks the authorization and the developer of the database query have to work together closely.

As described above, you can only check authorizations properly if you know what is to happen in the program in the case of a successful or failed check. With regard to the creation of a program, we now turn to the important question of what happens if the check fails. If you incorporate authorization checks in a program, the reaction to a successful check is generally already clear. However, you still have to consider how the program is to respond if the authorization check should fail. In such cases, the program could display and error message or write a log. Another option is to make a specific function – for example, displaying detailed data – unavailable to the user and to do so without comment.

You should also take into account that it is better to include your authorization check as early as possible in the program flow, both for performance and usability reasons. For example, it would be pointless to carry out a range of preparations for an SQL query if the user has no authorization for this query anyway. A good way of dealing with cases like this is to not display specific buttons or menu entries for users without the relevant authorization.