BAPI user authorization

[Former Member]

Can somebody help with this please?

I have created two users Z_USER1 & Z_USER2

I want to restrict each user to a set of custom BAPIs eg ZBAPI1 & ZBAPI2

For instance Z_USER1 should only have access to ZBAPI1

Could you please tell me what transaction I would need for this?

Thank you!

[arpan_paik]

For specific FM it cannot be controlled. It can be controlled by Funtion Group, which can be found in attrebute for FM. Just like table authorization. Object type is FUGR. Object is S_DEVELOP

Edited : There are several transaction for the same. like SE37, SE90...

Regards,

Arpan Paik

Edited by: P Arpan on Jan 27, 2011 7:23 PM

[Former Member]

For specific FM it cannot be controlled. It can be controlled by Funtion Group, which can be found in attrebute for FM. Just like table authorization. Object type is FUGR. Object is S_DEVELOP
Edited : There are several transaction for the same. like SE37, SE90...

Sorry, but this is incorrect and bad advice. You cannot run and administrate an SAP system using the ABAP workbench test environment (single testing in SE37) and authorizing on S_DEVELOP to control it. That is for developers in development systems only - everything else is bloody dangerous and normally a symptom of bad programming or bad habits if requested!

If the BAPI is called locally WITHOUT the DESTINATION extention, then you do not need to authorize on the level of the BAPI name or group at all, as there is no check. You need to control via the program calling the BAPI and who has which authorizations to use it and in which way. The best place for appropriate authority-checks are anyway beyond the interface of the BAPI, so "on the inside", which control whether the user can complete the code and not depend only on their ability to start it.

If the BAPI is called externally WITH the DESTINATION extention, then the user in the target destination (not it might change!) will need S_RFC authorizations. As of release 7.10 the domain of the RFC_TYPE has been extended to include FUNC in addition to FUGR. FUNC is the actual name of the function module and not the function group, however the field is truncated at the 16th character, so only the first 15 are considered.

This means you can control external RFC at the level of the function module name in addition, if you have and use a meaningfull naming convention. You can check for included FUNCNAMEs via table TFDIR where the FMODE = 'R'. Otherwise for FUGR you need to use PNAME and considering the value right of *SAPL (which is the function group name).

Sorry for the rant...

Julius

[arpan_paik]

 Sorry for the rant...  

Ha ha ha...I keep note of your post. SDN ain't a site where I will post all the time. I learn many thing here as well.

Thank you for the rant....

Regards,

Arpan Paik

[Former Member]

Actually the ability to locally execute (activity 16 for S_DEVELOP) function modules from the workbench (see SAP note 587410) is the same as having SAP_ALL. You can control on the object name, but will have a tough time controlling it because there are about 300 thousand of the buggers - as this includes the ones which are not remote enabled as well.

Much the same as SAP_ALL, folks who claim that they cannot work without it are very suspect (and dangerous to the system).

It best to reserve this for emergencies only.

Cheers,

Julius

[martin_voros]

If we are talking about RFC then I recommend this [wiki|http://wiki.sdn.sap.com/wiki/display/Security/BestPractice-HowtoanalyzeandsecureRFC+connections].

Cheers