NETTING IT OUT

Executives are looking to Web Services to enable new and very valuable interactions with customers, trading partners, suppliers, and other organizations. These Web Services interactions have two characteristics that will exacerbate security issues that you have been able to avoid up to now: multi-hop and multi-company.

Multi-hop interactions traverse several intermediaries, such as databases, platforms, applications, and networks, in order to complete a request. Most of today's security implementations, which are more like a patchwork than a solid fabric, are not able to maintain the context of the request as it passes along those intermediary steps. Requests are honored because they come from a trusted intermediary, rather than because the user originating the request deserves the answer. As a result, the integrity of the request and the response can't be guaranteed. There are two critical requirements that emerge from this issue: 1) maintaining security context so that the requestor's identity is known and 2) sharing security context with any resource that needs the identity information. The solution to both of these requirements is the Security Backplane, a services-based unifying architecture to prepare your own systems to provide consistent security information across the entire application environment.

There are two critical security issues that flare up when multi-company Web Service interactions are considered. The harder of those two is trust: how does your company assess and control the risk of these interactions with a trading circle, and what technology can be brought to bear on the problem? The second multi-company security problem is how to exchange security information, given that Web Services does not specify how to exchange security information and every company has a variety of incompatible security mechanisms. There are three critical requirements that emerge from the multi-company issues. You need to implement SAML and WS-Security, the lingua franca of security information. You need a policy board or executive forum of trading circle members to discuss liability, risk, and policy. And, finally, you need to create a security backplane, which also solves the context requirements.

We recommend five actions to ameliorate the multi-hop and multi-company security issues:

1. Limit your immediate stop-gap Web Services security extensions to SOAP header messages.
2. Assign one of your best executives the task of setting up a policy board for one of your trading circles.
3. Establish a security service that will present and utilize SAML assertions for interactions outside your organization.
4. Implement a security backplane.
5. Plan to support a federated directory.

PREPARING FOR WEB SERVICES' OPPORTUNITIES

The opportunity to cut cost and time out of business processes by using the lingua franca of Web Services to connect to customers, partners, and suppliers has attracted executive attention--and IT budgets--for the past 12 months. Some companies have held back from betting heavily on this new technology and set of standards, waiting for the fog of FUD (and fad) to lift. But Web Services hit the technology mainstream in January when SAP announced that it was not only providing Web Services interfaces, but providing a platform for customers to build composite service-based applications that would span companies.

Someone in your trading circle will soon offer valuable Web Services that you'll want to connect to. You need to prepare to seize that opportunity. Getting your Web Services security backplane in place is one of the most essential--and possibly the most difficult--preparations to make.

SECURITY ISSUES SPECIFIC TO WEB SERVICES

Web Services place new stresses--or exacerbate existing stress--on your security infrastructure. This additional stress will illuminate the current shortcomings in your security, which is almost certainly a patchwork of tools and practices that is just about capable of managing current requirements.

What's so hard--or unusual--about Web Services security? We see two aspects of Web Services that put new stress on your security implementation. Web Services tend to be multi-hop, and they also tend to span company and organization boundaries. Your existing security systems were almost certainly not designed for either multi-hop or multi-company interactions.

Handling Multi-Hop Requests

ISSUE: MAINTAINING CONTEXT ACROSS HOPS. Multi-hop requests are those which traverse intermediaries to reach a resource. For example, a bank branch manager using a portal application invokes a Web Service that sends a request for customer balances to a customer profile system, which, in turn, calls on a mortgage-status application, a home-equity status application, a credit card application, a savings application, and a checking application, all of which make requests of back-end databases.

Today's security implementations typically cannot maintain a line-of-sight from requestor to provider and back. The context of the request--who asked and what permissions are declared--gets lost along the way. There will be stages in the journey when intermediaries (such as a database) ...