Softwaremaker, Benjamin Mitchell, Sam Gentile and some others have been having a conversation about Indigo. I wanted to chime in on a particular point Benjamin made about Indigo that is also about WSE which is building up to Indigo.

one of the reasons I’m so excited about Indigo is this focus on designing the programming model with developer usability as a goal.

Hey, he’s talking about me (and you). I know I have put myself in the role of guinea pig here because I am “the developer”. I am the developer and not the plumber so although I am darned good at writing software, I have to put a lot more effort in to comprehending what’s going on in the background – and many developers will never even bother with that effort because it is sadly a big one.

So making the programming model intuitive enough and streamlined enough that developers can latch onto it easily and then our software can a) benefit from what is going into these tools and b) participate in interop if that’s where we are working. But if you are already a plumber, it’s pretty hard to grok what is and isn’t comprehensible to a non-plumber. I am really working at trying to understand this stuff, trying to translate it to others so they won’t have to put so much effort in and also trying to let Microsoft know when something just IS NOT accessible, when I work REALLY hard and I STILL am not getting it. I wish I had had the time to do this before WSE2 was released, but sadly I didn’t.

There has got to be a place somewhere in between “way too hard for me to spend the time figuring out” and “just click a few buttons and you have access to 10% of the features but not anything else”.  I know they are working on it. The programming model is pretty intuitive and really, once you get the basic chore down: create the different types of security tokens you are going to use in your messaging, add them to the soapcontext of your web service, define the elements you are going to use to secure your message and assign the proper one of your tokens to the elements, then add those elements to the soapcontext and go. There is a layer of WSE2 that will simply answer the needs of many applications. It’s only when you try to move away from that layer do you (well, if you are me) get in trouble.

Right now the pain I’m feeling is in the area of working outside of the simplicity of using x509 certificates. I haven’t even gotten much further than the basics. I haven’t even considered interop yet. I’m just writing the front and back ends in .net and trying to get them working together in a variety of scenarios.

So what’s my point here? Something about the fact that yes, they are definitely getting there, because I, Julie Lerman, can actually use WSE2 (although I did work really hard to get myself to the not-even-very-impressive-point that I’m at right now) and if they can just keep going on this same path between WSE2 and the future WSEs that we get up until Indigo, I bet we’ll be in damned fine shape.

Oh and there was one other thing I wanted to comment on which is the perspective that William (Softwaremaker) writes about in his post – about focusing on Interoperability. The funny thing for me is that I am not even LOOKING at interop. At the moment I don’t happen to need it with the applications I am working on. I am not trying to learn this stuff so that I can do interop, rather because one of the side benefits of all of this work that everyone is doing with ws-* in order to make interop work more fluidly and efficiently is that we can also leverage these tools in our proprietary applications (hmm – what is the word for non-interop?). I’ve got .net on both ends of my pipe. I’m not interoping with myself or anyone else. I’m not disagreeing in any way with William as I have no experience in that space at all. I just find it intersting that the real purpose behind WSE and Indigo is for interop, hell the real purpose behind web services is interop, but these tools (well obviously not Indigo yet) are the most important players in my application architecture anyway.

I am taking the plunge and trying to answer some (of the simpler) questions on the WSE newsgroup. It’s a little scary. I know I know this stuff (where I dare to answer) but there is this little voice in the back of my head that says “what if you don’t REALLY know it and you are just misinforming people?” That’s a really hard thing to deal with but goes away with time and you have to deal with it on each new subject that you learn about. So Hervey, if I’m not ready for prime time and my responses make you roll your eyes, just let me know (though privately may be a bit kinder… 😉 )

well it wasn’t a late night when I started.

I had to do some reconfiguration on the machine that I am using to do my wse2 demo tomorrow night at GUVSM in Montreal.

I am recreating some of these demos from scratch so I was practicing… 😉

Suddenly I was getting errors on my user of an X509 Certificate.

Cryptography_CSP_NoPrivateKey

That was easily googled and the answer (in the newsgroups by the master himself … Jeffrey Hasan) with the notion that there was something wrong with my certificate installs.

That made perfect sense since I changed my windows login password today and that wipes them out. However I checked them and they were still there, so I didn’t worry. But now, I deleted and attempted (note that key word…) to reinstall them.

I was able to install 2 of the 3 sample certificates but was getting an error when imorting the private server certificate into the Local Computer/Personal store. The error is

“an internal error occurred. The private key that you are importing might require a cryptographic service provider that is not installed on your system.”

So I googled and found lots of problems with windows 2000 server. After about an hour of this, I was grabbing at straws, installed the certificate elsewhere and then just dragged and dropped it into the place I wanted. Tada. Problem solved. (Temporarily, since I do want to know why I can no longer import into that store.)

Almost.

However, in my reproduction of my demos I had forgotten something important.

I was now getting a new error message when running my demo that said :

The certificate’s trust chain could not be verfied with the following reaons: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

Now I was really frustrated. I googled again with no real luck. Then poked around the newsgroups again and saw something that triggered my memory that I needed to check “Allow Test Roots” in the WSE Settings (or just hand code this into web.config).

So all is well now and I have added some google juice to future people who may have these problems as well.

And as we all know, these lessons are painful and exhausting, but they are the lessons that really ingrain this stuff into your head.

I have been reading a lot and looking at the sample, but not until I literally stepped through step by step in the samples for SecureConversation and CustomXMLSecurityToken that are part of the extensive list of samples provided with the WSE2 SDK, did I really start grokking things enough so that I can do the type of customization that I need to do.

These are fantastic learning tools and quite often seeing them in action helps when your brain just can’t put the pieced together on it’s own.

l am still working on this sucker. It’s not just the distractions, but the desire to understand what I’m doing, not just do it. I’m doing the plumber way with this Lab. I’ll do the other HOL, too. Then I’ll experiment with the tools and wizards. The whole concept of the elements collection is very interesting. that’s the SoapContext.security.Elements collection. Lots of buckets to help organize your brain and get your head around all that is going on. I imagine that I will look back on this and wonder why I ever thought it was so complex!

Posted from BLInk!

in my old Non-WSE method of doing web services security, I had to get a token from the webserver and have it time out after 2 minutes’then get another one. This was to protect myself from someone discovering and using that token while it was valid. they could do that, but 2 minutes is not enough time to do much damage. But it was still a kludge.

Now WSE2 hasderivedkeyTokenswhich forces a different hash of your username token each time you stick it into your soap header. Cool. Benjamin Mitchell wrote more on this here.

Posted from BLInk!

Among  the methods you can use in WSE2 to  authenticate users is to pass the local windows account through the UsernameToken — not a common scenario of course. However, it is notable that when you use this method, WSE2 can only use this if the password is sent in plain text (one of the enumerations you can choose when creating a UsernameToken) which, in *this* case, limits you to using HTTPS (or just letting your password hang free in the wind, so to speak).

Posted from BLInk!

I’m working on the WSE2ws-securityhands-on-lab somehow my distractions are too many." It is taking forever. I remember doing a HOL at TechEd with only one distraction… (was it Christoph? who is so much fun to chat with). But still I was able to get through the lab fairly quickly.

Posted from BLInk!

part of the description for my WSE2 talk at ASP.NET Connections is:

If you believe that you shouldn’t have to read a 20-page white paper four times in order to secure your Web services, then the new version of Web Service Enhancements has been designed with you in mind

so the joke here is that the manual for the WSE2 Security  & Policy Hands on Lab is 38 pages! 🙂  But I hope one pass will do the trick!