SEEBURGER AS2 Adapter Security

[Former Member]

Hello,

I am running into an issue on the install of the SEEBURGER AS2 Adapter. We currently have other AS2 communication software in place, which are in our DMZ for security purposes. However, we do not want to put our SAP XI server in the DMZ because we would like it more protected. We are getting around this problem by using a reverse proxy scenario to get it through our firewall.

Is there a more effecient way to install the SEEBURGER AS2 adapter without exposing the entire SAP XI server to the DMZ?

Thank you, any help or advice would be appreciated.

[Former Member · Accepted solution]

Hi Carley,

I will tell you something about Seeburger Adapters in detail, Just see if it helps...

Seeburger EDI Adapter provides an EDI solution on internet via HTTP or AS2 to replace the expensive VAN. It provides some pre-built mappings for IDOC to ANSI X12(810,850,855,856 etc.,) and Idoc to EDIFACT(ORDERS,DESADV,INVOIC etc.,) and has the ability to build your own. These pre-defined mappings transform the IDOC-XML to EDI-XML format.

These transformed EDI-XML messages are then converted to EDI specific format using the Seeburger's BIC(Business Integration Converter)adapter. In addition, Seeburger provides adapters like AS2,FTP(EDI specific) and so on to route these EDI messages to external EDI Partners.

Seeburger EDI Adapter leverages SAP XI's Adapter Framework. This Adapter is used to perform conversion between EDI and XML format. It also provides some canned EDI layouts and the ability to build your own. It is used to transfer the EDI message via HTTP or AS2 protocols.

The most direct way of using the Seeburger adapters is to configure the BIC as a module. There is a software component from seeburger called bicmapper which will allow you to do the following:

1. define or import the inbound message metadefinition in various formats ( edifact, xml,...)

2. using a mapping create an xml variant as the output metadefinition or edifact in the other direction.

3. create a one to one mapping between input en output.

4. export the metadata in xsd or sda format for import in XI

5. generate an SDA which can be deployed in XI and used as a module.

Please go through the following links which clearly explains what you want and it also helps you in understanding the same in depth:

http://www.seeburger.com

http://www.seeburger.com/fileadmin/com/pdf/AS2_General_Overview.pdf

http://www.seeburger.it/fileadmin/it/pdf/2005_04_sapphire_Ferrero_transcript.pdf

http://www.seeburger.com/fileadmin/com/pdf/SEEBURGER_SAP_Adapter_engl.pdf

http://www.seeburger.com/fileadmin/com/pdf/Butler_Group_SEEBURGER_Technology_Audit.pdf

http://www.sap.com/france/company/events/2006/02-01-Automotive-Seeburger.pdf

http://h41123.www4.hp.com/presentations/ISUG/XISeeBurger.ppt

http://www.sap.com/asia/company/events/nwtechdays/presentation/australia-slides/Pre-Built_Integratio...

Regards,

Abhy

[Former Member · Accepted solution]

Abhy,

Thank you for the information. However, this still does not tell me about my original question (the security issue). Is there a way for the SEEBURGER AS2 adapter to be installed without putting the entire instance of SAP XI at risk in the DMZ?

Thank you.

[former_member431549 · Accepted solution]

I don't have first hand experience, but I believe you could deploy a de-centralized adapter engine in the DMZ, running the Seeburger AS2 adapter. This server would have an install of the SAP J2EE stack. You would still need to be able to let IS and AE talk across firewall, but this would be another option as compared to reverse proxy.

We are looking at the Seeburger AS2 solution and I have thought about both of these options as possibilities.

[Former Member · Accepted solution]

We are solving the problem by having a reverse proxy in the DMZ. The proxy decrypt the SSL message and then forward the message to the XI system.

The proxy only allow trafic to the XI system and the url /AS2Server, it is therefore not possible to use other services at the xi system.

[former_member431549 · Accepted solution]

The problem with this approach is that decrypting in the DMZ is a security risk. You're better off having the proxy pass it to a server in the trusted segment of your network.

[Former Member]

The way you are using is the most common-seen

way. Why you need other ways?

Please give points. Thx.

[Former Member]

Thanks for the information Greg. Yes, other options would be great just to compare.

Thank you.