XML Eye for the Object Guy : XML

Sharing the fruits of summer's labors

tewald — Sat, 20 Sep 2003 00:23:00 GMT

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

tewald — Fri, 19 Sep 2003 23:51:00 GMT

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

tewald — Fri, 12 Sep 2003 21:47:00 GMT

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

tewald — Thu, 11 Sep 2003 09:48:00 GMT

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

tewald — Thu, 11 Sep 2003 09:36:00 GMT

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

tewald — Fri, 05 Sep 2003 04:10:00 GMT

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

tewald — Thu, 04 Sep 2003 03:07:00 GMT

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!