SAP Tables – S_TABU_LIN
We have already looked at the other SAP authorization objects used to secure tables, S_TABU_DIS, S_TABU_CLI, S_TABU_NAM. We end our discussion on table security with the one remaining object – S_TABU_LIN used for Line Oriented Authorizations. This object can be used to provide row level access control when accessing tables through standard tcodes like SM30 and SM31. I have purposely kept the discussion about this object for the last as its the most complicated to use by far and needs configuration changes in addition to role updates. Also note that S_TABU_LIN is always checked in addition, and not in place of, the check for S_TABU_DIS.
To use S_TABU_LIN in our authorization concept, the first step is to configure a Org Criterion through the SPRO transaction. We can use the org criterions provided by SAP or create our own criteria. The path for configuring org citeria is shown below.
We chose the first of the two options, “Define Org Citeria”. We create a new org citerion called ZMOLGA. The check box, Table-ind should remain unchecked as the new org criteria would only be checked for tables maintained by us and not all tables.
With the new org criteria selected in the screen, we double click the attributes option. This screen allows us to create the attribute for the org criteria. Further we can set the attribute to be the 1st to 8th attribute. The 1st to 8th attribute are actually the authorization fields present in S_TABU_LIN. Though in the present example we will just create a single attribute and set it as the 1st attribute, SAP allows us to create 7 other attributes for the same criterion.
Finally with the attribute created we just need to set the tables/views which will be checked for the org criteria. We use the view V_T510F_B in our example. Currently SAP only allows us to enter one table or view per attribute. The direct result of this limitation is that we need to create a new org criterion for each table we want to secure through S_TABU_LIN.
- Define Table for Org Criterion
We can now save our entries. The system will prompt for a transport request to contain the changed objects. We have now successfully created an org criterion. However, we still need to activate it before S_TABU_LIN and the org criterion will be checked during table access. Activating the criterion is simple. We just check the box and save our entries.
Once this preliminary configuration is done, we are free to use S_TABU_LIN in our roles to secure tables based on the Org criterion. Since our criterion ZMOLGA is based on the MOLGA field of the view V_T510F_B, we can actually restrict access to only certain rows of the table depending on the value of the MOLGA field. For example the authorization below will allow the user with this role to change rows for the V_T510F_B view when MOLGA value equals 10.
It is important to remember that S_TABU_LIN will only be checked for the standard SAP table maintenance transactions. Thus if we have some custom code accessing tables, row level security is not going to work for them. Off course nothing is stopping the developer in adding a authority-check statement for S_TABU_LIN in this case.
Aninda,
Gr8 work really helpful info.
Bcoz of this site many things are easy to understand.
Thanks a Lot……..
Hello there,
Please provide me information about CUA for sap security …
Hi Aninda,
If this object only works for standard SAP table maintenance transactions, would I be correct in assuming that it would also work for SM31 parameter transactions as well even though they would technically be custom tcodes?
Hi Vinnie,
The object would certainly work parameter transactions for SM31/SM30. In fact thats how I have mainly used it in practice.
Regards,
Aninda
Sorry, had a mistake in my email address, so I will add the question again. Thanks in advance.
Hi Aninda,
If this object only works for standard SAP table maintenance transactions, would I be correct in assuming that it would also work for SM31 parameter transactions as well even though they would technically be custom tcodes?
Hi All,
Why is it not possible to have more than 1 view/table per attribute?
Or is it possible and I am missing something?
This is the error I get when I try to add new entries in the table fields
********************************************************
Several table fields per attributs are not yet supported
********************************************************
Best Regards!
Curtis
Hi Curtis,
Thanks for pointing this out. The first time I tried this case was a few months after I had written the post. I have now updated the post to highlight this fact.
I am not sure of the underlying reason for the behaviour but I can confirm that SAP will not allow you to enter multiple tables/views at this step. If you are concerned with a small number of tables you can think of creating a separate org criterion for each of them.
Regards,
Aninda
Can the object S_TABU_LIN be used for SE16N & SE17? Once given for tables access can it be restrict values in SQ00? Can you provide a solution for the same? Also need a solution that covers lots of tables at one go. Any hep will be appreciated.
Regards,
Aarati
Hi Aarti,
I don’t believe you can use a single org criterion for multiple tables unless you are activating it for all tables where a field is present. Once activated, it should work for SE16N and SE17 as well. For SQ00, whether S_TABU_LIN is checked will depend on how the underlying infoset is designed. An Infoset created on a single table or a table join should check for S_TABU_LIN and the rest of the basic table security.
Thanks,
Aninda
Hi Aninda,
In the article specified in the above post,the unable to navigate to 3rd screen which is used in the editing the attributes name and authorization field.
Let me know abt this issue.
Thnx,
Avinash
The explanation on S_TABU_LIN with screenshot is really helpful and awesome tutorial. Hats off to the person who gave that presentation. Nice and very easy to understand.
Pingback: S_TABU_LIN: Line Oriented Authorizations – 1coach.by