Diffrent Authorization in Background & Foregroung mode.

[Former Member]

Hi,

While posting a document in FI transaction it is calling some other transaction in Background.

Now this process should run as it is, but if a person tries to enter the second transaction in the command field then it should give a message "No authorisation".

That means the second transaction should run when it is called from other program but should not be run when it is directly run from the command line.

Please help me on the issue.

Thanks,

Sameer

[Former Member]

Hi Sameer

Check table TCDCOUPLES and the search for this.

Cheers

David

Edited by: David Berry on Oct 19, 2010 7:57 AM

[Former Member]

Sameer,

this is not possible.

if user have access to called tcode, then user can execute that tcode dirctly also.

regards,

Surpreet

[Former Member]

Hello ,

To ensure that the called transaction are also subject to authorization check please use SE97 to set the check indicator check in table TCDCOUPLES for the entry of the pair or called and calling Tcodes you can check SAP Note 358122

Thanks

Dheeraj

[Former Member]

Hi

SAP is working as designed - tcode A calls Tcode B (no check), user tries to run tcode B directly and is blocked correctly.

Do you want the user to run tcode B directly?

Cheers

David

[Former Member]

Hi,

Problem is TCode B is not blocked when he tries to run directly. I want to block Tcode B.

It should be allowed only if it is run by any other TCode.

Thanks

Sameer

[Former Member]

Hi Sameer

So, the user has both transactions in their menu and you want to remove the called transaction. Change the check/no check values in TCDCOUPLES via SE54 in DEV and test if removing the called transaction from the role has the desired effect.

Cheers

David

[Former Member]

Hi David,

Thanks for the input.

But in TCDCOUPLES that entry does not exists.

I maintained that entry in SE97 still it is not getting reflected in TCDCOUPLES table.

My Calling transaction is FAGL_FC_VAL and Called transaction is FBB1.

Please help me on the issue.

Thanks

Sameer

[sdipanjan]

> So, the user has both transactions in their menu and you want to remove the called transaction. Change the check/no check values in TCDCOUPLES via SE54 in DEV and test if removing the called transaction from the role has the desired effect.

>

This need to be done in SE97.

From the above discussion it seems the Called TCode is also added in S_TCODE or the S_TCODE is containing some range which is giving access to the called tcode directly. So tcode B need to be removed from S_TCODE or the range (if any) need to be modified.

You may also check the following SAP note to get some idea how Transaction Calls happen and when they don't work.

[Note 515130 - SE97 does not always work|https://websmp130.sap-ag.de/sap%28bD1lbiZjPTAwMQ==%29/bc/bsp/spn/sapnotes/index2.htm?numm=515130]

Regards,

Dipanjan

[Former Member]

That'll teach me to go off memory and not check properly )

Well done that man!

Cheers

David

[sdipanjan]

> My Calling transaction is FAGL_FC_VAL and Called transaction is FBB1.

>

These two Tcode doesn't have any Calling - Called relationship.

Regards,

Dipanjan

[Former Member]

Hi,

Yes they dont have relationship in TCDCOUPLES. So I maintained it through SE97 but still it is not getting reflected.

While running FAGL_FC_VAL tcode FBB1 is called internally.

Thanks

Sameer

[sdipanjan]

> Yes they dont have relationship in TCDCOUPLES. So I maintained it through SE97 but still it is not getting reflected.

> While running FAGL_FC_VAL tcode FBB1 is called internally.

>

If the Calling - Called relation is not defined in the program logic (see the [SAP Note 358122 - Function description of transaction SE97|https://websmp130.sap-ag.de/sap%28bD1lbiZjPTAwMQ==%29/bc/bsp/spn/sapnotes/index2.htm?numm=0000358122&nlang=E] ) then it is not going to work even if you create one entry in the SE97.

From one of the note documentation ([Note 1074943 - FBB1 - FAGL_FC_VALU tax stmnt for foreign currency valuation|https://websmp130.sap-ag.de/sap%28bD1lbiZjPTAwMQ==%29/bc/bsp/spn/sapnotes/index2.htm?numm=1074943]) I got an impression (of course I am not confident on the Functional part and so can't assure you) that these two tcodes depends on each other to work. Now the question is whether the simultaneous occurrence is a SOD issue or not. If not (check against a SOD analysis tool or atleast with a SOD matrix) then you can assign them together. Else, go for an OSS message.

Regards,

Dipanjan

[Former Member]

Hi Dipanjan

I've learnt something new today (two things if you count double-checking which tcode maintains TCDCOUPLES).

I've saved those notes to have a look at them properly tomorrow - thankyou for the guidance.

Cheers

David

[Former Member]

It depends on where the check is performed and how it is coded.

If the called transaction itself calls function module AUTHORITY_CHECK_TCODE and the calling transaction is performing a CALL TRANSACTION then you will at most be able to enter the initial screen and process it once only (CALL TRANSACTION executes an explicit "commit" each time it is called). Any attempt to save will block you, but menu options with further navigation might be possible /available.

If the called transaction itself does not call function module AUTHORITY_CHECK_TCODE, then you only have the option to hard-code it or turn the check ON in SE97. You cannot turn it OFF!

What you need to be carefull of and the reason why SE97 can be dangerous, is because the call to the called transaction might be passed through to the executing code based on a CASE ok-code statement and WHEN ok-code = ??? is a user input... This is a very easy programming technique to respond to user commands and accordingly can be found in the wild...

If the target transaction called has many screens which the user can navigate around in, it is always better to use the function module AUTHORITY_CHECK_TCODE in the initialization events, because the user will have access to the screens.

This means you cannot encapsulate the call into a certain calling scenarios using parameters from authorizations restricted by the calling application transaction, as it could be anything.

For the same reason, CALL SCREEN xxx STARTING yyy... should never be used in RFC-enabled function modules because they by design should not contain S_TCODE checks, but rather native S_RFC checks from the kernel.

The best solution and option for controlling security is to locate the AUTHORITY-CHECK statements in the forms, functions, methods, even update tasks, etc so that you always have granularity and correct / consistent system behaviour. That way you do not need to bother about tcodes too much and can use SE97 to only selectively turn some checks OFF where it makes sense.

You should keep these to a minimum... see [SAP Note 515130 - SE97 does not always work|https://service.sap.com/sap/support/notes/515130] and rather concentrate on secure coding.

Tcodes are very "fluffy" things...

Cheers,

Julius

[Former Member]

Thank you Julius

Nice explanation, it is very useful and new learning to me.

Firoz.