The advent of web services reveals new issues that didn’t exist in previous closed environments. New levels of openness and new characteristics of data exchange and interoperability also mean that we face new challenges for securing our data and identities:
Corporate applications and their interfaces are publicly available for all to see. They are available via port 80, which is generally accepted as an open hole in the firewall through which all HTTP traffic flows. Don’t assume that just because something is tunneled through port 80 that it is safe. Applications that provide frontends for your critical data will increasingly be exposed through HTTP and accessible to anyone in the outside world. If taken to the extreme, these applications can even be published in a public directory for anyone to discover.
Data wrapped in SOAP envelopes provides a way to discern the structure and meaning of data being sent over the wire.
Sending and receiving parties don’t have to be implemented by using the same software platforms; i.e., they don’t have to have the same security libraries from the same vendor. Therefore, we need a set of standardized, platform-independent security solutions.
XML is extremely verbose. Encryption is expensive enough as it is. Wrapping data in XML can increase the size of the data that needs to be encrypted tremendously.
The vision of web services includes enabling spontaneous supply-chain communities or trading communities via dynamic discovery. This vision requires complex interactions, in which a SOAP message traverses multiple intermediaries. You may not have a pre-existing business arrangement with some of these intermediaries, and these intermediaries may not be built on a common infrastructure. How are encryption keys managed in such an environment?
A new class of security techniques is being developed to address these issues. Many of the issues are still being identified or have solutions that are still in their early stages. However, existing security technologies with proven track records won’t be abandoned anytime soon. In fact, these new techniques are intended to build upon or augment existing security technologies such as Public Key Infrastructures (PKI), Secure HTTP (HTTPS), and the Secure Sockets Layer (SSL). These technologies are better addressed by a book on general security issues, so we’ll only discuss them minimally. Instead, this chapter focuses on new security issues and solutions that have come about as a result of web services and their related technologies.
The sort of HTTP-based web commerce we’ve seen so far achieves security by relying on the SSL, which ultimately places responsibility for security at the level of the transport protocol. While this approach has been adequate so far, we need a new set of capabilities that allow the use of digital certificates, digital signatures, and authentication within XML documents; we should not rely on the underlying transport to do everything. After all, SOAP and web services are supposed to be protocol-independent, and therefore can’t rely on transport protocols for security. Additionally, incorporating security features within the XML documents themselves has many benefits for web services, which can now make judgments about the document payload and what restrictions can be placed on it.
Much of what we discuss here is based on the concepts of PKI and nonrepudiation. Here’s a brief description of what these concepts entail.
Public key cryptography relies on a mathematical algorithm that generates encryption and decryption keys that are used in pairs. When a key from a key pair is used to encrypt the data, only the other key from the pair can be used to decrypt it. One key is public, and the other is kept private. In sender-receiver/encryption-decryption usage, the sender uses the recipient’s public key to encrypt the data. Only the intended receiving party can decrypt the encrypted data because only this party has the appropriate private key.
It’s also possible to encrypt a document with your private key; then anyone who has access to your public key (in theory, anyone—the purpose of a public key to be public) can decrypt it. While this technique doesn’t sound useful, it ensures that a digitally signed document has not been tampered with. We will talk about this topic in more detail in Section 10.3 later in this chapter.
The problematic part of public key cryptography is the generation, distribution, and verification of keys. If I want to do business with you, how do I get your key? How do I know that the key I receive is your key and not a forgery? The PKI is supposed to solve this problem. We will talk about how the PKI relates to the latest technology proposals in Section 10.3.2.1.
In the context of web services, nonrepudiation means that the recipient can verify that an XML document (anything from a purchase order to an RPC request) actually came from the sender it claims to have come from and hasn’t been modified along the way. It’s the electronic equivalent of saying, “You can’t tell me that you didn’t want your house painted blue; here’s the work order, and here’s your signature on it.” More technically, nonrepudiation means that proper authentication is in place (sufficient to verify the identities of all participants in the transaction), and enough of a digital trail has been left to go back to any given event and verify that:
This is you.
You made a request.
This is exactly what you requested and you presented the request in this form.
Much of nonrepudiation involves the use of a digital signature.