BAPI interfaces vs. IDOC interfaces communicating thru RFC

[Former Member]

I do not know much about this, but I thought that I would ask the Pro's on what they thought on this, here is the question that was asked:

The project team is discussing the option of using BAPI interfaces vs. IDOC interfaces when communicating with an external company (XXXXX). During the meeting today, XXXXX mentioned that we might not be able to limit security (RFC Only) for BAPI interfaces to a single function module. He was asking if one of you guys could take a quick look at the RFC access to see if we have the option to limit access for a generic account to a specific function module.

The version of SAP that we use is 4.6c applications with a 4.6d_ext kernel

Could someone help me out with this?

Thank you

Robert

[Former Member]

At your release you can only limit on the function group name level (RFC_NAME of object S_RFC). Further restrictions need to be at application object level to determine what the user can and cannot do, also within one BAPI FM.

You can anyway use restrictions on the client side, such that the users can only call the function module in that function group from a specific application context (transaction) and not freely select the name of the function module and influence it's import parameters directly.

But as these remote calling systems (the client side..) are sometimes not auditable for your user you are maintaining authorizations for (on the server side) it is advisable to give them only that which they do need as per "minimum authority" principle.

As of release 7.10, you can control RFC at the level of the function module name, in addition to the function group.

This also means that you can maintain BAPI* as if you were to give S_TCODE = * for released tcodes, and control authority at the application object level (if checked correctly within the BAPI).

Cheers,

Julius

[Former Member]

Julius

Thank you for the reply, this answered my question.

Robert

[Former Member]

As of release 7.10, you can control RFC at the level of the function module name, in addition to the function group.

We have SAP systems with kernel releases 7.0 and 7.10 in our SAP landscape. I just checked ST01 and SM20N in SAP system with kernel release 7.10 for RFC calls, it is no different from kernel release 7.0 in auth trace (ST01) and audit log (SM20N). The authorization trace is still looking for FUGR (Function Group) NOT FUNC (Function Module).

Now my question is, what would be the benefit of S_RFC RFC_TYPE with value FUNC while authorization check is NOT against FUNC?

Can anyone please share your thoughts on this? Is there any relevant SAP note that helps me to fix this?

(

Ex: ST01: RFC_TYPE=FUGR;RFC_NAME=SYST;ACTVT=16

)

Thanks,

Himadama

Edited by: Julius Bussche on May 16, 2010 6:29 AM

quote tags corrected

[Former Member]

You must first let fugr fail, then the check on func will kick in.

This makes the solution downward compatible without impacting existing roles.

Some FMs by design do not make checks or let you do more than what the intended FM does. Now you can grant access to just one FM.

Cheers,

Julius