XML Eye for the Object Guy

Posting again!

2004-06-28T21:50:00Z

But at a new location: http://www.pluralsite.com/tewald/default.aspx.

Post-PDC pondering...

2003-11-06T04:48:00Z

Back from PDC, mailbox dealt with, finally some time to post...

As David observes, for many of us last week was a wonderful whirlwind of Indigo and Don, blended together from Monday through Thursday. Here are some thoughts...

Like everyone I know, I'm in love with Indigo. The reason is simple: the layered API hits the sweet spot. It used to be that building distributed apps meant writing sockets code. Then along came RPC and object RPC systems that encapsulated grungy details behind a programming model. Hiding the details was good, the programming model was okay - except when it wasn't. Unfortunately, with those frameworks, you didn't have much choice. Indigo, in contrast, layers functionality so that hiding the grungy communication details doesn't mandate a particular high-level programming model. You get security, reliability, transactions, etc., whether you choose to deal directly with XML messages, map message bodies to object models, use simple request/response message exchange patterns or something more complex, or whatever. In short, you can build communication models the way you want without having to go back to sockets and do everything yourself. That is exactly where I want to be.

Don's talk introducing SOA on Monday afternoon was the best one I've seen him give in a long time. I've learned a lot about being a speaker from Don and it was great to see him deliver that performance.

Finally, I had the pleasure of spending time with Steve Lucco, who works on Indigo with Don. Steve joined my wife Sarah as a lead vocalist in Band on the Runtime. He's really really smart and a great guy to hang out with. (Also, Steve's rendition of CPU Bound gets my vote for most hummable BotR tune, it's been stuck in my head for days.)

Speaking at PDC

2003-10-01T03:01:00Z

Cleaning out my inbox after vacation, I find a note pointing me to this post from Brian Jackson, wondering if I'll be speaking at PDC. Yes, and I'm looking forward to it. Don, Martin and I are going to deliver the pre-conference tutorial on XML and Web services. It'll be just like the old days... :-)

Sharing the fruits of summer's labors

2003-09-20T00:23:00Z

I did a lot of XML work over the summer. One of the byproducts was a pair of XML readers. The XmlElementReader wraps an XmlReader that is positioned on an Element node and allows you to read that element, but nothing more. It's useful for passing an XmlReader to a method, but ensuring that it only consumes the current element and nothing more. The XmlInscopeNamespaceReader also wraps an XmlReader. It provides a method to lookup all of prefix/namespace URI bindings that are inscope at any given time.

I'm on MSDN TV

2003-09-19T23:51:00Z

As Craig noted, my talk from the Applied XML DevCon in Portland, OR last August is now online courtesy of MSDN TV! It's in two parts, here are links to part 1 and part 2. I had a great time at that show, and this was a really fun talk and had a big impact on people (like Rich, who mentions it here). Lot's of people at the show and via email have asked for more info about the ideas I talked about. I haven't had time to write something up yet, I'm hoping to do it when I'm back from next week's vacation.

I need to clarify...

2003-09-12T21:47:00Z

Reading Micheal M's comment, I realized that I was not clear enough in my last post.When I said I didn't want to think about security, I meant as a plumber. Part of my responsibility as the designer or developer of an application is, as Micheal M, says, to think about everything as a possible security hole. He is absolutely right and I did not intend to imply otherwise.

But I need help. I can't write my own cryptography engine. I don't have the time, and, more importantly, I won't get it right. Similarly, I don't want to have to write my own SSL hand-shake to establish a secure channel with an HTTPS endpoint. Luckly, those things are provided for me by my platform. However, that doesn't mean I get to abdicate all responsibility. At the very least, I have to:

Make sure I understand how these technologies work and I know how to use them correctly
Decide how to use these technologies to my application so that I ensure data integrity and confidentiality wherever it's required
Make sure I test my application to ensure that the technology does what I expect it to
Make sure I keep my platform up-to-date with patches that fix security holes

SSL strikes a reasonable balance. I don't have to worry about implementing the cryptography or handshake protocol myself. I do have to worry about when and how I use it, keeping my implementation patched, and whether or not the cert presented to the client does in fact identify the server. That's tractable for me with my level of security expertise.

My point about WS-Security and all the threads about MsComServices was that I need to get more from my platform. I want to get replay detection and secure channels from my platform. As with SSL, I will still have to think long and hard about how and when to use these features, make sure I keep my implementation up-to-date, and test my implementation to make sure it works. But I won't have to implement everything myself.

Things are moving in the right direction with the WSE 2.0 Tech Preview. WSE 1.0 provided the atoms for WS-Security. 2.0 provides molecules like WS-SecureConversation. Increasing the level of abstraction in this way is key.

Thanks for raising this point Micheal. I don't wany anyone to think that I or anyone else at Microsoft is not VERY concerned about making software more secure. Ironically, I actually see removing myself from the lower level implementation details as a way to increase the security of my software. Using the right security features from my platform is a better choice, as long as I do so responsibly (see the bullet list above).

"But I'm a plumber..."

2003-09-11T09:48:00Z

I've spent a lot of time with WS-Security lately, partly because of the bruhaha over its use in MsComService, and partly because I'm digging more deeply into WSE 2.0. Like most of my friends (and a penguin Gudge knows), I'm a plumber. I like spending time thinking about how to program with XML messages (feeding my reputed addition). But I realized last weekend that there are limits, even for me. I realized that I want someone else to take care of security for me...

It's not that I'm not interested - I think it's a fascinating topic. But I have too many other things going on to lose myself in it, and I don't trust myself to build something secure if I have to worry about all the details of signing, encryption, nonces, hashes, etc. myself. Hopefully a day will soon come when I can simply request a secure channel to a distant service and sit back and relax, confident that someone else has thought about the hard security problems for me.

Then I can spend more time thinking about what the bodies of my message look like - the problem domain specific part that it's hard for other folks to help me with...

Changes in the works...

2003-09-11T09:36:00Z

Sam welcomed me back to the blogosphere...

Your points are well taken. People here are very aware of the fact that developers may well look to Microsoft.com's services as an example to emulate, so they try to make sure they do the right thing. In this case, there's a been a lot of confusion around the fact that WS-Security really offers levels of protection and, in this case, the level required is pretty low. That said, the guys who built the service are working on the details for replay detection. I'll keep you posted as I find out more...

In the same thread, Dare commented that the use of WS-Security in this context doesn't make sense to him and that a token like the one used in the Google service makes more sense to him. The problem with adding a token to every operation is that it goes in the body of the message. Since the goal in microsoft.com's case is to consume the token at a router that then passes the message on, it needs to be in a header so as to avoid violating the SOAP processing rules. Once you're using a header, you've got more code to write in any case. Given that, why not use an existing header that identifies users? I think it would have been more confusing if they'd made up some new header of their own...

One more thing...

2003-09-05T04:10:00Z

Someone pointed out that signing a message wouldn't actually solve the all the issues Simon raised. It would stop someone from tampering with a message, but it wouldn't stop someone from replaying a message. You need to take additional steps to protect against that as noted on this thread at Sam Ruby's blog.

However, the real point I was trying to make on behalf of the developers at Microsoft.com who built this prototype service, is that security wasn't really their goal.

Using UsernameToken with the new microsoft.com Web service

2003-09-04T03:07:00Z

I spent my summer deep in an engineering project, the purpose of which will come to light in coming months. Now that the first phase of that work is complete, I have time to start posting again. And what better place to start than by answering questions raised by Simon Fell's recent post about the use of WS-Security with the new Microsoft.com web services.

Some of the guys at microsoft.com spent their summer working on the server-side infrastructure they need in place to support production Web service. They recently launched a prototype service that's intended to vet the plumbing. To use the service, developers have to register and get a username and password. Request messages carry a WS-Security UsernameToken containing the username and a digest based on the password, a nonce, etc.. Simon points out that, because the message is not signed, it doesn't provide any security. He's right, but that really isn't the intent. Rather, the UsernameToken is used like a cookie. It tracks invocations to gather metrics about how the services are used and to throttle requests so that servers aren't overwhelmed. The goal is to test the server plumbing and get a sense of how people use it. Google and Amazon do similar things with their public services.

So, why use a WS-Security header to do this? The service designers felt that a header would be preferable to an extra parameter on every call. A SOAP header made more sense than an HTTP header, because, long-term it is likely that messages will end up being routed on the server side for a range of operational and deployment reasons. Given that, WS-Security's UsernameToken mechanism seemed to fit the bill. They thought about requiring messages to be signed with the token to help protect against swiped tokens, modified messages, etc. They decided against signing for several reasons:

the service is read-only
there's no private data to protect
requiring signing would make it much harder to build message from any toolkit that doesn't support WS-Security

From my perspective, the last issue is the most significant. It's pretty easy to layer in a UsernameToken with a password digest with a toolkit that has no knowledge of WS-Security (like this Python client). It's harder to layer in XMLDSIG support.

The people who maintain the new service's web site are working on updating the text there to make it clearer that the service is not intended to be secure. (They're also working on posting the documentation for the service online.) Beyond that, there are two other changes they could make. FIrst, they could modify the service to require a signature, thereby mitigating the issues Simon raised. However, that would make consuming the service from any non-XMLDSIG enabled toolkit essentially impossible. Alternatively, they could change the service to use some other header that people don't associate with security, e.g., . It isn't clear to me yet that either of those changes makes sense. But people here are definitely listening to your feedback!

What to wear under your IBM power suit

2003-05-06T09:40:00Z

I heard a rumor that Grady now has a pair of Don's Boxers. COM really was about love… :-)

Welcome Chris!

2003-04-23T06:07:00Z

Chris and I worked together for years at DevelopMentor, and now he has joined my team at Microsoft. I'm very much looking forward to working with him again!

Handling mandatory SOAP headers in ASP.NET

2003-04-18T11:19:00Z

My latest House of Web Services column is now online here. It explains how to fix an issue mandatory header handling in ASP.NET. Sample code is also available.

A shortcut I learned today

2003-04-09T11:42:00Z

I mentioned a few posts ago that I'd been spending all my time writing specs lately.

One side benefit is that Tommy Williams told me that Word maps the 'F4' key to the last operation you completed. If you are deleting rows from a table (Alt-A, D, R), F4 saves you a lot of keystrokes. Maybe everyone else in the world new about this (if so, why didn't you tell me?), but it was a new to me, and very useful.

Epiphanizing with Don

2003-04-09T11:42:00Z

After spending all day at an offsite for my new project, I went out to dinner with a member of my team, and eventually ended up back at Don's house. He was on fire, so we headed back into the office, where there are plenty of whiteboards. As is often the case, he was in the middle of an epiphany about XML APIs and I helped him work through some of his ideas. It was a blast - just like the old days. :-)

I'm very optimistic about the future of XML. I haven't yet commented on all the recent posts about XML's relative suckiness or lack there of. Two things are clear to me: (most of) the basic protocol stack and APIs we have today are totally reasonable, and we can do a lot better (at least where APIs are concerned). As I said way back when, there's a ton of work to do here.