I am building a WCF-based services that will be deployed to a hosting
company. This company uses HTTPS front-end devices that handle all the
SSL. So, an incoming HTTPS request is received by the front-end
device, decrypted, then forwarded to an internal server as an HTTP
request. My service will be deployed on one of the internal servers.

The problem that I am having is that WCF doesn't seem designed for
this scenario. Here's the situation:

* The WCF service uses the basicHttpBinding for interoperability
reasons
* Simiarly, for interoperability reasons I need message level security
with a username token
* WCF will only allow this with TransportWithMessageCredential
* TransportWithMessageCredential only works with HTTPS endpoints
* As noted above, I can't have an https endpoint because HTTPS
processing is done on a front-end device



Note that this scenario is essentially the same from a security
standpoint as if the HTTPS processing was being done on the machine
hosting the service -- the network connecting the front-end device and
the service hosting machine is private and secured.

Any suggestions on how to get this to work?

Given that many hosting providers will use similar HTTPS off-loading
architectures, this seems like a scenario WCF should be able to
handle.

Terry.

On my F5 setup, I believe the network team configured it so that the
F5 deals with the public SSL and compression, and then there is a
second SSL session between the F5 and the web-farm. This makes WCF
happy, but given that the F5 -> web-farm connection is well-secured, I
share in the frustration. It would be nice to have an "and I really,
really know what I am doing; please accept http traffic as secure"
option.

Marc

On Oct 16, 11:36 pm, "Marc Gravell" <marc.grav...@xxxxxx> wrote:

> On my F5 setup, I believe the network team configured it so that the
> F5 deals with the public SSL and compression, and then there is a
> second SSL session between the F5 and the web-farm.

It turns out that this would be difficult to do in my case. The IIS
that the WCF service is running on hosts a number of services all
hosted in a single IIS instance. These services have different
external DNS names and IIS only allows one certificate to be installed
per instance of IIS -- it turns out that the certificate that is
already installed in the IIS instance does not correspond to the DNS
name that my service is associated with. So I can't actually get an
HTTPS connection from the front end device to the internal server.

Terry.

Per IP address, surely. My farm also serves multiple sites, each with
different public DNS and SSL. We did it thus:
Add some IP addresses to IIS
Associate each site with the suitable IP (for https) and host-header
(for http)
The nlb (f5 BIG-IP in my case) usually has an option to "ignore" or
"require" validity on the certificate from the individual server; set
this to "ignore" (the default) so it doesn't matter if the servers all
have certificates for "mysite", and your load-balancer is asking for
"farm01"
(presumably the nlb also has the "mysite" certificate for the public
DNS)

Then the chain of events is something like:
client gets public IP for "mysite" from DNS, and connects to the nlb
nlb returns the "mysite" certificate to the client; host matches:
client is happy
client and nlb negotiate a shared-secret
client makes request to nlb (using client<-->nlb shared-secret)
nlb decrypts request using (using client<-->nlb shared-secret)
nlb selects a web-server and gets the private IP; connects to
web-server
web-server returns the "mysite" certificate to the nlb; nlb doesn't
care about the host
nlb and web-server negotiate a shared-secret
nlb makes request to web-server (using nlb<-->web-server
shared-secret)
web-server sub-contracts response to WCF, which is happy since we are
talking over SSL
web-server encrypts (using nlb<-->web-server shared-secret) and
returns response to nlb
nlb decrypts response (using nlb<-->web-server shared-secret)
nlb encrypts response (using client<-->nlb shared-secret) and returns
response to client
client decrypts response (using client<-->nlb shared-secret)

It looks like a lot of steps, but it works well for us; I believe that
most of the certificate and negotiation steps are cached and
optimised, so it isn't quite as bad as it looks...

Marc

A minor aside; I found that IIS had some issues in the host-factory
when multiple (http) sites were available on the IIS instance while
talking over https; it complained about having multiple "http"
addresses (which of course, we don't even care about). Failing to find
a better way, I fixed this by using a custom host-factory (about 5
lines of code) which limited it to serving https (it completely
ignores http requests). Let me know if you are interested in this and
I'll post it.

Marc

Well, here is a solution; MessageLevelSecurity is supported by
BasicHttpBinding. But ASP.NET web services do not support message level
security. Therefore use WSE 2.0 or 3.0 depending on the framework since WSE
supports WS-Security. WSE can communicate with WCF through the endpoint based
on BasicHttpBinding.

"tcoatta@xxxxxx" wrote:

> I am building a WCF-based services that will be deployed to a hosting
> company. This company uses HTTPS front-end devices that handle all the
> SSL. So, an incoming HTTPS request is received by the front-end
> device, decrypted, then forwarded to an internal server as an HTTP
> request. My service will be deployed on one of the internal servers.
>
> The problem that I am having is that WCF doesn't seem designed for
> this scenario. Here's the situation:
>
> * The WCF service uses the basicHttpBinding for interoperability
> reasons
> * Simiarly, for interoperability reasons I need message level security
> with a username token
> * WCF will only allow this with TransportWithMessageCredential
> * TransportWithMessageCredential only works with HTTPS endpoints
> * As noted above, I can't have an https endpoint because HTTPS
> processing is done on a front-end device
>
> Note that this scenario is essentially the same from a security
> standpoint as if the HTTPS processing was being done on the machine
> hosting the service -- the network connecting the front-end device and
> the service hosting machine is private and secured.
>
> Any suggestions on how to get this to work?
>
> Given that many hosting providers will use similar HTTPS off-loading
> architectures, this seems like a scenario WCF should be able to
> handle.
>
> Terry.
>
>