We have implemented webMethods B2B server using a reverse invoke and the b2b server clustering configuration. Our company firewall is between the them. Can anyone explain if and why it would be necessary to implement the use of digital certificates between the reverse invoke and b2b servers ?

You shouldn’t have to use Digital Certs to get through the firewall.

Most – if not all – firewalls disallow reverse invocations. By definition, that is the main purpose of a firewall. The firewall is designed to keep the data which did not originate within the trusted network (i.e. behind the firewall) from accessing the trusted network. If you are using a reverse invoke, chances are that there is a better solution to your business problem.

Two of your options are:

1. Edit your firewall configuration to allow the reverse invoke (which is not recommended and will probably earn you a verbal beatdown from your Security folks)
2. Initiate the server request from inside the firewall.

That said, reverse invoke has been successfully deployed by many organizations.

The b2b server is behind the firewall and is initiating the communication to the reverse invoke server in the dmz. Is it still necessary to implement digital certificates between the two servers ? Is there any way for this configuration to be hacked ? Is there any webMethods or other documentation that could help explain this ?

Digital certs between the internal box and the dmz would be necessary if you were worried about the reverse invoke connection being initiated with an unsecure DMZ. Consider the situation where the DMZ is compromised and the internal server initiates a connection to that invaded system. Then any calls made to the compromised system will propogate through to the internal server. This can be thwarted, however, if you use https for the proxy port on the DMZ and require client authentication. All trusted client certs are held on the internal box (authentication is done there, not on the DMZ).

In my experience SSLSOCK connections (as opposed to the unsecure SOCK connection) are extremely slow and unneccessary if you implement https through the proxy and require client certs.

In general, I’ve found security to generally accept the reverse invoke idea since only outbound rules are needed. I haven’t run into the firewall issues that Dan has (but I don’t doubt that they exist!)

Regarding Moriti’s comments:

Because digital certs are strictly for authentication (and not for encryption), it is not required to use them between the two B2B servers in your architecture. The digital certs will only confirm that the initiating machine is who it says that it is.

There is no way to make your system 100% secure, but there are certainly lots of measures that you can take to reduce the likelihood of a hacked system.

As Michael Farrell wrote:

"Your goal in the Security World is to do two things:

1. Do everything possible to reduce the chances of getting hacked
2. Minimize the exposure and possible damage that a hacker could do if it did reach a machine."

The first point is obvious, he writes, but the second is often ignored.

He lists these precautionary measures:

"Don’t put anything else on the machine in question. That includes files, databases and applications.

"Don’t give accounts on the machine to people that don’t need it. And even then, make sure that the people really need it.

“Don’t allow the machine to have privileges to communicate with any other box other than ones that are needed for the machine’s primary function. And even then, make sure that the other box is needed for the machine’s primary function.”

Joss makes some great points about SSLSOCK connections and the relative speed of connections of that type versus the benefits. However, each integration has its own personality and you may find that none of the solutions in this thread fit your plan.

For more information on these topics, webMethods Advantage (http://www.advantage.com) has some materials on security, IP Deny, and other built-in features of the webMethods B2B Server/Integration Server software.