No auth checks for custom transactions

[Former Member]

Hi,

In my SAP system there are many custom trasanactions in which there are no auth checks in their respective programs,

Is their any way to restrict these transactions based on the organisational levels without doing any changes to the program.

Can we restrict these transactions by adding a authorization through se93 ?

If any documents are there on the same issue please share.

Thanks,

Sanketh.

[andrea_brusarestelletti]

Hello,

no, there is no way, as of my knowledge, to do that, but adding in the custom programs the instruction AUTHORITY-CHECK: you can add in customs programs both authority checks to standard authorization objects, and to custom authorization objects that you can create on your own with transaction SU21.

Hope to be useful.

Best regards,

Andrea

[Former Member]

Hello,

Please consult you ABAP programmer to add Auth Check . without hardcoding the in program we cannot add any restriction, since it will not call any Auth object while executing.

Thanks,

Prasant

[Former Member]

Hi,

As the others have said, you need to get your dev team to change the ABAP code. If they complain, tell them they only have to do it because they failed to follow general good practice for custom developments. There is a good reason there are auth checks for most SAP delivered transactions intended for end user access.

SE93 will perform a static check only so if you want to differentiate on org levels it will not suffice.

[Former Member]

Without modifying the ABAP code, you will not be able to add org level checks, even with SE93, you'll only be able to enforce auth check for one AUTH OBJECT, but you can not specify the field / values along with it.

Cheers !!

Zaheer

[Former Member]

Hi Zaheer,

With SE93 you can define the activity and an org level (if available in the object), but I agree that it is static and not too much use in this situation.

[Former Member]

Hi Alex,

So if a custom program is dependent on any organisational level and if there is no authorization check in the program of that transaction.

Still can we restrict the transaction by adding an authorization object through SE93.

If any documents are available,please share.

Thanks,

sanketh.

[Former Member]

No. There are no documents for that, only pepper-spray

What if someone with org. value '1000' can start the transaction, and then select org. value '2000' in the selection screen?

You would need to hardcode the org. value in your program and not offer it to the selection screen. That is even worse!

Your design is wrong.

Cheers,

Julius

[Former Member]

Julius is right. But depending on what's going on, here's one approach that I've used.

Assuming that there is reluctance/inability to modify the code extensively, it's possible to first identify what org level (if org levels are where the restrictions should be) is to be restricted.

Then, you can have a developer put an authority check at the beginning of the execution to check for the valid org level, in whose absence the program exits. It's a dirty solution, but it works because the program won't run for any org level except the one that's hard coded.

On the flip side, don't hard code the org level into the program, but do an authority check to grab the org level at the beginning of the execution, and with the help of the developer, set that org level value as the value of whatever variable it is that will be used throughout the rest of the code.

At this point, ABAP is beyond me. Good luck.

Santosh

[Former Member]

I would take a slightly different approach, as a least worste option.

> Assuming that there is reluctance/inability to modify the code

In that case the code is modularized, but the security front-end is lazy.

What you can do is assign an authorization group to the report type program as well which has the org.value in the P_GROUP field of S_PROGRAM in it, and create a variant for it protected by P_ACTION = VARIANT. The users can submit reports if they are authorizated for the variant action as well, but not directly.

Then create an myriad of parameter transactions per org level and submit the report via transaction START_REPORT (so, via the varint!) with the variant set for the org. level in the selection screen.

But this completely defies thze concept of modularizing code and not maintaining redundant code, as well as redundant variants, and redundant menus of roles which could have been modularized as well.

The only potential "up side" of this is maintaining the SU24 data of the parameter transactions, but who does that?

Yes, if you maintained SE93 then the system would do it for you (automatic adjustement) but the scalability and flexibility of org. level maintenance in roles and well as the modularization (and maintainability) of code would be toasted.

Probably developers would not make authority-checks at all anymore, and that would be like going back to the conceptual stone ages.

Even the Commodore 64 was more modularized than that....

Cheers,

Julius