KerberosToken musings

I remember when I first heard about KerberosToken in WSE2, I wondered what all the fuss was about. I mean, I've always been a proponent of transport security wherever you can use it. I figure that unless you've got a really compelling reason to use WS-Security, you're better off using transport security, for several reasons:

1) Admins know how to deploy and manage it.

2) SSL (the spec as well as the many implementations) has been under public scrutiny for years - much longer than any of the WS-* stuff we've seen maturing over the last couple years.

3) You're a hell of a lot more likely to get good interop using plain ole' SSL. There are sooo many different schemes for securing messages using WS-Security. Without some basic profiles that give toolkit vendors direction, I can't imagine that toolkit X will have much of a chance of unwinding a message secured by toolkit Y. And that's just an interop problem; I'm not even talking about security now.

Given all this, I've been rather reluctant to give WSE's KerberosToken much of a look. But I now find myself considering using it on a project that I'm working on. You see, we're building an SOA architecture where virtually all of the endpoints are using Microsoft infrastructure. Kerberos is an incredibly natural fit:

1) Single sign on rocks. No bugging the user for her cleartext password.

2) Services don't see the client's password, or even a hash thereof.

3) Kerberos connections are much faster than SSL to establish, and we have very short lived sessions in this system.

So why am I thinking about using WS-* with KerbToken instead of relying on transport security? Here's the deal: when you use IIS to get Kerberos, you're only getting one very small benefit - the first request includes a header with a Kerb ticket and an authenticator. But the body of the request and subsequent requests have zero protection on them. No integrity protection. No replay protection. No connection hijacking protection. Not even any encryption. If you want any of that stuff, you have to layer on SSL, and to me that's just dumb, because Kerb is perfectly capable of providing ALL those features:

This is what KerbToken gives you - an all in one package that provides confidentiality, integrity, and authentication without requiring SSL, along with an opportunity for rich authorization on the back end, including the option to do constrained delegation.

The other benefit is that I believe I'll be able to bolt on support for UsernameTokenOverX509 when interop scenarios arise. And I will be able to do it without having to change anything significant for a given service. To do that with the current toolkit I'm using would take a bit of custom code on my part, but I'm hoping that'll change sometime soon. Even if it doesn't, that's code I only really have to write once.

I'll let you know how it turns out in about a month after we ship.