SAP Table Authorization

 

This post deals with detailed discussion on the concept of sap table authorization.

Tables store data. The data can be client specific data or cross client data.

It is necessary to know the meaning of client for understand the meaning of client specific and cross client data.

 

 

We have already discussed about the concept of client in one of our previous posts. Repeating the definition of client again – A client is an independent accountable entity within R/3 system. It can represent a company or a business unit. It has its own master data and transaction data and user master records (client specific data).

 

A client is always represented by a three digit number. SAP R/3 comes in built with three standard clients , i.e. 000, 001 and 066. Since a client is always a three digit number, an SAP System can have a maximum of 1000 clients (from 000 to 999). Out of these, a maximum of 997 clients can be customer specific clients and 3 (i.e. 000, 001 and 066) are SAP standard clients.

 

 

Data is stored in SAP database tables. This data is grouped based on clients. Client specific data, as the name suggests, is the data which is client dependent. Data specific to a particular client cannot be seen from other clients. Tables which contain client specific data have a field called client (MANDT). This MANDT field contain the client number. If the same table is viewed from other client, the MANDT will contain the three digit client number of that particular client and the data for that client.

Cross client data is that data which can be accessed from all clients. This is also called client independent data, which means that if a data in a table can be accessed from a client, say client 100, then the same data can be accessed from any other client (say client 200) also.

 

 

Now when we have discussed tables and data, the question arises as to how to access this data? What authorization is required for accessing any table data?

Tcode SE16 (Data browser) can be used for accessing table. But will just having access to transaction code SE16 or SM30 (Call View Maintenance) gives the authorization to access any table?

 

 

There are some authorization objects for securing tables. In this post we are going to discuss about the most important of all those authorization objects –  authorization object S_TABU_DIS. There are a few more authorization objects for tables which we would be discussing in our next post.

 

But before that lets understand a very important technical concept called “table authorization group” which plays the most important part for authorization to any table.

 

Table Authorization group allows us to secure access to tables in SAP. Authorization group (BRGRU) is represented by the authorization field DICBERCLS and is a part of authorization object S_TABU_DIS.

 

For a table to be secured, it should be linked to an authorization group. An authorization group can be created via transaction code SE54. The maximum length of a table authorization group is 4 characters.

 

The initial screen of SE54 is as below:

 

 

A table can be linked to an existing authorization group or a new authorization group can be created. Both creation of a new authorization group and linking of the table can be done via tcode SE54.

 

One table can be linked (assigned) to only one authorization group. But one authorization group can be linked to more than one tables.

 

So, when a user gets access to any authorization group, he can access all those tables that are linked to that authorization group (assuming there is no dependency on any other authorization object for any table/tables).

 

Now let us discuss about the authorization object for securing tables. In this post we are going to discuss about authorization object S_TABU_DIS.

 

Authorization Object S_TABU_DIS has two authorization fields :

  • Authorization Group (DICBERCLS)
  • Activity (ACTVT)

 

Permitted values for ACTVT (activity) are 02 (change) and 03 (display).

 

Let us take an example. Suppose there is a table authorization group Z123 and suppose 5 tables are linked to Z123.

Let us assume that the user has following access in his user master record:

Authorization object S_TABU_DIS

  • ACTVT (Activity) – 03
  • DICBERCLS (Authorization Group) – Z123

From the above access user should be able to display the 5 tables which are linked to Z123.

Here it is assumed that the user has access to table browsing tcodes like SE16 or SM30 or any parameter tcode for accessing the table. Also, there should not be additional condition like tables being cross client or restriction based on table name etc. All these restrictions are handled via other authorization objects which we would be discussing in our next post.

 

 

A few questions that need to be addressed:

 

How do we find out what all tables are linked to a particular authorization group?

Table TDDAT can be used for that purpose. It provides the list of tables which are linked to an authorization group. It can also be used for finding the authorization group for a particular table.

 

Where do we find list of all table authorization groups?

Table TBRG contains the table authorization groups.

 

 

 

Comments are closed.

Leave a Comment


*