Question

Here’s the desired setup:

• Service with wsHttpBinding is on IIS 6 on Machine 1 behind the firewall.
• Client is front end website on IIS 6 on Machine 2 on a DMZ.

We are currently able to authenticate the client using Windows authentication, but with impersonation

<identity impersonate="true" userName="OurCompany\Me" password="Blahblahblah" />

since the website would use the “ASPNET” as username, which is not in the domain.

We now want to move away from this method, because of safety issue; we don’t want to expose this kind of info on the DMZ.

1. Is there any way to get authenticated properly without using
   the impersonate on the client
   config?

2. If we changed so that we use
   certificate authentication, would it
   affect service operations that
   require impersonations (needed
   impersonations for file access on
   the network for example)?

thanks.

Answer 1

This has been resolved now, and I think it’d be constructive to share the solutions.

In terms of my original question – whether it’s able to do impersonation without setting it explicitly in the config or in the front end code. As mentioned by the above, the App Pool method does work, but only when both the client and server are on the same domain.

Since the web site client being situated in the DMZ has no access of the local network at all, meaning we are unable to impersonate any network user (this is a flaw in my original question, saying the impersonation works – it was actually not working).

So the only way to go was using certificate. Since this is internal communications, I have generated a test certificate on each of the server / client sides with the makecert. Using peer trust certificate authentications, I am able to get the communication working between the client and the server. This will ensure that no Windows / network user account information is presented in the DMZ zone.