(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.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!