Our client needs to call a webservice exposed by an external partner. Our client network configuration implies that only machines in the DMZ can call the external network.
The flow service from which the call to the webservice is initiated sits in an internal IS, which doesn’t have access to the “outworld”. We also have a gateway IS which sits in the DMZ and is consequently able to call the external network, but it isn’t designed to run any service, it only serves Reverse Invoke purposes.
I thought of placing a minimalist service executing the call to the external network on the DMZ IS, but as I said above, this is contrary to architecture design. I also tried configuring a simple HTTP Proxy in the internal IS, specifying the gateway IS as the Proxy Host, but it didn’t work. After reading the documentation about Proxy settings for outbound requests in Administrator’s Guide, I discovered that this feature is intended for third party proxy servers.
So my question is, does the IS have standard HTTP Proxy capabilities? If so, how do you configure an IS to use another IS as an HTTP Proxy for outbound requests?
The IS configured as “Reverse HTTP Gateway (RHG)” is for secure access from the cloud/world to the Internal Server, and not to let the internal server access the cloud/world.
The way IS connects to webservices is either directly or thru a 3rd party proxy, such Squid etc…
IS cannot be used as a HTTP proxy.
HOWEVER!!! if your requirement is only machines in the DMZ can access the “world” and this requirement is for a MINIMUN set of services you can do the following:
1- From Developer, and using the WSDL from the remote service, CREATE a connector on the RHG. This will create a flow service.
2- On the Internal Server, invoke the service running on the RHG (Using invoke service).
Flow will be: ServiceIS → ConnectorRHG → external server → RHG → InternalIS.
If that goes against the local policies, you would need to ask your IT for a solution, by either setting up a proxy, or open firewall communication for your Internal IS to that server.
We had indeed discussed the idea you suggested, but it would be against design rules, and it would be impractical because the machines hosting the gateway servers are not, in terms of resources, cut out to run services.
Hopefully our client will allow one of the alternatives.
Then in case using RHG as a proxy was possible (which is NOT), wouldn’t it break as well the design?
Your only solution is to get allowed to use a real proxy, or as mentioned open firewall for direct communication. In terms of security, proxy should be the correct way to go.
Well, the gateway server acting as an HTTP Proxy wouldn’t require it to actually run any service, which is what we really wanted to avoid.
Anyway, the client has accepted to let direct connexions from internal servers get through their firewall, so the problem is solved. As you said, it’s not the most secure way to go, but it’s their choice.