RE: Restriction report execution

[Sri_S1]

Hi,

We are trying to restrict a user to a particular z report. we added authorization group to that report and added the same to the user profile.

when we are testing the user ID, user is able to execute his report, but he is also executing standard sap reports that does not contain any authorization groups.

How to just stop him from executing the standard reports that does not authorization groups

thanks,

Sun

[Sri_S1]

Hi,

We are trying to restrict a user to a particular z report. we added authorization group to that report and added the same to the user profile.

when we are testing the user ID, user is able to execute his report, but he is also executing standard sap reports that does not contain any authorization groups.

How to just stop him from executing the standard reports that does not authorization groups

thanks,

Sun

[Former Member]

Hello,

The authorization to run a program is checked with object S_PROGRAM. The user should have the authorization for user action SUBMIT. Additional authorizations to run a program will only be checked if the program has an auth group maintained in its authorization group field. If not the user will be able to execute the program.

If you want to maintain an authorization group for programs use the report RSCSAUTH.With RSCSAUTH program you can assign the authorization group to a list of programs or individual programs. This ensures proper protection to your programs.

[Former Member]

Also it is a SAP recommended to assign your Zreports and tables to transaction codes rather then giving the end users authorization to execute SA38 & SE16.

This will ensure the user has only authorization to execute the required programs or modify the required tables.

[Sri_S1]

Hi Subramanyam,

Thanks for your answer, we already assigned Auth groups through RSCSAUTH to all the Z reports that we created and I gave the Same Auth Grp to the user in S_PROGRAM.

But the problem is along with the user report, he can also execute some reports like RSPARAM and RS* and so on.. that does not have any Auth Grps. (he is unable to execute other programs that has a diff Auth Grp).

so, now i am looking to restrict him so that he cannot execute the reports that does not contain any Aut h Grps.

thanks,

Sun

[Sri_S1]

Hi Subramanyam,

I suggested to add that report to a tcode. Thanks for your response.

thanks,

Sun

[Former Member]

Hi Sun

first of all check what are the authorizations given to him if you could

state what are the authorizations given .If you want to restrict a user

to particular zreport then its better if you put that zreport in one tcode

(SE93->In the tool bar>Transaction>create>then in the following screen

enter tcode(XXXX) description select according to the radio check buttons,

now in the following screen enter the details of the program,authorization object

to which authorization object you want to attach all those.

Now assign the tcode to that user in a separate role.Hope this will fetch you

the required thing.

regards,

Manjula.

[Sri_S1]

Hi Manjula,

Thanks for your response, i suggested to assign that report to a Tcode.

In that way, there is no need to give SA38

thanks,

Sun

[Former Member]

Note that p_action "variant" is also sufficient to submit the report, unless it is submitted from the workbench (e.g. SE38, SE80, etc etc etc). If there is no p_group to protect the report itself or the report tree, then the check is suppressed on S_PROGRAM. But normally there are still other checks which follow, depending on what the report is capable of doing.

The most common approach is to restrict the ability to execute reports online, and as and when you find dodgey ones, check that your authorization concept is intact enough that the checks in the report itself will prevent users from running them to completion, regardless of their S_TCODE authority.

If you find reports etc which have insufficient checks in them, please report them to SAP via service.sap.com. That way, SAP fixes them for all of us :-). I have done this on many occasions and SAP are greatfull if you report it to them.

You can also protect them (the standard reports) via RSCSAUTH as mentioned and this is not a modification. But to systematically go through them all is not an investment worth taking for a once-off implementation.

Cheers,

Julius

[Sri_S1]

Hi Julius,

Thanks for your response.

we already added Auth Grps through RSCSAUTH and i gave the same Auth Grp in S_PROGRAM under P_GROUP to the user.

He is able to execute the report for that Auth Grp and it is also restricting him to Execute other Reports that has diff Auth Grps,

But the problem here is, he is able to execute some reports that does not contain any Auth Grps,

how this can be possible if i give him a Auth Grp in his profile.

I tried executing RSPARAM which is a standard (SAP) and does not contain Auth Grp.

and its allowing him to execute this one, there are lot of reports that starts with R* (SAP ones i guess) that does not have any Auth Grp and user can execute them even after restricting him in his profile

Thanks,

Sun

[Former Member]

You are correct, but the reports can and should (or must) make appropriate checks themselves. S_PROGRAM is not enough, and a missing auth-group is not necessarily a problem.

For the program authgroups, it works like this: The runtime environment first checks whether the report is protected by an authorization group.

If not then a submit of the report is unhindered by any S_PROGRAM checks. (It does not replace it by symbolic values to be checked like S_TABU_DIS does from generic data browsers like SE16).

If it is protected, then it checks for p_action = 'SUBMIT' of that p_group value. If then fails, then it checks p_action = 'VARIANT' as the report might be submitted using it's selection screen values as well, which if passed will also submit the report.

The coding looks like this (with comments translated):

• Start only via Variants?...
• Submit authorization check.....
• No authority for this p_group...
• ... then permit authority for variant maintenance of the p_group as well.

FORM CHECK_ABAPSUBMIT_AUTH USING PROGNAME VARIANT SSET SECU. IF SSET >< SPACE. IF VARIANT = SPACE. MESSAGE E623(DB) WITH PROGNAME RAISING JUST_VIA_VARIANT. ENDIF. ENDIF. IF SECU >< SPACE. AUTHORITY-CHECK OBJECT 'S_PROGRAM' ID 'P_GROUP' FIELD SECU ID 'P_ACTION' FIELD 'SUBMIT'. IF SY-SUBRC NE 0. AUTHORITY-CHECK OBJECT 'S_PROGRAM' ID 'P_GROUP' FIELD SECU ID 'P_ACTION' FIELD 'VARIANT'. IF SY-SUBRC >< 0. MESSAGE E092 WITH SECU RAISING NO_SUBMIT_AUTH. ENDIF. ENDIF. ENDIF. ENDFORM.

The option of restricting the ability of users to enter (or change) the name of the report before it is submitted is the most obvious solution, and you have a large security gain with relatively low effort to create transactions and give them to the users (preferably in a role menu or report tree). Infact, this will most likely be an efficiency gain as they don't need to memorize the report names anymore and you can change the report without having to change the transaction name and menu in future.

If you want to go beyond this, then you need to make a little investment into using "dummy" p_group values which all users have (search the forum for message number "E092").

But remember that some report type programs are generated by the system and their names can be rather cryptic.... and they have the nasty habit of spawning and deleting themselves (known as "garbage collection") so you cannot protect them using that approach, but what you can do is look for the customer exit in function module RS_ABAPSUBMIT_AUTH_INTERN into which you can add some additional checks for unwanted programs or program names - some generated programs follow a naming convention such as Z$$$ (installed coding via external tables) or !xxx (single-tests of unsaved, inactive code) etc however most of these are not possible in a "closed" and "not modifiable" system anyway.

There are also a couple of other things you can do and we could go on for a long time... but as you can see the effort : benefit ratio is starting to get thin now.

I would recommend starting to cover 80% of the risk with 20% of the effort (~correct setup config, correct customzing and a robust role based authorization concept) and turn the security audit log on to compensate for the rest until you can find a reason to further fine tune it for specific risks.

Sorry for the long rambling answer, but hope it helps.

Cheers,

Julius

Edited by: Julius Bussche on Nov 24, 2008 4:51 PM

[Sri_S1]

Thanks Julius for your explanation.

I will put that report in a tcode and we will use it.

Less effort more secure....

I dont think SAP is going to assign Auth Grps to all the standard reports that does not has any Auth Grps, so we need to secure our reports in our own way.

thanks,

Sun

Edited by: sun on Nov 24, 2008 5:57 PM

[Former Member]

> I dont think SAP is going to assign Auth Grps to all the standard reports that does not has any Auth Grps, so we need to secure our reports in our own way.

I am also not convinced completely eitehr that SAP should protect all the thousands of reports, but a case-by-case study is certainly a pain and it would be impossible for any one person to find and check them all...

Best thing (regardless of s_tcode and s_program) is to have a correct authority-check at the correct place in the program code, which it also reacts to. This already becamee much better with the release of BAPI's (see transaction BAPI) and now as well with ABAP Object Oriented programming (see transaction SE24) which do these checks automatically if used.

Another place where things have improved a lot is in the so called "test environment" (not to be mistaken for the QAS "test system"). For reports, you can also tweak the check by implementing [SAP Note 1012066|https://service.sap.com/sap/support/notes/1012066] which is very usefull for auditors and other support folks who want to see or check the coding, but you don't want them to run it from there (test it) so you can restrict actvt '16'. The same for function modules was introduced some time ago and I strongly recommend against giving anyone authority for this "testing" (actvt 16 of object type FUGR) in a production system...

Cheers,

Julius

[Sri_S1]

Hi Julius,

Ok thanks,

Sun