Custom transaction on SAP program RBDMANI2

[Former Member]

I have received a request from our abap developer to add a custom transaction to a role. In the process of checking for proper security on the transaction I realized it is on an SAP program, RBDMANI2. My question is, how do I secure it? I know I can't modify the code so adding a check in SU24 is not an option.

If all custom transactions are supposed to have security on them, how do I secure the delivered program behind this code? I couldn't see an object to use.

Or is it ok to not have any checks on this transaction and just add it to the role with no objects brought in?

Thanks

[mvoros]

Hi,

some reports in SAP do not have granular access control. They are all or nothing. Your only chance is to control access via S_TCODE. If this is not acceptable then you have couple of options. Tell SAP and they might update the report. Copy report and add your custom checks. This solution should be last option.

The last solution which I want to mention is using enhancement framework to enhance standard reports. It allows you to use implicit enhancement points such as start of routine and inject your code. Unfortunately, in this case it's not that easy. There is a routine paral_processing which you could use to inject authorization check before processing IDoc. The issue is that it gets called only when you select option parallel processing. There is no suitable enhancement point for sequential processing. So if it's OK to use only parallel processing then you can enhance this routine, create variant for your transaction with read only enabled option "Parallel processing" and give it to users.

Cheers

[Former Member]

So when you say my only chance is to control access via S_TCODE are you saying that just adding it to role (so basically to s_tcode) is the only security it will have on it? To control access based on who has access to the role and therefore to the tcode?

Just doesn't seem like enough but apparently that is what I will have to go with

[mvoros]

Hi,

yes, that's what I meant. I assume that users can't execute any reports with transactions like  SA38 or SE38.

Cheers

[Former Member]

Hi Bobbi,

In addition to what Martin suggested, you can also add an authorization check to the transaction defination while creating your custom tcode thru' SE93 (recorded in table TSTCA) & that authorization check will be made right after S_TCODE check. This is one additional control I can think of.

Ofcourse,  assigning an authorization group to the report will also introduce an auth check on S_PROGRAM whenever your custom tcode is executed but that will affect other users who execute the program directly thru' SE38 and SA38 as well and hence not advisable according to me.

Thanks

Sandipan

Message was edited by: Sandipan Choudhury