A basic tenant of Web services is that requests for services may travel through multiple intermediates, which may be different divisions of the service company and, in many instances, different companies.
Therefore, from a security point of view, moving to a Web services architecture entails moving from security models based on a client/server paradigm to one where there are multiple intermediates that may or may not be trusted. Surprising to many is the fact that traditional, transport level security protocols such as SSL and Kerberos decrypt the message at each endpoint thus inappropriately exposing information. If any of the intermediates are compromised the total message is compromised. A second aspect of Web services is that the requests are machine-to-machine and must be fully automated, without human intervention at the various intermediate points for maximum efficiency.
As an example of a typical scenario, lets examine a purchase order request. The request may first come to the order department, which needs to verify the customer's credit. If the company has outsourced the credit check, which many companies have, the request goes to another company. There is certain information in the PO that should be shielded from the second company and certain information that is required by the second company. The traditional models do not have the granularity to support this differential protection. However, this type of granularity is supplied by the newer security paradigms such as WS-Security and SAML specified by OASIS. Using these paradigms individual parts or even complete messages may be protected from intermediates.
In addition, all these decisions have to be set by automated policy for efficiency as noted above. On the other hand, products that do the requisite automatic policy handling are not yet available, although specifications are being developed. Therefore, policy handling will be done by custom applications for the time being.
As the request moves through the different departments of the service company such as order fulfillment, manufacturing and shipping, each should digitally sign the message or pertinent parts of the message so that the subsequent departments know that the request has been satisfied by its predecessors. This also serves as an indisputable record of the order. For example, the shipping department should not approve the product for shipping unless the customer has passed the credit check, the product is available or has been manufactured, etc. The appropriate digital signatures are proof of the satisfaction of these prerequisites.
Each company has its own specific workflow requirements, so each security strategy must be individually designed. However, all but the simplest scenarios include the requirement of differential protection at various intermediates, indisputable signatures that the request has passed certain prerequisites and authentication of different entities as well as the original requestor, as the request passes through the chain of intermediates.
Another important aspect of securing a process is that the level of protection should match the value of the resources being protected. Security costs can vary greatly, from hundreds to millions of dollars, so too high a level of security relative to the value of the resource is an unnecessary expense, while too low a level of security relative to the value of the resource results in inadequate security. Therefore, a careful risk management assessment is an important requirement of a security strategy.
This was first published in July 2004