BAPI rfc security through java services vs. gui tcode /object

[DanH1]

Hi folks,

In my company we are beginning to implement java services connecting into our R/3 instances. This is posing security differences. Where as when you are logged into the R/3 directly the stantdard tcode to object is in effect. Through the java services a BAPI only needs an RFC authorization to function.

Wondering if anyone has any security guidelines or compliance thoughts on java services connecting to SAP instances. Is there a general acceptance that the java functions themselves are the security controls to the backend system ?

[WolfgangJanzen]

Please notice:

- there are (basic) checks which are performed when an action is started (-> start authorization check), e.g. when starting an ABAP transaction, an remote-callable ABAP function module, an ABAP report, etc.

- there are (more fine granular) checks on specific actions (-> instance-level checks), e.g. checking whether a user is allowed to display a specific invoice

Usually, a functional unit (RFC function module / ABAP transaction / ...) should trigger those instance-level checks. The runtime will perform the start authorization checks (before starting the functional unit).

-> S_TCODE and S_RFC checks are just entry-level checks

-> the (application-specific) instance-level checks should be identical for both, RFC/BAPI access as well as ABAP transaction access (via SAPGUI) - irregardless of the access protocol

[DanH1]

Thank you , but all i am seeing is a S_RFC authorization with a bapi name to display an article. Through the gui

the user needs i.e MM43 with associate tcodes.

is there some way the developers need to invoke the similiar authorizations by tcode ?

[WolfgangJanzen]

Well - this is then a negative example.

I encourage you to report this to SAP - asking to modify (-> correction) the BAPI in that way that it performs the same authorization checks as the functionally equivalent transaction (you can add a [reference to this SDN thread|]).

In an ideal world, all functional units should provide an API - and the UI should just use that API.

[Former Member]

Is the BAPI returning anything? Some of them require the structures to be activated, for the BAPI to actually work and at that point the authority-checks kick in.

Cheers,

Julius

[DanH1]

Thank You Wolfgang ..i will continue to look into

[DanH1]

Yes, the trace shows the BAPI call is hitting the S_RFC

authorization object, showing the Z function group the developement team has made. Can these by structured to

invoke the same authorizations by tcode and object ?

on gue side the user would have to have MM43 and the associated objects ?

[Former Member]

> Dan Hendrican wrote:

> Yes, the trace shows the BAPI call is hitting the S_RFC

> authorization object, showing the Z function group the developement team has made.

Which BAPI is your own z-BAPI calling? Possible reasons are:

- There are no checks in the BAPI => report it as advised by Wolfgang.

- The BAPI call is on a different server (not the one with the trace activated).

- The BAPI call is in a different user context than the one you activated the trace for.

> Can these by structured to invoke the same authorizations by tcode and object ?

> on gue side the user would have to have MM43 and the associated objects ?

Normally you would not want a tcode check in there (in RFCs). The entry point is the function group (S_RFC) and not the GUI transaction (S_TCODE).

As mentioned by Wolfgang already, you would want and expect the associated object checks to be the same. That way the user has the same access (and the same role), regardless of the entry point they choose to use or are given access to use.

In transaction SU24, you can in higher releases also maintain authorization defaults for function modules and your own custom tcode or RFC "entry points".

In lower releases, a work-around is to create "dummy" transactions.

Please tell me the name of the BAPI (not your z-BAPI).

Cheers,

Julius

[WolfgangJanzen]

>

> Yes, the trace shows the BAPI call is hitting the S_RFC
> authorization object, showing the Z function group the developement team has made. Can these by structured to
> invoke the same authorizations by tcode and object ?
> on gue side the user would have to have MM43 and the associated objects ?

Well, if you have created your own RFC-enabled function module (<- Z function module group) then you have to ensure that your coding is triggering AUTHORITY-CHECKs (and evaluates the result). You can call the ABAP function module AUTHORITY_CHECK_TCODE to perform the same checks as when a transaction is started via SAPGUI - notice: that refers only to the start authorization checks.

As mentioned previously, instance-level checks (on concrete values / actions) will have to be triggered (in your coding) in addition.

[DanH1]

Thank you Wolfgang and Julius,

I have sent an email to our developer with the info of the

authority checks to add in. He has added the checks and i now see the S_TCODE authorization as well as associated

auth objects with the tcode ..much thanks.

I am not a developer....wondering if you have any links to understanding BAPI's ,function groups , etc.

[Former Member]

Take a look at transaction BAPI for a start.

Via the menu "Go to" => "Environment" => links to documentation.

or

Choose / display the BAPI found, and select "Function Module Documentation".

or

Explore the Security Guides on service.sap.com. There are some on RFC.

Cheers,

Julius