I’m involved in a project where SAP generates a EDIFACT that shall be sent from SAP via wM (to do some processing) to another application. Since this is payment transactions, the security demands are excessive.

We planned to install a “stripped” IS with the PKI module on the SAP server to sign the data before they are transferred to the processing IS on another server. This is due to the fact that signing i SAP seems to be quite an unknown area.

The main security issue for this solution is the tRFC connection on the SAP server. Is it possible to break in to this connection to 1) manipulate data or 2) pretend you are the SAP server to send a fake transaction ?

Seems that SNC option in SAP Adapter only is for inbound (to SAP) transactions, not outbound.

Anybody with experience/thoughts on this ?

rgds
oKloster

What version of IS are you using? How were you planning on signing the EDIFACT document? Were you going to use TN to do this or something else? What portion of the EDIFACT document is to be signed? What keys would you use to generate the signature and what public key would be included in the signed message so that the signature could be verified at the other end?

Mark

Thanks for replying.

We did get in touch with wM to answer these questions (see at the bottom), but I will try to explain the challenge in more detail in case somebody else run into a similar problem (long post…):

a) SAP is creating a EDIFACT (done in SAP for historic reasons) that is to be transformed to another format before it is delivered to a internal application. This message is signed by an old consultant-written unix-based tool that no one really can maintain before it is ftp’ed to a locatioin where wM can pick it up.
b) To ease maintenance and improve security, there is a wish to standarize signing and get rid of ftp.
c) Signing in SAP is (suprizingly) very difficult. Therefore we want to use WmPKI or just standard pub.pkcs7:sign. To avoid a tRFC connection between servers, we plan on installing a IS on the SAP server to make use of the SAP adapter 4.6 to receive the message before signing it and sending it further.
d) So then the question is: Since the unsigned EDIFACT is transported on a tRFC connection to the IS; is it safe ? That of course depends on your demands, but this is a point to concider when dealing with sensitive data.

The questions and answers from wM on this:

I have gotten some more information concerning your questions from our engineers.
Your questions/concerns:
1.) Is it possible to “break into” this tRFC connection which are between two internal services (sap and sap adapter), to 1) manipulate data or 2) pretend you are the SAP server to send a fake transaction ?
2.) It seems like the SNC option in SAP Adapter only is for inbound (to SAP) transactions, not outbound. Is this correct or does it work both ways?
3.) When SAP sends data tp SAP Adapter over tRFC: Who is actually initialising the communication? SAP or SAP Adapter? Is it correct to say that webMethods are logging on to SAP, and SAP are using this connection for the RFC? If yes, can we trust this? What happens with a reconnect? Eg. someone is stopping the “orignal SAP Server” and starting a “bad SAP Server” to produce fake transactions…
4.) Any other conserns regarding the RFC connection we should be aware of?

The answers:
1. Yes - theoretically it is possible to break into an internal RFC/tRFC connection, when the attacker is e. g. able to install interception tools locally. More important: An attacker could simply register itself as RFC destination in order to receive the data - that’s is very simple to do.
2. With SAP 4.6, SNC is only available outbound to SAP, not inbound. WmSAP 6.5 supports SNC in both directions. We currently have no plans to backport this into SAP 4.6.
3. tRFC is not really secure - there is no way to guarantee the identity of the sender of receiver with standard tRFC (see also answer 1).
4. We would recommend to use WmSAP 6.5. You could then use SNC which supports both secure connectivity and certificates to check the identity of sender and receiver.
[FONT=Tms Rmn]

rgds
oKloster
[/font]