tags:

views:

19

answers:

1

I have the following setup:

  1. Server machine running a WCF service exposed via an IIS application that requires Windows authentication.
  2. A proxy server (Squid) requiring Windows authentication.
  3. A client machine running a Windows service which tries to make a connection to the WCF service through the proxy server. The service is set with a domain account credentials.

All machines are on the same domain. If I drop the proxy from the setup and set just the following properties on the client security binding, all works well:

  1. SecurityMode = TransportCredentialOnly
  2. Transport.ClientCredentialType = Windows

The connection is made successfully and the correct credentials are passed to the server.

If I add the proxy but drop the required Windows authentication on the proxy server, everything works fine too. The only setting I change here on the security binding is:

ProxyAddress = http://myproxyserver:3128

I can see the calls go through the proxy server with the correct credentials.

The problem is that when I set the Windows authentication requirement on the proxy server, the proxy server returns 407 error. When I check the log files, I can see there is no second attempt to respond to the 407 error with the correct credentials. The setting I add is:

Transport.ProxyCredentialType = Windows

Things I tried and didn't work:

  1. Set UseDefaultProxy - since this is a Windows service, it doesn't accept the default proxy.
  2. Manually set Windows Credentials in ClientCredentials.Windows (including domain).
  3. Add default proxy in app.config and machine.config.

Any ideas on what's going on and how to fix it?

A: 

Two things that might be the problem. First, and I can not be sure about this as I have not tried using a Windows credential with TransportCredentialOnly, is that transport security tends to be point-to-point. That means that an intermediate service, such as a proxy, would have to authenticate your transport credential itself, as well as reestablish the appropriate credentials for its repeat of your request to the real endpoint. Again, I am not certain how this works with a Windows credential...but given that it is a transport-level security setting, I would be doubtful that it can pass through the proxy without additional setup to ensure the proxy repeats the appropriate credentials. (Keep in mind, doing so effectively nullifies your security at the proxy...which in a controlled setting is not a problem, but can be in a real-world scenario.)

Second, the transport child element of the security element for your binding configuration should have a proxyCredentialType setting. If your proxy is interfering with your security, you may need to authenticate against the proxy itself. The proxyCredentialType setting defines what kind of proxy credential to use to authenticate against the proxy itself. You would then need to supply proxy credentials before you send your message.

jrista