To protect the data, we must provide two security services: confidentiality and integrity. We must ensure that the contents of the message are not revealed to unau- thorized personnel and we must ensure that the contents of the message are not altered. These services usually require cryptography. Encryption is used to provide confidentiality, and digital signatures are used to ensure message integrity. Keyed Message Authentication Codes (NIST 2002), another cryptographic technique, can be used for message integrity but does not scale well and is not suited for use across domains, for example, between eBuyer and ePortal.
Again, the approaches can be connection-oriented or message-oriented. Connec- tion-oriented approaches protect the messages while they are being transmitted between systems. While in storage, application or operating system mechanisms are used to protect the data. Message-oriented approaches protect messages in transit or in storage. Connection-oriented solutions include SSL and IPSec. Message-oriented solu- tions include XML Encryption and S/MIME.
A security mechanism may provide more than one service. Many of the same solu- tions previously discussed are also candidates to provide confidentiality and integrity services as well. For instance, a digital signature can authenticate the source of a mes- sage, but it also protects the integrity of the message. A security system is often designed to provide several related security services.
Both SSL and IPSec are used to securely transmit data from endpoint to endpoint. A connection is established between two communicating parties. The data is encrypted as it moves from one party to the other. At the destination site, it will be decrypted so that the receiver can process the request and pass it on, if necessary. With Web Services, the message may need to pass through other hands before arriving at its intended des- tination. We may not know who has access to each of these systems or how well man- aged they are. If the contents of the Web Services message must be protected from eavesdroppers, connection-oriented solutions, such as SSL and IPSec, are useful but may not be sufficient to the job.
Another issue with connection-oriented approaches is that the entire message is protected in transit. So, while the message is being transported, it is protected from
eavesdropping and modification. But, at the endpoint, the whole message is exposed. There is no ability to hide parts of the message from the endpoint or to protect parts of the message from modification. Depending on the situation, this level of protection may be adequate. In other cases, connection-oriented protection may need to be aug- mented by other protective mechanisms.
XML Encryption and XML Signature work together to provide message-oriented data protection. Since we have covered XML Signature, we will not repeat the expla- nation here, except to point out that since the signature is tied to the message repre- sentation (the hash of the message), a change to the message invalidates the signature, thereby serving as a way to detect that the message was altered.
An advantage of XML Encryption is that portions of the SOAP message can be encrypted. The encrypted portions of the message may or may not overlap with the signed portions of the document. This means that a message containing an offer to sell some equipment can include encrypted payment instructions that should be hidden from the potential buyer. But, the entire message can be signed so that the buyer can verify the seller’s signature on the offer.
The other accepted method of protecting messages is CMS. Its origins are in mes- sage protection. While it protects text-based information, it was not designed for XML. CMS operates on the entire message. There is a SOAP binding for MIME. So, if email is used to transmit the SOAP message and the granularity is acceptable, CMS is an option for message protection.
XML Schema processors are able to check XML documents for compliance with the associated schema. This is a powerful capability as a flexible method for specifying datatypes. There are two drawbacks to the approach. First, application developers may not always generate a schema for each message type. Second, inspection of the ele- ments and attributes in each message will be time-consuming. Protection against mal- formed messages may be appealing but many will forgo it because of the reduced performance that will result. Otherwise, applications will have to handle input check- ing, much as they do now.
System Characteristics
Before we describe the solutions for eBusiness, we need to answer some questions about the situation.
Between eBusiness and eBuyer, will other parties handle the message?
The offer from eBusiness is first sent to ePortal. At ePortal, the offer is extracted and sent to eBuyer in a message that may include offers from other possible vendors. The payment portion of the offer needs to be kept private, even from eBuyer. Once eBuyer selects eBusiness as its vendor, it sends its acceptance along with its account informa- tion to ePortal, which sends the acceptance to eBusiness. Again, neither ePortal nor eBusiness should be able to understand this part of the message. A reasonable question to ask at this point is why the information is sent if the payment instruction must be hidden from the other receivers. In this case, each side signs its message as a single unit. Removing the payment instruction from either message makes it impossible to verify the signature.
As discussed previously, SOAP messages may be routed through SOAP intermedi- aries that have responsibilities for support of the SOAP message processing. SOAP headers are used to convey information to intermediaries but the entire message is accessible to an intermediary. In our example, the intermediary is the ePortal account- ing system. Payment instructions are encrypted so that they can be decrypted by the accounting system. The accounting system uses this information to collect payment from eBuyer and pay eBusiness.
What protocol(s) will be used to transfer the SOAP message?
SOAP messages may be sent using any protocol that handles text messages. HTTP is the most likely protocol, but candidates also include FTP and SMTP. If there are intermediaries, different protocols may be used between each segment. HTTP is used between all of the participants in this transaction. EBuyer, ePortal, and eBusiness use HTTP to transmit the SOAP message.
Are the recipients/handlers of the message allowed to understand some parts of the message but not others? If yes, what parts of the message are each allowed to understand?
In the purchasing example described above, some information must be kept confi- dential from nodes that are handling the information. This is shown in Figure 6.4. First, eBusiness’s payment instruction must be kept from ePortal and eBuyer. When the offer is presented, the vendor does not want to make its banking information known except to those who need the information. The payment information is only needed by ePor- tal’s accounting system if Joe, the buyer, accepts eBusiness’s offer, so that the funds can be transferred to the correct account. eBuyer’s payment instruction must be kept from ePortal and eBusiness. eBuyer’s account information is also needed by ePortal’s accounting system to collect payment, but eBuyer wants to limit knowledge of its bank account number to those entities that have a need for the information. The ePortal accounting system needs the information to collect the amount owed by eBuyer.
Besides financial data, medical data or other sensitive personal data is a good exam- ple of information that might be transferred in SOAP messages where intermediaries handle messages but should not be allowed to understand parts of them.
What parts of the message are related so that they must be sealed as a group using a digital signature?
In the example, the description of the offer and the payment instruction need to be signed together. This protects the vendor from having the financial terms cut from the specification of the materials promised and attached to other merchandise. When the buyer accepts the offer, the payment instruction being sent to ePortal’s accounting sys- tem, including the seller’s payment information, should be signed.
In what order are the encryption and digital signatures to be applied?
If the signed portion of a message includes encrypted data, a decision has to be made whether the encryption happens before or after the signature. A digital signature applied after encryption must be clearly called out. With WS-Security, the order in
which cryptographic functions were performed is implied by the order in which the key information is appended to the security header. Keys are prepended to the header element as they are used. Therefore, the key for the most recently performed crypto- graphic operation is closest to the security header element start tag.
When eBuyer accepts eBusiness’s offer, eBuyer signs the offer as well as its accep- tance, linking them so that they cannot be used separately. Since eBusiness’s offer included eBusiness’s payment instruction, eBuyer signs encrypted data. The descrip- tion of the signature must exclude eBusiness’s payment instruction from decryption before eBuyer’s signature is verified.
Does an XML Schema specification exist for the SOAP messages exchanged?
Existence of the schema for the messages makes it possible to use XML Schema processor to check the validity of a message. Otherwise, the application programmer must take responsibility for this.
Figure 6.4 Encrypted data flow between nodes.
Buyer: Joe
ePortal.com
ePortal.com accounting
eBusiness.com Offer from eBusiness.com
to sell 50 widgets @ $20 each
Payment information: XXXXXXX
Offer from eBusiness.com to sell 50 widgets @ $20
each
Payment information: XXXXXXX
Send Joe 50 widgets @ $20 each Payment information:
XXXXXXX Account information:
YYYYYYYY
Send Joe 50 widgets @ $20 each Payment information:
XXXXXXX Account information:
YYYYYYYY Accept offer from
eBusiness.com to sell 50 widgets @ $20 each Payment information: XXXXXXX Account information: YYYYYYYY Send Joe 50 widgets
@ $20 each Payment information: Vendor Bank, account abc
Account information: Buyer Bank, account def eBuyer.com
Purchasing System