Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

S_TABU_DIS doesn't work with SELECT FROM TABLE

Former Member
0 Kudos

Hi Guru,

I have this problem: in Customer's Scenario there are in the same application server any SAP Modules as FI and HCM, there are FI consultant/developer and HCM consultant and developer. The FI Consulant should not see data of HCM and vice versa.

I have set the Authorization Object S_TABU_DIS for table HCM setting the authorization group PA for HCM table as PA0001, PA0008 etc. The problem occurs if i write a program with a SELECT * FROM PA0008, in this case the authorization check doensn't work.

Any suggestions?

Thanks a lot.

Lorenzo

5 REPLIES 5

martin_voros
Active Contributor
0 Kudos

Hi,

are you talking about production environment only or you want to separate users also in development box? It's not possible to do it in development box if you have developers. There is no way how you can prevent a user with access to write his own program to access any data in SAP.

Cheers

0 Kudos

Hi Martin,

I'm talking about production evironment. Only in production environment are sensitive data but if developer FI write a program in development and run it in production evironment the data will be visible although the Authorization Object S_TABU_DIS is set..

Thanks.

Regards.

0 Kudos

Hi,

this is common misconception that authorization checks are performed somehow magically. No, almost all authorization checks must me coded in your applications. There are some exceptions like S_TCODE and S_DATASET that are performed in kernel and you don't have to put them into your ABAP code. S_TABU_DIS does not belong to this class.

Hence you can't use S_TABU_DIS against malicious developer. The only reasonable thing what I can think of is to do a code review before moving new code into QA and later into production. So a developer can't sneak a shady code into production and later execute it there. But you have to assume that an ABAP program can do anything so you have to be careful what programs to get into production.

Some companies have separate HCM system to prevent these problems.

Cheers

Former Member
0 Kudos

+ 1 with Martin.

I would even class an S_TABU_DIS check as a rather stupid thing to do and if it were native in the select statement then you would have to give full access to all end users. Upside would be no org. levels needed anymore - also cool 😉

Rather use an LDB in your report or call the central FMs in HR to real infotypes. Also see object P_ABAP!

Cheers,

Julius

Former Member
0 Kudos

I agree with Julius and Martin. you'd be better off using i.e. HR_READ_INFOTYPE instead of a SELECT statement.

by using this FM an authorization check will take place on HR master data authorization (infotypes) whereas with a SELECT it will not.

the S_TABU_DIS object is not used to authorize data access specifically. it is usually used to prevent access to groups of tables through SE16(N) for example.  

in your case, the FI consultant should not be authorized for the P_ORGIN object (access to HR master data) nor should it have access to the PA group in S_TABU_DIS if you're really serious about not accessing HR data.

using SELECT in a report that the FI consultant can execute will render these authorization restrictions useless.