Ok, I've been working in Premier support for exactly 5 months now (to the day). I must have learned something interesting I can share with everyone. I mean it looks like the only blogger left alive on SOAPitStop is Anachostic (good stuff by the way David).
Well there is some good news, I've been spending time working on the distributed services PSS team as I continue to ramp up on dedicated engagements with custom solutions customers. That means I've been getting some really cool deep WCF issues to dig into. One of the most recent ones was a seemingly simple question about what happened to the PreAuthenticate switch between ASMX and WCF. I was sure I had just missed this property on some internal Http channel class .... wrong! I also figured this would be something plenty of people have already blogged about so there'd be no point in doing a long write up about this .... wrong!
Enough build up, here's the short of it. It turns out the PreAuthenticate flag is not something that can be easily controlled by you as a develoeper in the world of WCF. In fact, the underlying default channel factories will use your security settings to decide exactly how this setting should be set (ex. Basic auth gets PreAuthenticate by default, NTLM gets UnsafeAuthenticatedConnectionSharing by default). This is good and bad, on one hand I think there were a lot of developers that were unaware of the overhead associated with reauthenticating every HTTP request when PreAuth was turned off. I also think that it was a very misunderstood setting, in fact, until this most recent deep dive I had some misconceptions about how this worked too.
What I'm going to do is breakdown each of the main HTTP authentication schemes used in IIS and exactly how the WCF client proxies behave in each scenario. Along the way I'll explain the gory details of the HTTP stack and how to avoid significant overhead with your HTTP based WCF services. To reinfoce the behavior you'll see some snippets of IIS logs.
Basic Authentication: I'll start with basic auth as it behaves in the most straight forward way. If you have to use basic auth over SSL and you start using WCF you have nothing to worry about. If you dive into the code you'll find in the System.ServiceModel.Channels.HttpChannelFactory.GetWebRequest that when the AuthenticationSchemes.Basic is set that the PreAuthenticate is set to true automatically. Now this is where I initially had a misunderstanding about how this works. I was under the impression that when I have the PreAuthenticate set to true that I would not see any 401 errors in the IIS logs. In other words, the initial challenge/response was short-circuited and would thus avoid two trips to the server. My understanding was partially correct. What actually happens is the initial request from that TCP connection always requires two trips. Once the authentication handshake is complete each subsequent request will benefit from the PreAuthenticate flag. This is why it is the default in WCF, there's really no downside to having it set and it will significantly improve performance anytime you make multiple requests from the same authenticated connection. One of the best write ups out there is from the MSDN Forums (http://forums.msdn.microsoft.com/en-US/asmxandxml/thread/3ae9753d-2d97-45b9-9ba2-6d551fe60a48/)
IIS Logs Sample (4 Requests):
2008-06-26 15:10:27 W3SVC310214380 192.168.1.210 POST /Service.svc/BasicAuth - 8787 - 192.168.1.103 - 401 5 0
2008-06-26 15:10:27 W3SVC310214380 192.168.1.210 POST /Service.svc/BasicAuth - 8787 soapitstop\user1 192.168.1.103 - 200 0 0
2008-06-26 15:10:27 W3SVC310214380 192.168.1.210 POST /Service.svc/BasicAuth - 8787 soapitstop\user1 192.168.1.103 - 200 0 0
2008-06-26 15:10:27 W3SVC310214380 192.168.1.210 POST /Service.svc/BasicAuth - 8787 soapitstop\user1 192.168.1.103 - 200 0 0
2008-06-26 15:10:27 W3SVC310214380 192.168.1.210 POST /Service.svc/BasicAuth - 8787 soapitstop\user1 192.168.1.103 - 200 0 0
Integrated Authentication (NTLM): The first thing to do here is differentiate between NTLM authenticaiton (aka Integrated "Windows" Authentication) and Kerberos authentication which is the typical default used on Windows Server 2003. In fact you will often find that IIS needs to be forced to use NTLM exclusively because of the desire to use Kerberos (this is largely because Kerberos is considered a better security standard). Forcing IIS to use NTLM as the authentication provider is a blog post for another time. Let's just say you've gotten your client and service to communicate using NTLM instead of Kerberos. How does the PreAuthenticate switch factor into this. Interestingly enough it doesn't play in at all. What actually happens in this case can be found in System.ServiceModel.Channels.HttpChannelFactory.GetConnectionGroupName. In that method you can see a call to "IsWindowsAuth" followed by the setting of the UnsafeAuthenticatedConnectionSharing property to true. Well, that sure does sound scary doesn't it. Not to worry, the "Unsafe" keyword is there because without a user based ConnectionGroupName you could see users gain elevated connection privileges. In the case of WCF the connectiongroupname is built from the incoming credentials so everything is isolated as you would expect. Once again, without doing anything special you'll see that you get the benefit of a reusable authenticated TCP connection when using WCF.
IIS Logs Sample (4 Requests):
2008-06-26 15:10:25 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 - 192.168.1.103 - 401 5 0
2008-06-26 15:10:25 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 - 192.168.1.103 - 401 1 0
2008-06-26 15:10:25 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 SOAPITSTOP\aanalyst 192.168.1.103 - 200 0 0
2008-06-26 15:10:25 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 SOAPITSTOP\aanalyst 192.168.1.103 - 200 0 0
2008-06-26 15:10:25 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 SOAPITSTOP\aanalyst 192.168.1.103 - 200 0 0
2008-06-26 15:10:25 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 SOAPITSTOP\aanalyst 192.168.1.103 - 200 0 0
Integrated Authentiation (Kerberos): This is where things start to get interesting. Based on the last section you already know that this configuration will also get the UnsafeAuthenticatedConnectionSharing property set to true. You would also think that this means it would behave consistently with what that peroperty did with Ntlm. Unfortunately, that is not the case and I don't actually have a good answer for this at this time. I continue to do background research on how to avoid multiple round trips when using Kerberos instead of Ntlm but until I have a better answer (which may end up being a security enhancement or some other type of known benefit to reauthenticating every request) you'll have to do one of two things. The first one (and by the far the easier of the two) would be to just use Ntlm in an intranet (specifically Windows to Windows) scenario instead of Windows Auth. If you absolutely have to use Windows/Kerberos (I keep saying "Windows" because that's the enum option in the WCF transport security) then you may want to explore building your own channel and insert your own implementation that can set the PreAuthenticate switch to true for Windows auth in the same way it does for Basic. I have not validated this yet myself but I plan to when I get some free time. If nothing else I hope this helps clarify what has always been a confusing topic in my book. One other noteworthy aspect of this last configuration is about the IIS metabase and the AuthPersistence flag settings. I actually played around with these a lot but they didn't buy me anything, come to find out the AuthPersistence flags are only relevant to Ntlm. For more information on these you can look at the following link http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/8feeaa51-c634-4de3-bfdc-e922d195a45e.mspx?mfr=true
IIS Log Sample (4 Requests)
2008-06-26 14:39:42 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 - 192.168.1.103 - 401 5 0
2008-06-26 14:39:42 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 SOAPITSTOP\aanalyst 192.168.1.103 - 200 0 0
2008-06-26 14:39:42 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 - 192.168.1.103 - 401 5 0
2008-06-26 14:39:42 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 SOAPITSTOP\aanalyst 192.168.1.103 - 200 0 0
2008-06-26 14:39:42 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 - 192.168.1.103 - 401 5 0
2008-06-26 14:39:42 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 SOAPITSTOP\aanalyst 192.168.1.103 - 200 0 0
2008-06-26 14:39:42 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 - 192.168.1.103 - 401 5 0
2008-06-26 14:39:42 W3SVC310214380 192.168.1.210 POST /Service.svc/WindowsAuth - 8787 SOAPITSTOP\aanalyst 192.168.1.103 - 200 0 0
Well there it is, hoepfully this explains why you really don't need to set these settings anymore in the WCF client proxies. I also have some other good support cases I've worked on performing pre-compilation with WCF services and a huge scalability and perf overview of TCP based services. I hope to get around to writing those up in the next few days. If you have any follow up questions please post a quesiton or comment here on SOAPitStop.