Cómo funciona el programa del S_TABU_DIS - VIEW_AUTHORITY_CHECK

SAP Tables – S_TABU_NAM

BY ANINDA, ON DECEMBER 7TH, 2011

As security consultants, we are often asked to secure or grant access to SAP tables. So
most of us are already aware of the authorization objects used to secure
tables, S_TABU_DIS, S_TABU_CLI and S_TABU_LIN. Out of this, S_TABU_DIS is
the one that is needed for all tables. S_TABU_DIS secures tables on the basis of
activity (02, 03) and authorization group for the table. S_TABU_CLI is needed
when a user needs access to maintain client independent tables. S_TABU_LIN is
meant for Line Oriented Authorizations which allows us to authorize indivdual
rows of a table. However, till now security for tables was based on the authorization
groups. The limitation with authorization groups is the lack of granular security on
individual tables. Once a user has access a particular table authorization group, the
user can access all tables linked to the authorization group. Technically it is has always
been possible to create a new authorization group and link the offending table. But this
soluation came with its own problems, specially when adopted for standard tables. For
example a lot of tables are accessed to by standard tcodes. Changing authorizations
groups for such tables can potentially impact the functioning of tcodes calling them.
Also, the new authorization groups might be overwritten by SAP service packs so
this becomes a recurring check for upcoming upgrades. Fortunately SAP in its latest
service packs has come up with a new authorization objects for securinf tables,
S_TABU_NAM. S_TABU_NAM promises to overcome the limitation of the current
S_TABU_DIS object.

S_TABU_NAM - Fields

As can be seen above, the object has two authorization fields. The first is activity
meant to restrict access to just display (03) or update (02). The other field TABLE
takes the actual name of the table and allows us to restrict/provide access to individual
tables overridding access for authorization groups.

I am copying the relevant SAP code section from the

standard function module VIEW_AUHTORITY_CHECK. This FM is called by all standard
table access transactions like SE16, SE16N, SM30, SM31, SM34, etc.
VIEW_AUTHORITY_CHECK 1
 VIEW_AUTHORITY_CHECK 2

As you can see from the code above, VIEW_AUTHORITY_CHECK has a initial check for
S_TABU_DIS. Only when the S_TABU_DIS check fails, is the new object S_TABU_NAM
checked. So all the existing checks and the security roles built around them need not
be updated as a result of the new object. It just provides us with an additional layer of
flexibility for building our checks for tables. An example scenario might be to give
display access to all tables with authorization group SC but restrict write access to just
the T77UA (which shares the same auth group).