Bypass authorization through Z CODE

[Former Member]

Hello Experts,

Is there any possibility that through Z code I can bypass the authorization of standard SAP transaction.

Transaction VA22 is not authorized for the users but I want through developing Z transaction(ZVA22) for VA22 user should achieve this functionality i.e I want to call VA22 from inside ZVA22.

Can this be done, if yes, How??

Please Help.

[ThomasZloch]

Unlocked and moved to Security.

Thomas

[koehntopp]

First of all: why would you do that???

That's the kind of stuff that comes back to bite you when you expect it the least.

The SAP authorization architecture is at the core of your ERP system, keeping you secure. What you are trying to do is build in a backdoor.

Not a good idea. At all.

Frank.

[mvoros]

Hi,

I agree with Frank. It sounds as a terrible idea to disable all authorization check in transaction VA22. I would suggest that you tell us your motivation or requirements and somebody from community might be able to give you a better solution. Your solution is doable but it does not seem to be a good solution.

Cheers

[Former Member]

If you are attaching the same program to the ZVA22 it is going to be difficult to disable the security Checks. Can you explain the requirement little better.

[mvoros]

It's not difficult. You can just disable checks in SU24 but it's not a good idea.

[Former Member]

If you take a look in SU24 you will see that SAP delivers an armada of objects with "No check" indicators.

Possibly the incentive with ZVA22 is to code a VA22 with restricted capability, but turning the check on in SU24 would be a much easier and supported alternative.

Quite often, this is the case with the ability to change the conditions in VA22. By default, the application objects checked are delivered as "No check" from SU22.

@ Shubham: Can you explain what is wrong with VA22? Why do you want to provide the functionality but not make it possible for the user to enter the standard tcode?

Cheers,

Julius

[mvoros]

My not a good idea was meant for turning off all auth. checks for complex transaction like VA22. I don't have any problem with turning some check off for justified cases.

Cheers

[Former Member]

I understood your comment that way as well and agree - but wanted to point out that standard VA22 has several objects deactivated for the check.

This might be the reason why the guru wants to "bypass" the VA22, which initially seems like a "hack". Sometimes, the intention is actually to limit the functionality and the standard tcode does not offer it (by default) so what is meant is that the user should not be able to directly start the standard tcode but still use the functionality.

Turning the check back on in SU24 (e.g. for conditions) is a better option, and in the case of VA22 is quite popular. Hence I suspected that to be the gurus real intention.

hopefully Shubham will follow up (this thread was originally locked in the ABAP forums, but was then moved here for further discussion).

Cheers,

Julius

[Former Member]

BTW: Another option is FM BAPI_CUSTOMERQUOTATION_CHANGE. Of course you need to be authorized to read the record you want to change, but the application program can limit the fields to be changed and code it's own authority-checks before changing anything.

This is an optional (remote enabled...) API which can also be used locally. The application programmer can choose which checks to make and there are enhancement points to add all sorts of external calls and code.

I dont think that Shubham should be judged for having used the term "bypass" when you will typically find that many users in customer systems could "really bypass" security if they wanted to be a bit adventurous with their own RFC access and a client side application which they cannot realisticly be prevented from using.

In this case, Shubham should create a wrapper FM and give them a simple UI to change the fields which the wrapper is capable of changing.

For the same reason, GRC implementations should document custom functions and not rely on "silly" tcodes to make rules...

Non-SAPGui Transaction code type access is more on the downward trend out here in the wild, IMO.

Cheers,

Julius

[mvoros]

Hi,

you might be right. Maybe they have FM that calls VA22 in batch input to change some fields. The users don't have authorization to change anything on SO. So they want to create new transaction linked to VA22 but without authorization checks. No users will use this transaction directly. Some of the BAPIs allow to disable auth. checks. I am not sure about BAPI for SO but PO ones can do this.

Cheers

[Former Member]

The cool thing (and more secure way) of deactivating checks is to contain it to the transaction code context and development environment and transport the SU24 "no checks".

The "old" way was to have import parameters. These are more easily influenced by the caller (sometimes also remotely...) and make the interface more complex. Defeats the purpose of modularization of the calling code as well.

Anyway. lets see what Subham's explanation is. Hopefully the thread is followed up on, as there are very valid cases for "no check" indicators and preventing the user from starting the standard "core" SAPGui transaction as well.

Cheers,

Julius

[Former Member]

Hello,

Apologies for late reply.

I got this requirement and when I asked team to explain the scenario on why they needed it, they didn't turned up.

Gradually, I came to know that as per the business requirement complete authorization for VA22 tr. code can not be given to all users. For this ZVA22 tr. code has been created to provide the authorizations to limited users for limited functionality.

Hope this answers the concerns.

[Colleen]

HI Shubham

Does this means that you created a variant transaction ZVA22 based on VA22. Possibly, you have limited fields appearing etc and that you then intend to restrict subsequent authorizations? But now, your problem is when the user executes ZVA22 it is looking for S_TCODe = VA22?

Your initial post reads like you created ZVA22 to avoid an authorization check happening within VA22 (such as disable checking objet V_VBAK_VKO) - this desire is concerning (and raised by other community members)

If you are trying to stop S_TCODE = VA22, assuming it is due to a call transaction and not hard coded, would SE97 definition on ZVA22 to say do not check S_TCODE for VA22 work?