Extra level of security in ABAP for sensitive custom tcodes

[Former Member]

Hi All,

Is it a best practice to include this extra level of authority check in custom programs which are deemed as sensitive ?

CALL FUNCTION 'AUTHORITY_CHECK_TCODE'

So trying to execute the underlying program for a tcode with SE38/SA38 would still prompt a check on S_TCODE.

I see this check in some sensitive SAP tcodes, viz. SU01,SU22.

Your inputs would be appreciated.

Thank you

Abhishek

[Former Member]

This Looks like a terific initiative:

It seems that this line makes it impossible to run the program from SE/SA38 when the user does not have the authorisation for the T_CODE specified, I wonder if that T_CODE is assigned via SE93 or hardcoded in the ABAP??

PLS make it a standard in all your new designs

[Former Member]

Hi Auke

Thanks for that...it just came across my mind when I was trying to dig something. The best we can do with this is protect those sensitive tcodes.

Am just wondering how will it work with SE97? When maintained with a calling tcode, which check will take precedence, cause this T_code check is hardcoded! Any thoughts?

Thank you

Abhishek

[Former Member]

There have been a number of discussions about tcodes, how and when to check them and the function module 'AUTHORITY_CHECK_TCODE'.

Try search a search for: https://forums.sdn.sap.com/search.jspa?threadID=&q=authority_check_tcode&objID=f208&dateRange=all&nu...

I have also seen some comments in some SAP programs, which indicate that this is "the old way" of checking authority, and not a new way as you might be thinking... which makes a critical report transaction without security in the report seem like a stone age idea...

But it is very usefull, particularly for retro-fitting unprotected report transactions which might be used by more than one transaction => you can then instruct the system via SE97 to permit a submit of the report from a set of transactions and not just one.

But that it only limited to transactions.

Cheers,

Julius

[Former Member]

Hi Julius,

Thanks for that...

In fact, I did check the search before I posted, its a best practice I follow 😛

Even I did check the SAP comments on it being a bit old fashioned, however, was still wondering it is still a good check that can be used, particularly useful to prevent access to users having SE38/SA38.

Though redundant, it can actually be a handy check in some cases.. its something like.... "Old wine in a new bottle" (bad joke!)

Cheers!

Thanks you both, your views are most appreciated!

Abhishek

[Former Member]

Yes, I agree with you. There are critical cases where you want the user to have a specific transaction, they must be in that transaction code and no other, and they must be authorized to start the transaction (or perhaps only a part of it), otherwise nothing will happen.

And it can be very usefull for retro-fits of security checks.

>

> "Old wine in a new bottle"

Nope, that's not the joke about the 2 developers either.

Cheers,

Julius

[Former Member]

>

> Nope, that's not the joke about the 2 developers either.

>

Didn't follow you

[Former Member]

>

> Didn't follow you

Then you did'nt follow one of the threads in the search results to the end either

(It was just a little joke in an old thread)

Cheers,

Julius

[WolfgangJanzen]

Yes, it's recommended to check on S_TCODE (by using the function module AUTHORITY_CHECK_TCODE which also checks whether the transaction is callable or not) in reports which are associated to so-called report transactions.

[Former Member]

Hi Wolfgang,

Thanks for the info.

Am actually working on implementing this standard on the identified critical custom transactions. Appreciate all your responses and guidance 😛

[Former Member]

I know of a "solution" where a customer specific function module was created for customer specific report transactions. Not wanting to only use S_TCODE and / or S_PROGRAM... (which are an all or nothing in most cases, from the perspective of those two authorization objects).

A problem they encountered was that at some point one would like to be able to configure the thing further. For example, a global lock on a program (completely obsolete), or an exception handling flag, or a "super user only" restriction. Those requirements need to be scalable... so... which delivery class to choose? Or call function within itself.

The requirement was, to have one function module which is scalable to a multiple of objects (and IDs with field values where required) to retro-fit so-called report transactions.

'AUTHORITY_CHECK_TCODE' was very usefull.

Nightly greetings,

Julius