Access WCF-service behind firewall from DMZ

I'm about to develop an service for a customer. The service will be located on the intranet behind firewalls and have a database of its own. The service will be consumed by another Web-application located on the DMZ. Now, my problem is that the company has a kind of strict policy not to open any ports from DMZ into the intranet.

1) Is it possible for my Web-app on the DMZ to access a WCF-service on the intranet without open a port?

2) If not, is there any reference architecture describing that opening a port may be done and still have a safe solution? Perhaps combined with certificates, some kind of athorization etc. There is no need for any other app to consume the s开发者_运维知识库ervice (at least not for now), so it is ok to have a configuration that limits the consumers to this single web-app.

Best regards /Valle

I had to "refine" my previous answer a little, by deleting it all :)

So here's the short, better version of it. Not the best one, but it works pretty good. To make the explanation simpler let's consider you have a single service and a client that wants to consume it.

1. add a proxy server application that runs outside the firewall and exposes 2 services:
   the first one is identical to the original service (same address, binding, contract)
   the second one is a duplex service that has as its callback the same contract of the above service
2. add a proxy client application that runs inside the firewall and consume the second service of the proxy server and also the original service
3. the original client will consume the proxy server instead of the original service

How it works:

1. the proxy client connects to the proxy server and register the callback
2. the proxy client also connects to the original service
3. the original client connects to the proxy service
4. the proxy server forwards all the calls from the service to the callback (remember the contracts are the same)
5. the proxy client forwards all the calls from the callback implementation to the client of the original service (again the contracts are the same)
6. the original service process the call and returns the result
7. the replies are forwarded back in the opposite order up to the original client

Note that the original client has no idea that it connects to the proxy server instead of the original service

Another note is that the forwarding happens in the code which is not very nice. The WCF in .NET 4.0 has routing support but I'm not sure you can route only the callback channel and not also the direct one.

Hope it helps, Gicanu