WSE3 and "Username over Certifficate" turnkey policy
I have been doing a bit of work with Web Service Enhancements V3 and its various turnkey security policies lately. WSE3 offers simplified policy implementation via the use of these "turnkey policies". Basically, WSE2 supported (as best as it could given the incomplete standards currently) for WS-Policy. WSE3 takes a different approach and doesn't really offer WS-Policy support, however offers direct support for these turnkey scenario's which are just implementations of some of the more popular WS-Policy implementations. Kind of like pre-packaged WS-Policy solutions.
The WSE3 implementation still uses a WSE3PolicyCache.config file so you can be forgiven for confusing this with WS-Policy. However, the intention of this post is a brief mention of some problems I had with the "Username over Certificate" turnkey policy that WSE3 offers. Basically, you can use a simple plain text username token for authentication purposes, and use a certificate to sign and encrypt that message making it pretty secure (well ok, more secure than simple "Username over Transport" policy without SSL ...)
The solution I was working on was using IIS6 and a specific application pool with the identity defined as the default NETWORK SERVICE user. The web.config of the services being exposed had an explicit statement to impersonate a particular domain user, like:
<identity impersonate="true" username="DOMAIN\someUser" password="somePassword" />
I had given access to almost everybody on the system to the certificate file store as I was having problems getting the WSE3 subsystem to authenticate correctly, in the hope I could identify it as an access issue. The error I was receiving was something like:
"Unable to access the file specified."
(Side Note: If you ever write a system that outputs an error like this, please give the name of the file I apparently "specified")
At any rate, after a quick chat with a fellow readify colleague (thanks Martin), he pointed me to the obvious that the system should be using the domain user as the application pool identity, and not impersonating via the web.config. Once I had assigned the permissions to the domain user to run the services as an ASP.NET application (and ofcourse removed the <identity impersonate="true" .... statement from the web.config) it now works fine.
Just thought I'd post this up for anybody else trying to do somethig similar.