Restrict access to rows in tables using S_TABU_LIN

[Former Member]

Hello

Is it possible to use this authorization object to restrict access to rows in data tables, based on role?

Namely, a query is created for table holding financial documents data, and I would like users in charge of one company code, to only be able to see rows relating to that company code when they execute the query.

I have defined and activated an organization criteria, and included it in the role authorization data restricted to only one company code value, but the user is still able to see all rows in the table.

The system trace doesn't show a check for the S_TABU_LIN Object while the user is executing the query.

Can anyone tell me what I'm missing?

Thanks in advance

A.

[Former Member]

Hello A.,

I am not a query guru (hopefully Auke or one of the others can help out), but my understanding is that the authority-checks on the tables are determined for the query at the time of creating it.

If your S_TABU_LIN checks are not active for the query, then they simply are not there.

Can anyone confirm this?

Kind regards,

Julius

[Former Member]

Dear A,

You are on the right track -S-TABU_LIN is the object used to control the lines of the table. This can be used within the company code.

I have not used this ...but I remenber a post here in Sep-oct 07 .The access to tables are through Auth Grps. Did you try giving acess to S_TABU_DIS ( Defined in table--TDDAT) and then giving access to S_tabu_LIN ?

Again, Alex/Auke (=NUKE!!) can give us a better input.

Thanks

[Former Member]

Hi Aleksandra.

Are you talking about writing a custom report to get this info or standard SAP Query?

If it's standard SAP query then you can incorporate AUTHORITY-CHECK statement in the infoset for that query.

That way you can restrict the line items that a user can see without resorting to S_TABU_LIN. I suggest speaking to your ABAP team about putting code in the infoset.

[Former Member]

Thank you all for your answers.

Alex, it seems that none of our ABAP team has dealt with authorizaation checks whithin the code they wrote. Could you give me some more details on how to write the code in the infoset, if it's not to long a story to explain here?

Regards,

A

[Former Member]

Hi Aleksandra,

I usually leave this to the ABAP team but as an overview you need to identify fields for restriction at the infoset level. You can then use the input of those fields to validate against an auth check (in the code section of the infoset) before retrieving or presenting data (there are a few options).

As the selection screen on a query is dynamically created, this needs to be adjusted or you will get multiple fields appear when you run the query.

Hope that helps, the code is pretty straightforward but the only stuff I have is customer code (Hi Gerald).

[Former Member]

OK, this seems to be a job for the ABAP team so I will leave it up to them further.

Alex, can I just ask why you advised to use this, rather than the S_TABU_LIN auth. object? Did you have problems using it?

[Former Member]

If you activate S_TABU_LIN, whenever that org criterion is hit with table data being retrieved then the check will be performed. If it is a standard SAP table field then that could potentially become problematic depending how you set it up.

By extending the security in the infoset query you are turning the query from a quick and dirty tool to extract data into something that you can control as you would a bespoke report. Once your dev team have worked out what they need to do, you can apply the standard auth concept to queries with relative ease and without impacting other parts of your security.

Another thing to mention is that if your developers use logical databases to retrieve query data then there is usually auth checks incorporated in there (which don't show up in SU53 or ST01).

[Former Member]

Thanks for the explanation. I understand why it is better to use auth. check in infoset code, but I am still puzzled with why the S_TABU_LIN authorization doesn't work.

[Former Member]

Does the S_TABU_LIN auth check kick in when you access the table via SE16?

[Former Member]

Just checked it. No, there is no auth. check in the log when using se16 to display the same table.

[Former Member]

OK, sounds a bit fishy to me. You have defined and activated your org criteria so it should be working. It might be worth taking a look at OSS note 763269 (though that may only cover SE16). If this doesn't work then I'm all out of ideas, S_TABU_LIN isn't exactly my forte I'm afraid

[Former Member]

No, this support package was implemented in our system before.

Either it is a program error, or S_TABU_LIN auth. object cannot be applied to restrict query output at all.

Thank you very much for all your help.

Regards,

A

[Former Member]

Hello Aleksandra,

Have you tried searching service.sap.com for "S_TABU_LIN missing authority checks"?

Kind regards,

Julius

[dyaryura]

Hello,

Just stepped into this post and note  24578 - SAP Query: Authorizations

confirms that S_TABU_LIN cannot be used for queries:

"...When a query is executed on an InfoSet with direct read accesses on a table or a table join, the system checks whether the executing user has read authorization for the corresponding tables (display authorization for object S_TABU_DIS/S_TABU_NAM). The line-based generic table authorization check (object S_TABU_LIN) cannot be used for queries...."

We´re currently using query variants in the program, so the custom tcode that calls the query already set a variant for the query where the organizational field attributes are greyed out. problem is that we might need to create a new tcode for every organization. Have you faced a similar problem before? any thoughts?

Thanks

Diego