Problems with hosting WCF in IIS
Problems with hosting WCF in IISOld forum URL: forums.lhotka.net/forums/t/8431.aspx
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
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, 2010Thanks!
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.
k2so replied on Friday, January 29, 2010I 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?
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, 2010Thanks 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, 2010Thank you for sharing your results - I'm sure that'll be very useful to someone else!
Copyright (c) Marimer LLC