July 14, 2011, 1:59 a.m.
posted by superj
Security for Web Services: Motivations
The Web Services model proposes to use the widely available public Internet for conducting business transactions. The notion of conducting business on a public network is a double-edged sword. On the one hand, doing so makes it easy to do business with anyone on the network, with the speed and efficiency we have seen in Internet e-mail. On the other hand, just as we must lock our cars when parking in most major cities, we need to protect ourselves from opportunistic crime, which comes with the power of open access to everybody.
Security is not an absolute. It is not technically possible to guarantee 100 percent security in any situation. Improving security in an e-business solution is based on many identifiable techniques, each designed as a countermeasure against various kinds of risks: digital certificates to guarantee authenticity and integrity, encryption methods to ensure confidentiality, tickets for authorizing access, and many more. But even using all available techniques, one can never guarantee that a particular application is absolutely 100 percent secure.
Security requirements vary by application. For example, you might notice a camera that records the license plate of your rental car at the parking lot exit. Such a system provides an automatic audit trail of cars leaving the lot. This is a unique requirement for the physical security of a rental car agency but may not apply to your business.
Security technologies do not come for free. Adding credentials to a message makes the message longer, thereby adding overhead in transmission, routing, and processing a received message. You may need a newer version of your middleware to support a particular security technology, and upgrading requires work and sometimes a fee to the software vendor. Pragmatically, though, the main cost is in processing time. The pricing for secure messaging—cryptography—is expensive, and the price for interoperable messaging—CanonicalizatioN (C14N), which consists of bringing an XML document to its canonical form —is even more expensive.
This leads us to a difficult question: "How much should we do to make an application sufficiently secure to be comfortable using the public Internet for message exchange?" As you would expect, the answer is not simple, because different problems require different solutions. Essentially, you should do enough to make the application reasonably secure, and not more. For example, suppose that you can buy a digital certificate to guarantee the integrity and authenticity of a purchase. A certificate that costs $50 is probably a good investment for a transaction involving $5,000,000 but is likely to be overkill for a transaction of $5. Security involves risk assessment and making trade-offs based on cost and value of the security measures available.