Question on SE97

[Former Member]

We have a question on turning off authorization checks via SE97.

Our issue is that when users execute WA03, the program calls WA08 which is not in the user role. We do not want to add WA08 to the user but instead would like to turn off the check on WA08.

We went into SE97 and turned off the check for WA08. When we test, the program is still checking for WA08 and the user gets message "You are not authorized for WA08"

Did we miss a step or did somehing change?

We are running ECC6.0

(the change did raise a transport which we have not moved to other systems but the testing was done in the same system where the change was made)

Thank you

[Former Member]

I had faced similar issues , internal calls would crop up with transactions not in the role.

The best option we chose is in SU24 open transaction WA03 , be in change mode add S_Tcode and its value as WA08

save and transport wherever required for testing , remember to update the role.

In this method advantages:

1. User cannot execute WA08 directly

2.User will not see the transaction in the menu

3.It will not bring in the authorization objects related to WA08

4. It will sit in the standard authorization object S_tcode.

[Former Member]

Are you saying we would have to manually add WA08 to s_tcode in the role?

Or would it be automatically be brought in after SU24 was maintained?

[Former Member]

I did as you said and the user can execute WA08 directly even though it is not on their menu.

That is what we were trying to avoid.

I added a check to S-tcode on WA08 in SU24 for WA03. Added WA03to the role and it did bring in WA08 in the back.

But WA08 is alo executable directly for the user.

[Former Member]

You should not believe ST01 traces at face value. Take a carefull look at [SAP Note 1373111|https://service.sap.com/sap/support/notes/1373111] and consider going back to correct some roles in your previous projects....

@ Bobby: There is one restraint in SE97 for some complex transactions. When the transaction is called without a tcode check but with parameters (so the calling transaction must take care of the security!) then a confict arises as system field sy-tcode is set to the value of the called transaction. If the user has the option to navigate further and then back peddle then this context is lost and they have full access again to the screen 1000.

For this reason, some transactions check their own context regardless of the origin of the calling transaction (function module AUTHORITY_CHECK_TCODE) and if tcode = sy-tcode then it is checked again.

You could try to instruct the system in Se97 for a tcode to trust itself (no-check). The check is still performed always via the ok-code or menu or foreign CALL TRANSACTION constructs, but if the user is already on the inside then the application must take care of the context of the call and try to keep it.

This is very difficult and will most likely result in the same as the user being able to start the tcode directly.

It is very application coding specific. SE97 treats it generically from a central point to give the application coding the option to use.

Hope that makes sense...

Cheers,

Julius

[Former Member]

Please make sure you dont have any other role having WA08, please disable the manually added object S_tcode

from your role.

I am almost positive that WA08 should not work , let me go through the objects for both WA03 and WA08 and get back to you.

in the meanwhile make sure that WA08 is not in any role via S_tcode etc.... for the test user.

[Former Member]

Julius,

This finding was not through ST01!

For example:

User executes WA03 , you get error at the bottom of the screen you do not have authroizations for WA08.

but your business scenario does not want WA08 transaction to the user. This was very rare case may two instances among

14 megaprocesses.

[Former Member]

Did you update the role, in case you did let me know how

after all the steps you mentioned did you use Expert mode or authorization data tab in PFCG?

[Former Member]

Well that is what Se97 is for, but it does not work in all cases.

Variant transactions and Enjoy transactions are well documented cases.

Lets see what Bobby comes up with and the user's report back to him.

Cheers,

Julius

[Former Member]

I used the authorization data tab in PFCG. It did not bring in any other objects nor did it change anything. I just needed to generate the profile.

[Former Member]

Are you a JAVA developer?

[Former Member]

I am not sure of your SAP version but look at SAP NOTE 515130