Question:
Hi,
what are the ways to restrict accesses to different ABAP reports, when using SE38/SA38? If a user needs to be given access to SE38/SA38 in order to run a certain ABAP report (let's say RHINTE30, for example, or in this case one of the QUalifications reports), what I need to do to to restrict the user from having access to other ABAP reports?
I know one possibility is to make a customer specific transaction for the report and include that the the auth. role, but are there other ways aswell?
BR,
Lissuli
Answer:
Hi,
I know one possibility is to make a customer specific transaction for the report and include that the the auth. role, but are there other ways aswell?
No. If you give SA/SE38 you will give access to run thousands of reports which do not have any authorisation group.
This topic has been covered a number of times, if you use the forum search functionality you will get plenty of info on this subject.
cheers
Al.
Answer:
There is only ONE way to efectively control execution of report and that is to add an authorization group to EVERY report in the system using report RSCSAUTH. The SAP logic that start a report, regardless of how you start it, check to see if the report has an authorizaiton group. If it does it checks the user's access and validates against S_PROGRAM. So the only TRUE way to control report execution is to add an authorization group to the report ( all type 1 and J programs in SAP). The mere assigning of the report to a tcode will not prevent the user form accessing a report Since most access given users have the access to mover from one report to another from any transaction code or report.
Answer:
There is only ONE way to efectively control execution of report and that is to add an authorization group to EVERY report in the system using report RSCSAUTH. The SAP logic that start a report, regardless of how you start it, check to see if the report has an authorizaiton group. If it does it checks the user's access and validates against S_PROGRAM. So the only TRUE way to control report execution is to add an authorization group to the report ( all type 1 and J programs in SAP). The mere assigning of the report to a tcode will not prevent the user form accessing a report Since most access given users have the access to mover from one report to another from any transaction code or report.
but wont that be changing SAP standard programs attributes?
_________________
The heart has its reasons which reason knows not of
PASCAL
Answer:
So.
THe attribute is recognized as a customer security field as is the table authorization group. Te report Auth group is maintianted in report RSCSAUTH.
Answer:
so u meant it is fine to do so? with the report being able to adjust back before/after a sap upgrade?
_________________
The heart has its reasons which reason knows not of
PASCAL
Answer:
Hmm, I gave the the SAP report name that SAP provides to change the value on all reports, indicated the field is recognised as a customer field... So is it Fine to change the value? I think do.
Upgrade effects... ead the documentation on the report. It provides a feature to restore.
Answer:
There is only ONE way to efectively control execution of report and that is to add an authorization group to EVERY report in the system using report xxx.
Dear John,
Considering that changing or removing the Auth Group would then be ONE big security hole, have you ever run a trace on what is checked to run that ABAP?
Bob
Answer:
Many reports have no authoprization checks in the internals and the only check is the auth group on the report....
Answer:
so u meant it is fine to do so? with the report being able to adjust back before/after a sap upgrade?
The point of this report/table is to be able to restore after changes and upgrades. You have to restore frequently after hot packs and there are "dynamically generated" repoirts that will be created without an authorization group that you may choose to deal with.
Answer:
Many reports have no authoprization checks in the internals and the only check is the auth group on the report....
Including RSCSAUTH....
Answer:
That is correct but RSCSAUTH has an autorization group on it, its delivered value is SAP_ALL ( Go figure)
Answer:
Would this logic also apply to Query access. Considering that the SQ01 tcode is often requested for query access, shouldn't be also be doing the same type of security for them. I mean restricting who creates the query and giving access to that query by creating a tcode for it.
If you give SQ00, then don't you also give access to all unprotected queries same as SA38 would. Adding it to a role is another options, but I don't currently support the "User Menu".
Inquiring minds want to know.
Answer:
DO not give query at al, have th queries developed and then assign than tot he roles in PFCG using "add report" . it creates a tcode and you do not have to maintiant the user groups.