Here is a very good reason – note the writers of the comments, too. Plumbers!

(by way of Casey)

Posted from BLInk!

(re my I give up on wse2 without x509 post) I followed another thought this morning and was able to get one form of encryption working although it’s not totally satisfactory.

By signing my requests with a username token (and policy automatically uses a derivedkey token of that) I can just use that token to encrypt the response. I was having a problem with this because my policy was missing one little piece of info – I hadn’t told the policy that the token used for signing was also supposed to be an identity token. So it just was failing and failing and I had decided that I was trying to to something that you weren’t supposed to do. And because I’m coding against a remote server, I had to create the policy manually (with the help of some copy and paste though.) Check this post for the reason why and a followup in the wse newsgroup for the thread I started titled “config tool and policy for remote server“ where Hervey Wilson explains that this is by design and is being reconsidered for wse3.

It’s a bad solution, but better than nothing. And it’s not great because the real roadblock is that implementing secureconversation is the thing that is truly difficult without the x509 web server certificate (or kerberos).

So I am replacing a non-WSE solution that did create an authorization ticket which I could use for a number of transactions, with a solution that will require the usernametoken to be authorized on every single request at the server. In the case of my client, this is an app that I own both ends of and the webserver and sqlserver are on the same box, so I am not going to make myself any more nuts over this – since the processing time is nominal and this is not like some banking application with millions of users.

But – let’s be clear here- this is a “better than nothing” solution however it is NOT a highly recommended one if you have any care about the quality of the security you are providing.

Since I have no idea when the admins responsible for my client’s servers will put an x509 cert on the webserver, I have decided to set aside all of the work I have been doing to apply wse2 to one of their existing applications and get on with my life.  I have learned a lot. I will continue to dig into WSE2 because it fascinates me and has opened up a huge door for me. But I don’t foresee any real-life implementations any time soon. Which I hate. This application demands that I be able to encrypt my responses. With WSE1, I could create my own “shared secret” key in the client app and the same one in the web services and then on the client end insert <decryptionkeyprovider> into the app.config to point to my decryption key. That was the recommended way but now it’s been deemed “too insecure“ and taken away. Although with WSE2, we have ws-trust and the ability to create and issue custom security context tokens from the web server, this method still requires a server certificate to make it possible for humans to implement it. I need to get on to other projects for this client as well as the myriad other commitments I am worried about falling behind on. In fantasyland I would love to just keep playing and playing with this. Oh well.

oh – I should mention the Kerberos token option. It’s not an option – since I can’t count on all of the clients being on windows xp.