What is a "reverse invoke" setup

Skip to end of metadata

Added by Nathan Lee, last edited by Nathan Lee on Dec 08, 2004 (view change) show comment

Go to start of metadata

webMethods Reverse Invoke Explained

Reverse invoke (in the webMethods integration server sense) is a technique for allowing your server to be hidden behind a hard firewall to further reduce the possibility of a security compromise. I thought I'd give a quick summary of it here to perhaps demystify it for anyone unfamiliar with it.

Machines Involved
There are two machines involved, each running an instance of an Integration Server: the "internal" integration server which has your actual code on it, and the "proxy" integration server, which sits in the DMZ and has no code to speak of on it.

Ports Involved
So what you do on the proxy IS (Integration Server) is open up a proxy port ("forwarding port" if you like) for external systems to connect to. You also need a registration port open for the internal IS to connect to and keep connections open. What happens is that when you "register reverse connections" on the internal IS's web admin UI: the internal IS opens a connection from within the safety of a "hard firewall" (one which doesn't allow any outside connections to hit your internal IS's machine). It connects to the registration port on the "proxy" IS. Once this connection (or many connections generally) is established, it keeps the socket(s) open which allows the proxy IS to relay any requests that come in on the proxy port from the outside world.

View from the outside world

So all the outside world has to do is to invoke your services through the reverse invoke server is to make the call on that proxy port on the proxy IS. They appear to talk to the proxy server rather than your internal IS.

Practical Example
To put some numbers in to clarify the scenario.. (and because it's always easier when you have a concrete example).

On the proxy IS (running on machine MY-PROXY-IN-DMZ) normal admin port open 5555 to allow you to administer the thing change mode to be a proxy IS create a registration port (6666), and a proxy port (7777)

On the firewall between internal and DMZ Block any incoming (DMZ to internal) requests. Allow outgoing from MY-INTERNAL-IS to MY-PROXY-IN-DMZ and any external servers it opens connections to (e.g. a trading partner that you send data to).

On the internal IS (running on machine MY-INTERNAL-IS) create a remote server alias for your proxy IS (to host MY-PROXY-IN-DMZ, port 6666) register reverse connections (to the alias above, say 10-20 connections)

On the DMZ's external firewall: Open up incoming requests to get to the proxy port (7777). Allow outgoing from MY-INTERNAL-IS to any external servers it opens connections to (e.g. a trading partner that you send data to). Do NOT allow access to the administration port from the outside world. Although it's password protected, there's no need to administer it internet-remotely (generally).

Your external partners, partner businesses, internet entities: Invoke the service using host MY-PROXY-IN-DMZ, port 7777.

Tips and tricks

It is advisable to really lock down and minimise the proxy IS, as you aren't going to be using it for running any code, so chop out any example packages, disable any developer accounts, change the admin password (should be done anyhow), make sure it's in the rc.init scripts to auto start up. You can then generally ignore this IS as it will just stay running and relaying requests. On the internal side, I'd advise scheduling a service which checks on the reverse invoke connections periodically and ensures they are up. In the case of a server restart with the proxy down, it will not recreate those connections. Be proactive with monitoring and set things up to email you if it can't recreate the connections when down. To find out the service, check what the "register reverse invoke connections" screen does. In 6.1 there is a pub.security.reverseinvoke folder in the WmPublic package that will help out a lot. Versions prior to this: check what the DSP is doing and emulate it. The protocol that is used to communicate back along the reverse invoke socket is called SOCK (or SSLSOCK if you want to use SSL), and relays all the request information except for some of the HTTP header information. If you have to stop both IS's, when you start them up do the proxy IS first (it should be faster anyhow as it will have a minimal install and minimal packages). Restrict where the admin port can be invoked from and make it an HTTPS port. This will further reduce the risk of someone hacking the proxy IS The proxy IS does NOT do the communication for you if you make an outgoing HTTP, FTP, SMTP connection from the internal IS. It's purely for incoming connections.

Check with webMethods about licensing, as I believe it's generally regarded as another CPU. The number of reverse invoke connections you create should be the peak number of concurrent requests you expect and a margin of error to allow for growth. Like any performance tuning, experiment to see what works best.

None

3 Comments
Hide/Show Comments

1. Mar 05, 2006

amrutharaj Hi Nathan Lee, It is a good article especially for the first time setting the R
Hi Nathan Lee, It is a good article especially for the first time setting the Reverse Invoke Proxy. What I don't understand is that do I need to deploy any flow service in Proxy that receives the document from the external and then invoke an appropriate service in the Internal IS via whatever the port configured between Proxy and Internal IS? Could you please clarify my doubt? Thank you With regardsAmrutharaj

Permalink

1. Mar 06, 2006

Nathan Lee Hi Amrutharaj, you do not generally need to deploy any of your code on the proxy
Hi Amrutharaj, you do not generally need to deploy any of your code on the proxy Integration Server. The proxy Integration server merely routes your invoke requests to the Internal integration server. There are a few cases where you may have some code executing on the proxy IS, but generally the proxy IS does very little except pass the requests on to the internal IS where your code lies and is executed.

So when you invoke your service from the outside world you will *think* that you are invoking the service on the proxy IS's proxy listener port then the proxy IS will pass that invoke request back along the network to the internal IS and then return the results after execution has finished. Hope that clears that up. regards, Nathan Permalink

2. Feb 25, 2007

Mayank Baluja Hi Nathan, Can we use a reverse Invoke IS to act act as reverse invoke server f
Hi Nathan, Can we use a reverse Invoke IS to act act as reverse invoke server for different environments. ie use the same IS to talk to many IS'es by configuring different ports. If yes pls advise how it can be done? Also, can we use one reverse invoke IS to redirect calls to two IS instances hosting two different applications, If yes how? Regards M