How to override security for table access when using SAP Query?

[Former Member]

We have a number of infosets which use table join between PA0001 and CATSDB table. To execute a query based on such a query you would need access to table auth group PA through S_TABU_DIS. This was earlier not a problem as SAP query was earlier used by support staff and not end users. We do not want to give S_TABU_DIS with to end users as this amounts to givin them access to all PA tables.

The generated code for the query checks for the condition

"%rtmode-no_authchk = space"

before going for the authorization check.

Thus, ideally the authorization check for an InfoSet can be skipped if we can pass X for this variable from the InfoSet definition. Is there a way to do this?

Would appreciste any inputs to help suppress the authorization check at this point. Thanks.....

[jurjen_heeck]

How about copying the abap to the customer namespace, linking it to a custom transaction and adapting the copy to skip the authority check?

[Former Member]

Hi Jurjen,

Thanks for your inputs. I agree that your solution will work but we do would have to do this for all the queries defind on the infoset which would need some substantial amount of work from our ABAP team.

[Former Member]

i found [this|] in SDN.

- option 1 will not solve your problem

- of course, option 2 is always available -> you could put the appropriate coding directly into the infoset.

- option 3 is not for you, since CATSDB is not used in a logical database.

and in 'extras' -> 'enhancements' in the infoset i found this one: CL_QUERY_TAB_ACCESS_AUTHORITY which is kind of a class for auth-control - but i have no clue how to use this - i'm not even an abaper, even less so oo - but my firsts impression is that this will check tables, not auth-objects ... please ask an abaper.

Edited by: Mylene Euridice Dorias on May 19, 2008 4:23 PM

[Former Member]

Why don't you change the table auth group for PA0001 and CATSDB to a custom one and only assign the custom table auth group in S_TABU_DIS to this group of users.

[Former Member]

Adding code to the InfoSet.

-

---

We had tried to add custom code to the infoset to modify the logic. CL_QUERY_TAB_ACCESS_AUTHORITY is the routine for checking if the user has appropriate authorization in his buffer. So you this is called you can be sure that the no authorization exception will be raised. We could not find any way to add code so that this routine will not be called in the generated report.

Modifying table authgroup for PA0001 and CATSDB

-

---

Both PA0001 and CATSDB are both standard tables which are used in a number of applications. Changing their authgroup just to be able to use them in SQ01 queries does not seem to be a viable alternative.

Thanks everyone for their many responses to this problem. We still do not have any end in sight for this. We might just end up giving access to table authgroup PA to the users and removing access to standard table maintainance transactions from the users' roles.

[Former Member]

have you tried adding code to the infoset like say for the event START-OF-SELECTION??? you might do so in Extras -> Coding. put an authority check in there ...

[Former Member]

The question is not about putting an extra authorization check but removing the authorization check in the generated code. But I have indeed tried adding custom code to INITIALIZATION, START-OF-SELECTION or DATA sections in the Infoset. I could not set up somthing to negate the existing authorization check. Would higly appreaciate if you are aware of a method to stop the the authorization check routines from being called in the generated code for the InfoSet.

[Former Member]

o.k. i found a way but you will not like it:

you can deactivate the classes that will generate the authority-check in the final coding of the query if you deactivate them when CREATING an info-set. only then can you delete those classes. it's not possible afterwards.

since the coding of this is generated at the even start-of-selection (topmost) you cannot override them using coding which would run 'afterwards'.

in your case that would mean you would have to copy your infosets to new ones and take care to delete those classes.

sorry, no better answer ...

[Former Member]

how lucky there's service.sap.com.

note 758956 solves the problem (whithout intending to):

>Transaction SQ02 -> Change InfoSet -> Menu: Goto -> Global attributes -> 'Further Options' -> Enter the value 'CL_QUERY_TAB_ACCESS_AUTHORITY_BW' in the field 'Class for authorization check'.

just delete the class there ...

[Former Member]

Making the changes noted above resulted in a ABAP dump. It appears that the field for "Class for Authorization Check" can not be empty. A balnak field defaults to "CL_TEXT_IDENTIFIER". This gives a run time error as the data types of CL_TEXT_IDENTIFIER and what the generated code expects do not match. I do not know enough ABAP to sort this out but will be working with the ABAP team on it. Thanks a lot for your response!

[Former Member]

Perhaps you could replace it with a class of your own (transaction SE24)?

I have not tried to do this; it was just a thought.

Kind regards,

Julius

[Former Member]

>

> Perhaps you could replace it with a class of your own (transaction SE24)?
> 
> I have not tried to do this; it was just a thought.
> 
> Kind regards,
> Julius

unfortunately this does not work. SAP saw fit to 'hard-code' the implementation of the interface in RSAQEXCE:

(only parts of that abap displayed here).

 170 data: iref type ref to if_query_tab_access_authority.
1107 *       FORM AUTHORITY_BEGIN
1112 form authority_begin using p_auth_classname type AQS_CLSNA.
1119   perform authority_init using p_auth_classname.
1120   call method iref->access_authority_begin.

well for my part (searching a solution for a query on LTAK, wanting L_LGNUM as an object) i'm out of ideas. i shall have to modify SAP-standard and disable the class and do my own coding in the info-set. no other possibility - i cannot allow S_TABU_DIS for group LA and even if i did, what help would it be - i would have to allow that to all companies in that client having WM - and that would be literally all - i need LGNUM here!

[Former Member]

Would it not work to give a specific context to the query iteself (generate a transaction for it in the role menu?) and then disable the check for that transaction context in SU24?

That might solve for LGNUM problem, but not the S_TABU_DIS "problem", normally, I don't think.

"Hard coding" can be a bugger. More reliable type of bugger

Cheers,

Julius

[Former Member]

>

> Would it not work to give a specific context to the query iteself (generate a transaction for it in the role menu?) and then disable the check for that transaction context in SU24?
> 
> That might solve for LGNUM problem, but not the S_TABU_DIS "problem", normally, I don't think.
> 
> "Hard coding" can be a bugger. More reliable type of bugger 
> 
> Cheers,
> Julius

yes, i could do that - i saw that LS* transations are set up like this. but it does not satisfy my need. i need the S_TABU_DIS thingy gone because if my colleague in Shanghai or someplace else create a new query with the existing infoset, i cannot prevent that they are able to view data from the warehouses of all other companies (different LGNUM) - and i would have to enable S_TABU_DIS act 03 group LA for all - you see!! i refuse to do that and i want an authority-check right there in the infoset on L_LGNUM. unfortunately no-one in the ABAP-forum on SDN could help me set that up <sigh>.

honestly: the security setup for queries is not satisfying.

[Former Member]

Hi there Mylene,

I am sure you know about S_TABU_LIN, but I guess that is not an option here.

You have me stumped as well, but if I think of or find something I will post it.

Kind regards,

Julius

[Former Member]

We finally convinced the business to use a custom report for the data. The security for queries is just not enough.

[Former Member]

>

> We finally convinced the business to use a custom report for the data. The security for queries is just not enough.

My understanding of the above is that it is too much , which is debatable.

How do you track who has access to which data if the business application logic is not used (okay...) and the direct table access is not checked either (okay...) but placed together with both missing?)?

How would you prevent someone from accessing this data or know who can access it?

Of course you can also secure the custom report and document that - but who reads the documentation? Or should be expected to find it?

Just some thoughts,

Julius