custom transaction codes no authorization objects associated

[Former Member]

Hi Gurus,

I want to know the risk of having a number of custom transaction codes that do not have authorization objects associated with them.

I looked at table TSTC and compared it with table TSTCA and noted that the custom tcodes in table TSTC were not listed in TSTCA...meaning no auth objects associated with them.

Thanks!

[Former Member]

It simply means that everyone can start the trx without an authorisation check being done!

So correct ASAP!

[Former Member]

Hi Sam

TSTCA will not show you if there are auth objects coded in the ABAP, which is in many cases more important than having an additional static check associated with the transaction code maintained in SE93.

The risk of what you have observed in minimal if there are properly coded checks in the program itself. If there are no checks coded in the program then you need to get it fixed as users will only be restricted by S_TCODE and a small number of checks performed at the kernel level.

Edited by: Alex Ayers on Feb 14, 2009 8:17 AM

[jurjen_heeck]

> The risk of what you have observed in minimal if there are properly coded checks in the program itself.

Which should point your investigation into the transactions themselves.

If they are parameter- or variant transactions for existing programs you should have a look at the checks for these programs. I suspect they will be safe.

If the program behind the custom transaction is also custom, best talk to the programmer about authorty-checks.

[Former Member]

If they have absolutely no checks what is the first thing you think we should do?

[jurjen_heeck]

> If they have absolutely no checks what is the first thing you think we should do?

It depends on what these transactions/programs do. There's always the S_TCODE check but you may want to protect the data these programs show or even modify. Apart from the S_TCODE check you can also switch on an extra check in SE93, but that check will be executed only at transaction start, irrespective of the data selected.

This part, incorporating authority-checks into the source code should have started in the design phase. You'll need an abaper and someone with knowledge about the security classification of the data involved.

So 'the first thing' in my opinion, is to assess wether you really need checks in these programs. The most likely answer will be 'yes'.

[Former Member]

Hello Sam,

Can you please check which kind of Customer tcodes these are, are they coupled tcodes or they are for custom programs.

if coupled then you don't need to worry, as check will be in place.

however if are based on customer programs, then if programmer created program without any AUTHORITY-CHECK, then may be that program do not pose any risk.

else the custom program will contain AUTHORITY-CHECK coding in the code.

and if some custom auth object and fields are used, then please do NOT maintain them in SU24, as this will cause lot of unknown problem.

best is to create roles with these authorizations and assign those to the users.

hope this help

Regards,

Surpreet

[jurjen_heeck]

> and if some custom auth object and fields are used, then please do NOT maintain them in SU24, as this will cause lot of unknown problem.

Please elaborate on this one, if possible with an example of the problems encountered.

[Former Member]

Thanks - I will update this thread when I get more information. For now I will leave it as unanswered. Thanks you all for responding.

[Former Member]

> I looked at table TSTC and compared it with table TSTCA and noted that the custom tcodes in table TSTC were not listed in TSTCA...meaning no auth objects associated with them.

Stated like this, your observation is not complete (as the TSTCA is as well, as you have noticed).

TSTCA is an old mechanism. It was invented to add upfront checks before there were tcode checks (you can still see this in some old IMG tcodes). Later it was used to add common denominator checks (mostly display activities) for parameter transactions as the user might be able to call the transaction via menus etc but should not be able to proceed with it.

However, the bugger with all these upfront checks is that you need to raise a lot of informative messages for them, and when the message says "You are not authorized to use transaction &" then it does not necessarily relate to the tcode &.

As others have already said, the best place for an authority-check is in the source code at the location where the activity will be technically performed. Using the same check earlier already is also a good practice for user friendliness of the User Interface programming (screens) but this does require a better understanding of the results of trace files.

That way, regardless of the caller, the user will face the same checks and you can reuse functionality in your role concept from many entry points in the standard system and create your own custom entry points which will experience the same checks as well.

As far as I know, this is one of the drivers behind encouraging use of BAPI's (see transaction BAPI) and in ABAP Object Oriented programming models there are more "fool proof" mechanisms as well to protect the developer from making errors.

I think if you still cannot close the thread, then you should provide a very specific example for the discussion...

My 2 cents,

Julius