Skip to Content
Author's profile photo Otto Gold

On the way to granularity

Let’s start with S_TABU_DIS and S_TABU_NAM

We still remember the times when it was not so easy to authorize for generic tools for the access to database tables (transactions such as SE16, SE17, SM30, SM31 or SM34). The only option was the authorization object S_TABU_DIS, which lets one authorize on the level of authorization groups (groups of tables). Just to summarize -> it means that you permit access to a certain group of tables which means that the user can either access all of these tables or none of them. Some people tried tricks with reassigning the tables to different groups

Then S_TABU_NAM object has been introduced which has made it possible to authorize for a single table which was something many MANY (!!) authorizations administrator wanted and prayed for. Now you can maintain parameter transactions for the tables you need to authorize for, maintain the S_TABU_NAM proposal for that parameter transaction in SU24 and via the role menu get the S_TABU_NAM instances all “Standard” in the role.

And how this S_TABU_NAM works exactly? In the module VIEW_AUTHORITY_CHECK, the system checks S_TABU_NAM only if the authorization check on S_TABU_DIS was unsuccessful. This procedure enables both the retention of the previous table access concept and the superposed use of both authorization objects. Notes 1500054 and 1434284 are provided for information regarding the optimum use of this enhancement.

If you build roles via menus and understand the benefit of SU24, you will never give any table access which is not necessary or which you cannot link back to why it had been given when your auditor asks (assuming you understand the “Standard” instance type and know “sun over the mountains” icon and its magic).

Technical details for the interested:

  1. You can see what group the table is assigned in table TDDAT. The combination TABNAME and CCLASS is what you are looking for.
  2. It is probably more convenient for you to find this information somewhere in the SAP standard screens. Then I can recommend you transaction SE11 > provide the name of the table and click “Display”. Then in the main menu Utilities > Assign Authorization Group.
  3. Note that not every table is assigned to a group. Or a meaningful group. Note that table group &NC& is equivalent to “empty value”. Beware of SAP standard SU24 proposals that pull the &NC& value for S_TABU_DIS-DICBERCLS field. But that would be another story.
  4. If you want to learn more about the authorization concept options for generic table access or simply want to have everything describe in one place, please find your way to OSS Note 1434284 – FAQ| Authorization concept for generic table access.
  5. Avoid coding your own S_TABU_* objects’ (all objects in the family) authorization checks at all costs. Use function module VIEW_AUTHORITY_CHECK for this purpose every time. You can see OSS Note 1481950 – New authorization check for generic table access for some details (in combination with 1434284 above!!).
  6. Note: changing authorization group of a standard table is a modification!
  7. Warning: Be careful with banning the S_TABU_DIS object completely. It should not be used as a hardcoded authority check in the SAP standard code any more (if you find it, outside of VIEW_AUTHORITY_CHECK, please inform us about it here!), but you can still find it in TSTCA (check in SE93 – authorizations needed to start a transaction). Because the S_TABU_DIS/ NAM logic is implemented in the VIEW_AUTHORITY_CHECK function module, TSTCA mechanism does not know about it (does not use this way!) and so S_TABU_DIS in TSTCA must still be authorized for using the object not some “friend” object like with DIS and NAM. In case you find TSTCA in SAP standard transactions, you can also consider reporting it here and we can see if we can get rid of it once and for all somehow.
  8. S_TABU_DIS and NAM get a little mention in Frank Buchholz’ blog ABAP Development Standards concerning Security. Unfortunately it does not mention the information about not using S_TABU_* checks hardcoded in the code and the need for VIEW_AUTHORITY_CHECK but maybe you can just believe me on that one.

I must also remind you about the blog by Greg Capps: Reduce the Risk of SAP Direct Table Access.

Then we got S_RFC, RFCTYPE = FUNC

We used to have the same problem with authorizing for S_RFC. You may have noticed that S_RFC gets generated automatically by the PFCG framework when you put a function module into a menu of a role (yes, that works!). Unfortunately what gets generated is a S_RFC instance with RFCTYPE = FUGR. This means that by putting a function module into a menu of a role your role will get S_RFC instance generated which will authorize for all function modules in the function group.

The good news is that there is better granularity possible here since RFCTYPE = FUNC has been introduced. It means you can (MANUALLY!) authorize for a single function module.

It works very much like S_TABU_DIS and NAM: At run time the first check is for the function group executed. If this check fails a second check for the function module is executed. By this behaviour no changes are to be expected during upgrade, but a more granular authority check can be activated on demand. It also share something with S_TCODE – generated entries you cannot edit (because they correspond to the menu entries): Note that the S_RFC standard authorizations discussed in this note are not authorization default values but automatically created start authorizations analogous to S_TCODE. Therefore, they cannot be edited.

If anyone from SAP reads this I would be interested to know if anyone plans to generate S_RFC type FUNC in PFCG either as a default option (after installation or upgrade of the system) or as a default option once a customizing switch is changed (PRGN/SSM_CUST?). That would be wonderful.

Let me share a workaround for type FUNC if you have the time (or the strict requirement) or the urge to make your roles super secure. What you can do is you can manually add new SU24 proposals to the function modules that you want to use (you already are using) in your roles: S_RFC with RFCTYPE = FUNC. Then when you create your role menus and SU24 gets pulled into the authorizations as well as S_RFC RFCTYPE = FUGR gets generated by the PFCG for you, you have the necessary authorization needed to use your functions modules covered twice. Once by FUGR, once byFUNC. Now if you deactivate the instance with RFCTYPE = FUGR, you have a role authorized for S_RFC values which it really needs and not all the function modules that happen to be in the function groups.

Technical details for the interested:

  1. S_RFC type FUNC has been introduced with OSS Note 931251 – Security Note: Authority Check for Function Modules.
  2. OSS Note 1640733 – PFCG: Additional S_RFC authorization describes the mechanism how PFCG generates standard instances for S_RFC object for (remote enabled) function modules in the menu of a role.
  3. OSS Note 1749485 – PFCG: Problems when updating start authorizations mentions the generated instances for S_START and S_SERVICE objects based on the role’s menu entries just like we get for S_RFC.

Anyway I hope you see my point. Just like S_TABU_DIS got more granular with S_TABU_NAM, so did S_RFC (although within one object).

…and now we’ve got S_PROGNAM

And finally… here we are getting to the point why I reminded you about old and known facts above – as an introduction to the “get-more-granular” movement which now has a brand new member. Let me introduce you to S_PROGRAM’s younger brother S_PROGNAM. Please check the spelling to see the difference once again;-).

So what is this new S_PROGNAM? It is a possibility to authorize for individual programs rather than via program groups. Note that you must activate the feature to be able to use it, for existing customers using existing authorization concepts it does not change anything (backwards compatible).

The programmatic submit of reports is secured by the authorization group (old S_PROGRAM) the report is assigned to. In case the authorization group is empty, the report may be executed without an initial authorization check. How I see the new check (if active) it checks your authorizations every time (every time you start a program using the API which also takes care of S_PROGNAM). Which means it does not “just happen” when you call SUBMIT <program> in your custom code. If any of my assumptions is wrong, I will update the texts once I learn the facts (and can cite them via an OSS note).

As a consequence of this new granularity and flexibility you can authorize for only those programs that are really needed and if you work carefully and patiently (and manually), you may get up into a world where S_PROGRAM does not have * in the value and S_PROGNAM is used in combination with SU24 proposals and role menus. Happy hardening (of your security).

Technical details for the interested:

  1. To learn more about the new S_PROGNAM object start with the note 1946079 – Initial Authorization Check in Function SUBMIT_REPORT. Note that this authority check IS OPTIONAL and you must turn it on (see point 3 below).
  2. Note that although this S_PROGNAM object is quite new, it is back-ported all the way to NW 700 SP4 (which a LOOONG time ago!). In case you run an older system, you can consider importing the correction instructions if you can upgrade for whatever reason. If I am not mistaken, by default the mechanism and the object exist in the NetWeaver systems 740 onwards. Try transaction SACF and you will see.
  3. To be able to use the new S_PROGNAM you need to have the SACF transaction (switchable authorizations framework installed first). For more information about what that is you can read OSS Note 1922808 – SACF: FAQ – Supplementary application information and Note 1908870 – SACF: Workbench for switchable authorization scenarios.
  4. To read an interesting discussion about the old S_PROGRAM navigate here:

P. S.: Rumours have it that we can expect more granularity coming for other objects as well. A candidate that some people are waiting for (like DSAG – German User Group in its materials) is S_GUI that would give the admins the granularity to decide about export / import feature for each program separately. In case anyone has any updates on this one, I would love to hear about it.

Questions for SAP:

1) Will you change the S_RFC behaviour in PFCG? So that PFCG generates S_RFC type FUNC instead of FUGR now when such option is available? Even if you don’t make it a mainstream thing for everyone, would you at least consider a switch (PRGN/SSM_CUST) that would let customers switch that on/ change the current default behaviour? Note: we are well aware of the limit on the number of values in a PFCG instance, especially when names of functions are so long.

Update 06/12/2014: 1640733 – PFCG: Additional S_RFC authorization

2) Would you consider an option to check S_TABU_NAM first (before S_TABU_DIS) or provide a switch to do this so that in the authorization trace the more granular access comes first? Then the info which table it was if the check was unsuccessful comes first and makes it easier for the normal and also the lazy to spot the value which must go to SU24/ role in PFCG?).

3) Would you consider cleaning the TSTCA table records to remove S_TABU_DIS from there (as that is not considered for NAM&DIS mechanism because that only works via VIEW_AUTHORITY_CHECK)?

4) Would you tell us why you decided to perform the check on S_TABU_DIS before S_TABU_NAM? Ideally put that into some OSS note (or KBA?) and let us read it there – from the official source.

5) Although it is unlikely, has that ever been considered to retire S_TABU_DIS object one day? Would you consider a switch that would deactivate S_TABU_DIS in the system so that customers can force more granular access only?

6) Can you provide any updates on S_GUI getting more granularity as well? Like when, new object or new field, SACF or standard delivery etc.?

Interesting points from the discussion:

Martin Voros recommends note 2041892 – Logging of call of generic table accesses to your attention.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      Hi Otto


      Great piece!


      VIEW_AUTHORITY_CHECK, the system checks S_TABU_NAM only if the authorization check on S_TABU_DIS was unsuccessful


      Probably something you can't answer but I always wonder why they didn't perform the S_TABU_NAM first and then check the S_TABU_DIS next if it fails? It'd be a nice way to show on the trace file that the object appears and would be preferred as more restrictive access.


      but you can still find it in TSTCA


      Do you know if SAP intends to go through their list and change this over? Force customers to switch to S_TABU_NAM? Or is there an intention to S_TABU_DIS to always remain?



      For granularity example, would you consider S_ALV_LAYR over S_ALV_LAYO (1667238 - Introduction of authorization object S_ALV_LAYR)? Admittedly, aim not to have S_ALV_LAYO in Production. Also, this came out a while ago but I'm certain my customers are unaware of it.





      Author's profile photo Otto Gold
      Otto Gold
      Blog Post Author

      Hello Colleen,


      I assume they expected something like what I suggest for S_RFC, RFCTYPE = FUNC. That you actively replace S_TABU_DIS with NAM and then just stop using S_TABU_DIS completely. If you have S_TABU_DIS in the TSTCA for transactions and you enter SU24 maintenance for that transaction at least once - SU24 automatically enhances itself to propose what is in the TSTCA. This way you should always get real values in your roles and can decide if you deactivate S_TABU_DIS or keep it for isolated cases (in combination with where used list in "Authorizations" tab).


      I don't remember ever seeing or hearing the information about the order of the checks anywhere and don't want to speculate either. What would be an option would be a switch (you know like PRGN/SSM_CUST) to hit the S_TABU_NAM first. That would be quite helpful.


      I have no idea if they clean it or when they do it. We can keep asking here or via OSS. No idea what else we can do. I had my share of fun reporting SU24 problems via OSS and don't want to open too many fronts (cans of worms) with them.


      I am sure they are not going to retire S_TABU_DIS during our lifetime. I don't think it is the right thing for everyone either.


      You are right with LAYO and LAYR. Julius said the same thing. So now I have the suggestion from both of you which makes it statistically significant enough that I will add it shortly Just for the sake of completeness and so that we can point our customers to a single point of truth


      cheers Otto

      Author's profile photo Otto Gold
      Otto Gold
      Blog Post Author

      By the way I count 496 TSTCA records for S_TABU_DIS in my system (2 fields -> 248 transactions). Some of them without a value. Ouch.

      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      Thanks Otto


      a switch would be excellent for customers to be able to rid the object. As far as tstca goes, surely that is an easy fix for next Ehp? su25 would then pick it up




      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      As I sit here building security I came across the S_TABU_DIS piece...


      pity the code is in the sequence of S_TABU_DIS followed by S_TABU_NAM in function module VIEW_AUTHORITY_CHECK


      if it's all coming through here then the PRGN_CUST switch could(?) easily be implemented.


      I wonder if SAP will ever answer your questions?

      Author's profile photo Martin Voros
      Martin Voros

      Hi Otto,


      nice summary. Not sure why people are excited about S_GUI enhancement. People might be also interested in note 2041892 - Logging of call of generic table accesses. SM19 now can log generic access to tables.



      Author's profile photo Otto Gold
      Otto Gold
      Blog Post Author

      Hi Martin,


      thanks for the comment. I especially appreciate the note number because that is new to me (and will be appreciated by my colleagues and customers!). Thanks a ton!


      cheers Otto

      Author's profile photo Matt Fraser
      Matt Fraser

      This is really good information. I was aware of the S_TABU_NAM enhancement, but the S_RFC RFCTYPE=FUNC and S_PROGNAM were new to me. Also, I didn't know the details of how S_TABU_NAM and S_TABU_DIS interacted, so that's really useful.

      Author's profile photo Rakesh Ram
      Rakesh Ram

      Hi Otto Gold,


      Just like your name, the article is also GOLD. I was also aware of table security but not aware of S_RFC and S_PROGNAM. and adding to this thanks to colleen lee for S_ALV_LAYR over S_ALV_LAYO.


      you people really help us a lot to expand our limited knowledge.




      Author's profile photo Former Member
      Former Member

      But how do you solve this old problem:  tables like LFA1, which can contain vital tax ID information.  SAP puts it in cclass=FA along with >900 other tables and this is maddening. Users routinely view other tables in the FA class all the time, they build sqvi queries, pull extracts, etc. and it's part of their daily life.  But certain tables, like LFA1 (and several others in FA) are vital, and nobody should have access or those tables should be from views only.   What to do?   We can't revoke S_TABU_DIS/DICBERCLAS=FA from users without huge backlash.  One option I can imagine is pulling S_TABU_DIS/FA out of all roles, then create a new role having only S_TABU_NAM and a hardcoded list of >900 tables from the FA class, except without the vital tables.  But how to keep such a hardcoded list updated as support packs roll in?


      It's maddening.  I wish SAP would give us a blacklist in the form of a control table or an attribute flag in Se11, so we can flag vital tables, and then require a specific reference in S_TABU_NAM to view the table regardless of any s_tabu_dis values the user has.  


      But since that doesn't exist, how do you approach s_tabu_dis cleanups, Otto?  

      Author's profile photo Former Member
      Former Member

      Agree, it would be nice to flag tables into a blacklist instead of using S_TABU_NAM to make a whitelist.   Or here's a thought - make it less worrisome to override SAP default table class assignments by making some kind of where-used list for the table and its auth class, so we can know what transactions break if the table's class assignment changes.  That would be nice.


      Otto - those are good questions for SAP.  Do you have answers?  did you ask them via an OSS message...SAP Idea Place?   Is there a way the community can get updates besides comments of this blog post?

      Author's profile photo Otto Gold
      Otto Gold
      Blog Post Author

      It is not so difficult to put such a list together. Table TDDAT for table groups, USOBT_C for SU24 entries etc. The main problem is that you would have to recheck this thing quite often.


      Jason I have this problem that I am known "repeated offender" on OSS with all sorts of things that are not "bug report" type of things. The openness of every component for discussions is different in every component. Sometimes I get lucky with BC-SEC and I get the answers for the whole community (I will post things here or below my other blogs to share them) or some hope that my ideas are not so ridiculous. They have their own priorities. I have my experience. What is "better" or "more relevant"? I don't have hundreds of customers behind me to shout "do what Otto says". that sounds wrong, that would be like unions


      I am trying to be nice with SAP and hope for the best. I hope that providing good content here on SDN and generally showing that I am knowledgeable gives my ideas a chance. Better chance than battling OSS. But it is their choice


      cheers Otto