GRC Compliance Calibrator 5.3 and the "action" field for S_TCODE.

[Former Member]

Dear GRC gurus,

I have read the threads here on the search terms for the "action" field in the "function" definitions, but not found a clear answer... so forgive me for asking a possibly obvious question.

When implementing the technical rules for the function, it seems that the "action" field is included in the check even if it's value is not in the "permissions" of object S_TCODE. But there is no "look up" nor validation (how could there be from the Java system?) on what that value is.

Appart from the fact that one might be tempted to enter some nonesense text in there, what is the logic behind the checks in the coding if it happens to fit a tcode name and is this field truncated at any points?

The reason for asking, is that we have some critical functions in the system for which we do not care how the user gets to it (tcode's... , rfc's..., service's... etc) but want to analyze whether the users can infact use the function (as opposed to attempt to start it). This makes sense in many business functions, and for the "basis" stuff which is critical it should be clear).

What we wanted to do was "name" the action by it's well known transaction code (in a symbolic sort of way, for the business users... to be able to recognize it, symbolically... although S_TCODE does not have an activity field........) but not have it checked in the rule set at the technical level. The standard delivered rules seemed to do the same thing... but we are still stuck on the s_tcode check because we dont want it in some cases and have good reasons for this.

- Can anyone confirm how this really works? For example wild carding FB* as the action name?

- Assuming our above analysis is correct, which tricks can you recommend (add a "dummy" action?; add a * action?; a possible naming convention?) to shed the harness of the tcode check (or having to document all of the buggers in the actions...) but still make it useable for the only slightly technically inclined folks who do understand that there are enough tcodes or it is critical enough that we should not rely on the "very general" protection provided by tcodes?

Bad news, future insights and work-arounds are all welcome

Cheers,

Julius

Edited by: Julius Bussche on Dec 10, 2008 11:30 PM

[sam_szafranski3 · Accepted solution]

Note 1225227 - How to upload the functions containing only permissions

hope this helps.

regards,

Sam SZAFRANSKI

www.axl-trax.com

[Former Member · Accepted solution]

Thank you Sam and also Kaushal for searching

This describes exactly what we were looking for and the manual load / merge was also the intention using the file as the "master" to maintain and not make changes within the application.

Thanks again. I will try it out.

Cheers,

Julius

[Former Member]

I suppose this thread answers the question I was stumbling on for the last few weeks as to how to define "Critical Permissions" in RAR 5.3 as it always complained about that there should be no TCodes associated with the permissions :).

Thanks

[Former Member]

So it is the menu....

See function module AUTHORITY_CHECK_TCODE, where used and "coupled" (SE97, etc...).

There seems to be no way to check object authority only, without actually creating a dummy transaction for it and also assigning it to the menu.

Assumed closed.

Cheers,

Julius