Dare Obasanjo asks for prescriptive guidance for developers on when web services and ws-* should be used. This goes past the “web services or remoting?” question that we have all seen that chart for. (sorry , can’t link to an example – but surely you’ve seen it). I am using web services in a non-interop solution where I own both ends of the pipe (over the internet) and have even implemented wse2 …because I saw this as an “easy” way to solve my problems. In some situations, this could be a very bad choice. I would absolutely like to see what Dare is asking for. Including myself, we sometimes get so caught up in how to do something, that we don’t stop to think whether or not it’s what we need. I just spent weeks shoving wse2 down the throat of a production app that worked perfectly fine. Admittedly, I did this mostly due to a bit of an ego problem (and that I wanted to get past my “in theory“ only understanding of WSE2).

Posted from BLInk!

Don’t forget to change the endpoints in your policycache files!

(she says, having learned the hard way, once again…)

Posted from BLInk!

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.

Now that I have just refreshed the WSE2 samples with their original versions (thanks Bristowe), I am very happily debugging through them to see Don Smith’s lovely code for creating and issuing custom security tokens. My frustration had a lot to do with the fact that I know there is a goldmine of info in the samples and stepping through them with the debugger brings me so much farther than just reading explanations that don’t cover every single step.

And now I grok this stuff well enough to dare to dig in again and start mucking with it.

Here are some tricks about debugging into web services and into httphandlers that you never really understand until you have to use them.

Debugging web services from a windows client is sometimes a real mystery. Sometimes it works, sometimes it doesn’t and I never really understood.

I had this experience when debugging into the custom username token manager – sometimes I just couldn’t get at the code. (John Robbins ….I need to read your book cover to cover and that is all there is to it!!!) Hervey Wilson reminded me of Debug/Processes which helped enormously. I learned finally how to attach to a process that I couldn’t get into normally to debug. With the custom security token it was a bit different since I needed to attach to an httphandler that was not loaded before I needed it. Here you just need to attach to the aspnet worker process (aspnet_wp.exe) when you are at a point in your code that you know it is being used – and tada – you  can debug into the http hander. In the case of the CustomXML Security Token Sample, the httphandler is where all the goodies were.

Posted from BLInk!

yeah – I’m pouting. Whine whine whine…and whimper, too.

I’m coming up against one brick wall after another after another trying to run some of the wse2 samples so I can try to understand how some of these things work. I don’t know if I’m setting things up improperly or what. I wish I could get Don Smith to just come here to Vermont and sit with me for one whole day. I know I could figure everything out with someone to just point me in the right direction every time I go astray. But unfortunately these “astray-nesses” take me off track for hours and sometimes entire days.

So I’m pouting. Maybe just tired and time to call it quits. nah – that’s like giving up.

update for the kind souls who tried to comfort me after my very satfisying rant: I had two places to test this. The second is my tablet where I could use localhost, but I had mucked with the code a while ago and broke it and was not adept enough to figure out how to fix it. So John Bristowe was kind enough to email me a new sample directory (save those samples – you have to reinstall wse2 to get them again) and at least on that machine it’s all working again. But I learned a LOT as usual trying to track down the problem.

I have been racking my brain trying to figure out how to pass info from one managed application to another that is in a separate process. I’m thinking of all of the tools that I know how to work with and none of them make me happy. The information is user information as I have the user login to one app and then that app starts up another app in a separate process – but I don’t want the user to have to log in again.

I started thinking about this over the weekend and mentioned the problem in this post, thinking that it was just because I have limited knowledge, but the solution was probably just out of my reach, yet common knowledge to many others.

Some of the paths my brain has gone down…

 – persist the info – using some type of encryption, temporarily write the info into a file and then read that file from the second process. I dno’t like this because I come up with way too many what-ifs.

– pass the info as args within the startprocessinfoclass. No way. Too easy for someone to then start up the 2nd app on their own without credentials.

– pass the login and password as args and then force the new app to quickly re-authenticate the user. No – I have no clue how secure or inaccessible the command line args are.

– get a securitycontexttoken within the first app (that is already doing wse2) and pass it to the 2nd app. Hmmmm… that could work – although since my client won’t have x509 certs on the server (don’t ask, please!) this won’t be as easy as I would like.

However, I think that this last thing is going to be my best chance. Hooray WSE2.

Now to figure out how to accomplish this. Oh – it is never ending…

When you create a policy in an WSE2 enabled client app in Visual Studio using the WSE Settings tool, your policycache.config file will likely be in the root directory of the application development folder because that is the default setting and I know everyone loves to just use those defaults.  Your app.config file will point to

<microsoft.web.services2>
<diagnostics />
<policy>
<cache name=”../../policyCache.config” />
</policy>
</microsoft.web.services2>

So you need to remember when you deploy your application, especially if you are testing and possibly deploying manually, that the policyCache config is not in the bin folder AND that you will probably need to modify that location setting in the app.config based on the final relationship between your exe and that file.

Just a little thing…but it had me scratching my head for a few minutes.

Here is a great analogy that is going to be very useful in helping people grok security tokens written by Steve Maine. I think it is immimently important for people to understand these building blocks that are being used in web service security, whether they go with WSE or not. Anything that can make folks go “ooooooooooh! NOW I get it” is so valuable.