The Kitchen Sink Weblog: Tales from Sun's internet facing edge

Speaking of a blast from the past. Remember VMS? I do. I'm glad Unix (and it's grown up rebellious spawn Linux) out-lasted it. I really didn't care for VMS, with all the privileges and quotas. But it used to be popular, so I had to learn it. I used to call VMS the Klingon of operating systems, because both were ponderous and stuck on ceremony. Also both have redundant systems. I can't quite remember but a second something (stomach?) saved Warf from certain death. Guess which species was MS-DOS? I leave that as an exercise to the reader.

So as a wannabe techie, it is with some trepidation I plunge into a description of a technical problem we are having. But it's an interesting problem, so I wanted to put it out there. We recently built a webservice with the thought of making it public for our users to use. Right now the only client is the web frontend that runs on our sites. The service mostly provides read-only data, *but* a client can do some writes. As one would expect we require a login-in (user id and password) for the writes, because we are keeping track of the data for each user. This of course means that the client has to pass the userid and password to the webservice. And here is the problem. We don't want the userid and password to be passed to the server in the clear.

The XWS security model seems to assume a peer to peer model rather than client/server. So you can secure the conversation, but only if each side has installed a certificate. This is fine for two servers. But what about a webservice that might have lots of clients ... prebuilt clients that might be used by non-technical users? Getting each user of a client to download the certificate and compile it in is not really an option.

It is interesting to look at how other webservices with clients have tackled this problem, ie. Amazon. They don't use a user id and password. Instead they generate a token for each client. The token is passed in the clear, but at least it is not a password. However not very secure.

The only solution we have come up with is to put the entire webservice under https. There seems to be no way to secure just some of the conversation to a webservice. But having everything under https is way expensive. Much more handshaking has to be done for each connection. If anyone has any bright ideas we are all ears.

Kathy

P.S. I know that some people have been asking about Alameda. Truth is I don't know much about it's status, as I have been reorged away and taken on new work. If I hear anything that I will pass it along.