In the previous post on SAP Table authorization we had discussed about client specific and cross client data. We also went through the concept of authorization group and how it is used in authorization object S_TABU_DIS. In this post we will discuss about some other authorization objects which are related to SAP table authorization.
During our discussion on authorization object S_TABU_DIS, we also saw that for someone to be able to access any table via table browser (SE16), he needs to have access to the correct table authorization group and activity. Authorization of S_TABU_DIS is sufficient in such cases where the table contains client specific data.
But what about such cases where table contains cross client data (client independent tables)?
For such cases, the user should have authorization to authorization object S_TABU_CLI (apart from S_TABU_DIS). The first check in case of cross client tables is S_TABU_DIS and the next check is on S_TABU_CLI.
Authorization object S_TABU_CLI consists of following authorization field –
|Authorization Field||Long Text|
|CLIIDMAINT||Indicator for cross-client maintenance|
The CLIIDMAINT field can take on the value X to grant a user authorization to maintain cross-client tables in general.
Let us take our discussion on S_TABU_DIS a step ahead. What happens if a table is not linked to any authorization group?
If a table is not linked to any authorization group, then what authorization will be required by the user to access the table? Will access to table browser be sufficient to access the table? We may think that perhaps the user can access the table without any authorization group in S_TABU_DIS, but that will be a wrong perception.
Important point to Remember : Those tables which are not linked to any authorization group are protected by authorization group &NC&. “NC” stands for “non classified”.
So, if a user tries to access a table which is not linked to any authorization group, the he will need to have authorization group &NC& with necessary activity for object S_TABU_DIS in his user buffer. Otherwise he will get an authorization error. The SU53 screenshot will be as shown below:
We have seen that one authorization group can be linked to many tables. This means that at times users get access to more tables than they actually need. This at times can be a bit risky. From Security point of view, a user should get only what he needs. Its not a good idea to give access to hundreds of tables, when he needs only one.
So, what is the solution?
S_TABU_NAM is an authorization object created solely to resolve this kind of conflict.
S_TABU_NAM has two authorization fields :
|Authorization Field||Long Text|
ACTVT (Activity) field restricts the access to 02 (change) and 03 (display). The field TABLE (Table Name) is for name of the table which needs to be accessed.
Let us discuss how the authorization object S_TABU_NAM is checked. There is a standard function module VIEW_AUTHORITY_CHECK where the authority-check process for S_TABU_NAM has been coded. Lets see how it works:
Let us assume a scenario where a user is trying to update a table ZX123. As per the function module VIEW_AUTHORITY_CHECK, authorization object S_TABU_DIS should be checked first. Suppose the user does not have update access for table ZX123 via S_TABU_DIS. This means that the check for S_TABU_DIS for the table has failed. After the initial check for S_TABU_DIS fails, authorization object S_TABU_NAM is checked.
So, if the user has following access in his user buffer he should have update access for the table ZX123:
Authorization object : S_TABU_NAM
So, as per the function module VIEW_AUTHORITY_CHECK, authorization object S_TABU_NAM is checked after check for S_TABU_DIS fails.