k2so posted on Thursday, January 28, 2010

CSLA / WCF 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="Company\Me" password="blahblah" />

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.

Is there any way to get authenticated properly without using the impersonate on the client config?
If we change to using certificate authentication, would it affect service operations that require impersonations (needed impersonations for file access on the network for example)?

This might not be a CSLA centric problem, but very much appreciated if anyone can offer some opinions on this.

ajj3085 replied on Thursday, January 28, 2010

In IIS6 and higher, you can set the Application Pool's identity, then turn off inpersonation in the web.config file. The worker process will then run as that user.

I haven't done cert. auth though, so I can't help you there.

If you don't want the server to be part of the domain at all... I don't really know how you'd get around that.

k2so replied on Thursday, January 28, 2010

Thanks!

One thing I want to clarify, to set the application pool's identity, I am assuming setting it on the client machine rather than the service, right?

tmg4340 replied on Thursday, January 28, 2010

Actually, I might recommend that you set an app pool identity on both web servers. They probably won't be the same ID either - the server hosting your WCF service can use a network ID which you can use to set access to your network locations et. al, which should eliminate impersonation entirely. It would also potentially avoid a "double hop" issue as well (though I'm betting that you won't run into that, considering that your client web server sounds like it's pretty much completely outside of your network.)

The only potential issue with this is in case you're taking advantage of the impersonated ID in the database for something like auditing. Were you to set up an app-pool identity on your service, your database would see the app pool ID, which is potentially diffferent from your impersonation ID.

HTH

- Scott

k2so replied on Friday, January 29, 2010

I tried setting an App Pool on the client machine in the DMZ, but it's without any network user information (again, for security); only local users are available to choose. I am thinking this won't work as the service can only recognize a network user. I haven't tried this fully yet, but are there any ideas on how to workaround this?

RockfordLhotka replied on Friday, January 29, 2010

Have you looked at the PnP WCF guidance book?

http://www.codeplex.com/WCFSecurity/

It has a lot of information on different WCF security configurations, including background and how to set them up.

k2so replied on Monday, February 01, 2010

Thanks Rocky! That's a very helpful document.

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.

ajj3085 replied on Friday, January 29, 2010

RockfordLhotka replied on Monday, February 01, 2010

Thank you for sharing your results - I'm sure that'll be very useful to someone else!