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.
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?
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.