Best practice usage of system users for different RFC functions execution

[Former Member]

Hello experts,

Could you guys share your thoughts on RFC type 3 - system userid usage:

Would it be recommended to use ONE RFC destination (type 3) for execution of various functions?

Is it recommended using the different RFC destinations (type 3) (with different system user ids) depending on the functions execution?

Thanks in advance for your thoughts.

Thanks

Himadama

[Former Member]

> depending on the functions execution?

Exactly that is what you should consider for users with saved logon data. A better alternate sometimes not to save the logon data...

The search term you are looking for in your doubt is "cardinality". Please also see the Security Wiki (there is a link in the FAQ thread).

Historically, some config "wizards" will tempt you into defining a "default" user. But you can change it, or ignore it.

The logical system name (as destination name) is still a restraint to make your life easier - but here you can also use the current user option, or trusted RFC, or a real SSO which authenticates the client user and not the chain-of-trust.

The wiki will explain this in more detail, as it has been asked several times before. Having said that doesn't make it easy, and it is a hard days work but important.

Cheers,

Julius

[Former Member]

Thanks Julius for your information.

Option 1: System user id / password:

Password is sent over the network. But SNC control would take care of this.

1 destination = 1 system userid

If the useru2019s password is compromised the risk would be limited to that destination function group (RFC_NAME in S_RFC auth object)

System users only need RFC authorizations (S_RFC).

Only monitoring System users would be enough.

Better password management if required.

Option 2: u201CCurrent Useru201D option:

One user may need access for more than one function groups access ( RFC_NAME).

Compromising user's password would result more damage than the system user. Since this user has broad access to execute multiple function groups.

Monitoring these users would be overloaded job in this case becoz of increased users numbers.

The management of authorizations (roles) to these users may require strict approval process.

Option 3: Trusted system option:

u2022 RFC_SYSID :

u2022 RFC_CLIENT:

u2022 RFC_USER : ' '

u2022 RFC_EQUSER: Y (for Yes)

u2022 RFC_TCODE : *

u2022 RFC_INFO :

u2022 ACTVT : 16

Seems user requires both the auth objects S_RFCACL and S_RFC in this case.

Compromising user's password would result more damage than the system user. Since this user has broad access to execute multiple function groups.

Monitoring these users would be overloaded job in this case becoz of increased users numbers.

The management of authorizations (roles) to these users may require strict approval process.

Would you say considering the system userid/password is better option than other methods with SNC control in place? Please share your thoughts.

Thanks

Himadama

[Former Member]

> better option than other methods

There is no absolute "better option".

It depends on the type of connection, the level of trust you have in the system invoking the call, the requirements to be able to audit the access or the calling system.

Some types of connections will for example not support the "current user" option (ALE distribution is the most obvious example) others will force you to use trusted RFC (SolMan effectively does this).

Once you get to know the types of connections, the applications using them, the RFC's in the target and the general user behaviour, then you gain experience which option is most suitable to which scenario.

> System users only need RFC authorizations (S_RFC).

This is not correct. Remote enabled RFC's should make appropriate application authorization-checks as well, or at the least validate their own config locally.

Cheers,

Julius

[Former Member]

This is not correct. Remote enabled RFC's should make appropriate application authorization-checks as well, or at the least validate their own config locally.

There are 31,850+ Remote Enabled SAP delievered function modules in ECC6.0 system, in that only 200+ are maintained in USOBX.

Does this mean authorization checks not required for all other 31,600+ remote enabled function modules.

In 200+ USOBX table, most of them require only S_RFC no other application specific authorization objects listed.

Some of them require more than S_RFC authorization objects.

For Example: RFC /ISDFPS/ME_MM_GMVMT_CREATE listed the following auth objects:

S_RFC

M_MSEG_BMB

M_MSEG_BWA

M_MSEG_WMB

M_MSEG_WWA

I also tested one custom RFC but the user is only requiring the S_RFC object. There is no trace for other authorization objects than S_RFC. So, Do i need to include the AUTHORITY-CHECK statement in custom FMs to force the application specific authorizations?

Also calling FM AUTHORITY_CHECK_RFC (based on source code) only checking authorizations against S_RFC auth object

Please share your thoughts.

Thanks in advance.

Himadama.

Edited by: Julius Bussche on May 19, 2010 7:46 AM

quote tags corrected formatting

[Former Member]

You cannot rely on SU22 to tell you whether a check is available in an FM or not.

You can however maintain SU24 to your heart's content for proposals. I always do now

Cheers,

Julius

[Former Member]

Thanks Julius for your information.

You cannot rely on SU22 to tell you whether a check is available in an FM or not.

I looked at the source code of the FM "/ISDFPS/ME_MM_GMVMT_CREATE" and noticed the SU22 maintained because within the program these authority-checks maintained...

You can however maintain SU24 to your heart's content for proposals. I always do now 🙂

The ST01 trace is source to maintain SU24 (SU22) auth objects(application specific) but in this case some of the standard function modules not coded with authority checks, so SU22 was not maintained.

Now I understand that the programmer who develops a custom FM have to find out (with the business&/security) and use the standard relevant authorization objects or custom authorization objects with in the code itself. This allows Security to maintain SU24.

Do you agree?

Thanks,

Himadama

[Former Member]

The idea behind function modules is "modularization": The same function can perform many tasks which do not need to be reprogrammed redundantly each time. This makes them very powerfull and dangerous from a security context.

If the calling program context of an RFC is known, and will be used consistently for a scenario you are using, then maintain the proposals for the objects and values as much as you can in SU24.

There is no real need to maintain "check only" indicators for them as the checks are still performed.

Maintaining SU24 by adding proposals for what you do use is a better option than SAP delivering all the possible checks for each FM in SU22.

If you do this carefully, you will get to know the RFC's fairly quickly. Ranging around naughty authorizations has anyway never been a good solution, and this is very true for RFC.

Good luck,

Julius

[Former Member]

Thanks again Julius.

There is no real need to maintain "check only" indicators for them

--But you should not have SU24 with "Do Not Check" since it switches off authority checks within the ABAP program(Frank's message: )

as the checks are still performed.

--The program should have some form of hard coded Authority Checks..( is there any other way again???)

The real problem with 7.0 kernel release systems in our environment is: We have a function group with more than 3 function modules(create, change, display(get list), etc). If I do not have application specific auth checks then one system user id (for rfc) with the S_RFC gives authorizations to execute all function modules within that group.

I do NOT want this...

I see two options here--

Either our developers need to maintain application specific authorization checks with in the function module or maintain one to one relation between function module and function group....

I am just trying to find out different options available for restrictive rfc security at function module level....

Thanks,

Himadama

[Former Member]

You cannot make "no check" indicators for RFC function modules. So that problem you have is taken care of...

But for turning checks on which are not there in the coding, there is no medication except adding them.

In this case, the system user has the S_RFC authorization and is calling the one FM from a fixed program context with validated import parameters by that program. So... on the client side of the call you can control the access.

See SAP Note 587410. If the caller can access the interface of the FM outside of the program context (i.e. in the testframe, or from an RFCSDK, etc) and choose the name of the function module, then your control level is lost.

> The real problem with 7.0 kernel release systems in our environment is: We have a function group with more than 3 function modules(create, change, display(get list), etc). If I do not have application specific auth checks then one system user id (for rfc) with the S_RFC gives authorizations to execute all function modules within that group.

I do NOT want this...

Yes I agree with you, an RFC enabled FM should make the correct checks with appropriate activities otherwise it is destined for misuse. One FM per FUGR is not a solution either, except for special utilities.

Cheers,

Julius