Typically when we think about security for a Web service, our focus is on how to protect it from unauthorized and malicious users. Thus, we tend to concentrate on such things as authentication of the requestor, checking to see that the requestor is authorized to access the service, validation of the request message, and so forth - all things that happen on the way in or during a request for the service. However, there is an equally important set of security functions that need to occur on the way out or after the service has finished processing the request.

Because these security requirements are not as apparent when thinking about Web services security, they tend to get built in as an afterthought without as much design and consideration as is necessary. This article describes some of the important security requirements that need to be considered beyond the typical steps that occur during a service request. In this article we'll refer to these steps as "security on the way out."

Typical View of Web Services Security - Only Half of the Picture
Figure 1 shows a simplified view of what we tend to concentrate on when thinking about Web services security. A requestor issues a request for a Web service in the form of a SOAP message. As part of this message, there are claims about the identity of the requestor and any associated attributes. When the Web service receives this request, it first verifies the identity of the requestor. Once the identity is verified, it compares the attributes associated with the identity against those referenced in its security policy to determine if the requestor is authorized. Next, it validates the request message, verifying any signatures, validating the XML, and so forth. When all of this is successful, the request is passed to the service implementation for processing. Although accomplishing all of this is by no means trivial, this is only half of the picture.

The Complete Picture
Figure 2 represents a more complete picture of Web services security, showing all of the steps that occur on the way in as described above, plus all of the steps that may need to occur on the way out. The following are some of the steps:

• Filtering the content of the response message
• Signing the response message (or selected elements of it)
• Encrypting the response message (or selected elements of it)
• Inserting any additional security tokens

Content Filtering
In many cases, even though the requestor may be authorized to access a service, it may not be authorized to access all of the data that is produced or retrieved by that service. Thus, the contents of the response will need to be filtered to return only the data that the requestor is authorized to access. For example, within the Department of Defense (DOD), a requestor may invoke an enterprise search service to find information related to biological weapons. That search service may find a set of documents related to biological weapons, some of which are classified as Secret and some classified as Top Secret. If the requestor only has a clearance level of Secret, then the search service will need to filter out the documents classified as Top Secret before returning the response.

Ideally, this type of functionality should be handled in the security infrastructure, separate from the implementation of the service. One approach may be to use a message handler that intercepts outbound messages from the Web service and uses XSLT to filter out content that the requestor is not authorized to see. One drawback to this approach is that it may not be the most efficient approach. In some cases, it may make more sense to filter out the content before everything is converted to XML. In other cases, this may not even be feasible. Considering the DOD example from above, if the schema definition for the response data does not include an element or attribute that specifies the classification level of the data, that information would be lost once the response is converted into XML. Thus, the message handler would not have enough information to properly filter the data. In such cases, it may be necessary to have a post-processing security layer within the service implementation to perform the filtering before the response is converted into XML.

Message Signing
There are two purposes for digitally signing the response message: for nonrepudiation and protecting the integrity of the message. These are typically driven by business or legal agreements that require the response messages to be digitally signed to protect both the service provider and consumer.

For example, the accounts payable department of a large organization may provide a Web service for its partners to submit invoices for payment. The implementation logic of this service will need to verify and approve the invoices that it receives. Upon verification and approval, this service will need to digitally sign a response message that is sent back to the partner indicating that the invoice has been received, verified, and approved. If there is ever any type of dispute over late or missing payments, the partner will have a digitally signed response proving that the organization did receive and approve the invoice it sent.

In some cases, the total amount due that is specified on an invoice may not be the total amount that is approved for payment, perhaps because not all goods were delivered or some were defective. Whatever the case may be, the response from this invoicing service may contain an element that specifies the actual amount that was approved for payment. The service provider may want to sign that element of the response message to protect its integrity - so that it can't be modified without detection. This prevents an unscrupulous partner from disputing that a greater amount was approved for payment.

Digitally signing the response message should be handled in the security infrastructure. The implementation should use the W3C specification for XML Signature [XMLSIG]. This is a formal recommendation from W3C that describes the syntax and processing rules for digitally signing selected elements in an XML document. The Web Services Security (WS-Security) standard from OASIS describes how XML Signature can be used to secure SOAP messages and how the signature should be attached to the message headers [WSSEC]. Following this standard allows loosely coupled service providers and consumers to independently sign and verify the SOAP messages that they exchange. Most Web service security products available today provide an outbound message handler that can be plugged into the service and digitally sign the XML response message. Some vendors offer dedicated XML hardware appliances that can "sit in front of" the Web service and intercept inbound and outbound messages and digitally sign and verify the XML messages.

Message Encryption
The reason why message encryption may be needed on the response is pretty obvious - the response may contain sensitive information that only the intended recipient should see. With traditional applications, confidentiality is typically provided through transport and network-level mechanisms such as SSL and TLS. In a SOA Web services environment, such mechanisms may not always be adequate or feasible. Although not explicitly shown in the Figures 1 and 2, the response message may go through several intermediaries before it is returned to the requestor or the next target service in a process flow. Some of these intermediaries may be trusted and some may not be. Mechanisms such as SSL and TLS are point to point, so the intermediaries will be able to see the response messages unencrypted. For untrusted intermediaries, it is obvious why this is a problem. For trusted intermediaries, there may be elements of the message that they should be able to access and still other elements that should be kept confidential from them. Thus, message-level encryption is needed for selectively encrypting certain elements of the response message and to prevent exposure of the response message to untrusted intermediaries.

Message encryption should be performed after the response has been converted into an XML message. Similar to message signing, this makes it ideal to be performed in the outbound message handler of the security infrastructure. WS-Security describes how XML Encryption should be used to encrypt any section of the body or header of a SOAP message. XML Encryption is another W3C recommendation that specifies a process for encrypting XML data and representing the results in XML [XMLENC]. Using these mechanisms essentially allows encrypting of the response message at the application level, thus avoiding the aforementioned problems. Just as with message signing, most Web service security vendors provide message handlers or XML appliances that can perform the message-level encryption and decryption so that developers will not need to build it into the service's implementation.

Insert Security Tokens
With the composite nature of SOA-based systems, the flow usually does not stop at a single Web service. That service may need to invoke another service or its response may be returned to an orchestration engine that uses the contents as input to the next service in the process flow. In either case, the service may need to forward along the security tokens from the original requestor or it may need to insert some new tokens with information about the service provider. A security token is just a collection of claims or statements (usually about the identity, privileges, group memberships, etc.) about a subject, which in this case can be the Web service itself or the original requestor of the service. Adding security tokens to the outbound message (either a response or a new request for another service) from a Web service allows the next target service in the flow to authenticate who is making the request and to make an authorization decision.

Adding security tokens to an outbound message can be supported by having an outbound message handler that intercepts the message on the way out and inserts the tokens into the message headers. Unfortunately, the heterogeneous environment in which a Web service typically operates often adds extra complexity. Security tokens can be expressed in multiple formats such as X.509 certificates, Kerberos tickets, or SAML assertions. In a heterogeneous environment there may be multiple interacting domains with different security infrastructures, and they may not all support the same format for security tokens. Thus, the security token inserted by the outbound message handler may not always be interoperable with the security infrastructure of the next target service. Web Services Trust (WS-Trust) is a set of specifications, proposed by vendors such as IBM, BEA, and Microsoft, which describes how security tokens can be issued and exchanged through a trusted authority to enable interoperability across security domains [WSTRUST]. WS-Security defines how security tokens should be represented and attached to the headers of a SOAP message. Using a Web service security product that supports both WS-Security and WS-Trust may help to alleviate some of the complexity involved with supporting this requirement.

Summary
In this article we discussed security requirements on the way out from a Web service. Such requirements typically don't get as much consideration when we think about Web services security. We discussed content filtering, signing the response message, encrypting the response message, and inserting security tokens. These requirements are almost identical to the steps that a client performs when sending a request to a service. The same technologies and standards are used to support both. Fundamentally, this is because the interactions between Web services and their requestors resemble more of a peer-to-peer model instead of the traditional client-to-server model. From a security perspective, this means that there is almost always a parallel set of security processing steps that needs to occur in the other half of the interacting peers. Keeping this in mind when designing the security for your SOA will help to ensure that you're not just supporting half of the requirements.

References

• [WSSEC] Web Services Security: SOAP Message Security 1.0 (WS-Security 2004): http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-soap-message-security-1.0.pdf
• [WSTRUST] Web Services Trust Language (WS-Trust): www-128.ibm.com/developerworks/library/ specification/ws-trust/
• [XMLENC] XML Encryption Syntax and Processing: www.w3.org/TR/xmlenc-core/
• [XMLSIG] XML-Signature Syntax and Processing: www.w3.org/TR/xmldsig-core/