A couple items on security, Rich Salz on Web Service security at XML.com and Phil Windley's weblog. I had a conversation of my own with a big customer yesterday about our web services offering; most of what they were asking about was security. One thing that came out in yesterday's meeting is that most everybody is doing SSL to make the message exchange confidential; Rich Salz says that SSL/TLS falls down in that "you can't save the message for later to prove that it hasn't been modified...In case of a dispute, it's impossible for either party to prove that it has the unmodified message". So if you wanted a strong audit trail, it sounds like SSL will defeat that. So Rich makes the case for WS-Security, which addresses the issue of message integrity and confidentiality, but not the question of identity or authorization. And I disagree with Rich's assertion that "these requirements are met by using cryptography" - as Bruce Schneier likes to say, "security is a process, not a product". Crypto can get you only so far.

Phil's pointer to Baseline's article on securing your network from insiders gets to one of the other points our customer was concerned about; namely, what mechanisms protect the customer from disgruntled employees on both sides? The wiseacre in me wanted to say "don't disgruntle your employees, then", but it's a serious question, as the article shows. We discussed endpoint checking, to allow the customer's credentials to work only from authorized networks, and schemes for creating user IDs that were less priveleged than what their production application would use. We support the latter, but not the former (yet). On our side, the customer wanted to be assured that our coders don't know the production DB credentials, for instance, and that those credentials weren't stored on the web server's file system in cleartext. As a coder, those kinds of restrictions can be a pain, but if you're deploying web services, expect your customers to ask those kinds of questions.