In-Depth

Web Services: Careful, It’s a Circus Out There...

• By Tony Baer
• May 1, 2005

Talking Points

• Web services blur the boundaries between network and software functionality and data by making access dynamic.
  
• As a result, access control becomes far more complex as applications are exposed as services over a network.
  
• For most companies, offering sensitive Web services in high volumes is still over the horizon.
  

Over the past year, Northern Trust took its first steps toward building a service-oriented architecture. According to Audra Lind, a vice president with the corporate operations and technology unit, the goal was to develop a framework that would ultimately make it faster and cheaper for developers to build new applications, such as providing composite data views to traders. “It will open the doors for sharing and reusing across different lines of business,” she said. Although Northern Trust’s SOA project, currently covering investment and cash transfer systems, is confined behind the firewall, security is a paramount concern. The firm’s first goal was to develop a single sign-on system so that users could work with data from multiple systems without having to enter multiple passwords. The enterprise manages end-user roles using an identity management system from Oblix (recently acquired by Oracle) and AmberPoint, a system that brokers Web services requests for authentication and authorization.

Identity management and access control are only the first steps in securing Northern Trust’s SOA infrastructure. “We need to understand security vulnerabilities so we can position ourselves to communicate internally and externally over time,” Lind says. “If we open up to the outside world, we want to make sure that everything is nailed down.” As the next step, the bank is determining how to secure the endpoints, the parts of the system that dispense the actual services.

Prior to the advent of Web services, organizations could afford to follow a tiered approach to security, focusing on authenticating the end user, authorizing access and maintaining audit trails for back-end systems; anti-virus and similar protection for desktop clients and Web servers; and intrusion prevention at the firewall and network devices out on the periphery. The tasks of maintaining security were often split by tier, with the network admins handling external protection, and systems or database administrators managing access to the back end. (See related story, “No soup-to-nuts solution.”)

Even as enterprises opened back-end systems to the Internet, access and access control were relatively simple, static functions. With only a narrowly prescribed range of tasks supported, Web access shared many of the same access control disciplines developed with internal systems.

However, Web services blur the boundaries between network and software functionality and data by making access dynamic. In place of selected discrete functions made available through a portal, Web services can dynamically interact with other services or requests originating elsewhere in the network cloud, making interaction far less predictable. As application functions are exposed as services, multiple services could proliferate as application processes are deconstructed and recombined. For instance, in a preliminary tally, SAP counted well over a thousand discrete services that could be exposed from its core applications. As a result, access control becomes far more complex as applications are exposed as services over a network.

Web services are designed to operate in the heterogeneous federated environments that are blossoming across the business world. As a result, Web services requests and deliveries could pass through multiple intermediaries that may aggregate or split messages, dictating closer, more nuanced scrutiny of the user’s identity and the integrity of the message. “You could easily spoof an identity or service request if you don’t use proper encryption or signature standards,” warns Christopher Crowhurst, VP and principal architect for Thomson Learning, the educational unit of Thomson, the financial and publishing giant.

SOAP, the most popular Web service messaging protocol, uses HTTP—which is designed to pass through firewalls—and that could make Web services especially vulnerable to exploits that traditional perimeter devices might stop. XML messages are bulkier than binary code, which invites the possibility of servers bogging down while parsing the payloads of denial of service attacks. Another potential channel for attacks are binary attachments to SOAP messages, which would allow viruses to hitch rides the way they currently do with e-mail. (See related story, “Web services not a draw for virus writers, yet.”)

Significantly, the thrust of most Web services security standards to date has centered on authenticating the requestor, vouching for the integrity of the message, and providing the headers for specifying security policy. But if you adopt those standards and build your defenses accordingly, will that provide adequate protection?

Keeping the lid on
These problems are clearly solvable as long as you don’t take a one-size-fits-all approach. For instance, there are many approaches for encrypting and signing messages. Secure Sockets Layer (SSL), which is highly familiar from its broad-based use over the Web, may be relatively easy to implement, but not as efficient as XML Signature, a newer technology developed specifically for Web services.

The use of public key encryption, which was long considered the gold standard, has decreased because of its complexity. Regardless of which option is used, if a system is to process a high volume of Web services transactions, resorting to an appliance can prevent this resource-intensive process from bringing a network to its knees.

In many cases, layered defenses may make sense because a single external device can’t be counted on to check for suspect intrusions plus handle encryption, inspect the payload and perform policy decisions all in one pass. For instance, while a firewall checks for general intrusions, encrypted Web services messages might pass to a second dedicated gateway that would decrypt and authenticate the message and identity of the sender. In some cases, policy enforcement regarding what requests, from which entities, are acceptable under which conditions might be entrusted to yet another layer of software or device. For virus detection, there are links with anti-virus programs.

There is also the business context to consider, Wagner says. For instance, if services are exchanged between a known circle of trusted partners, an approach that validates the sender by organization might be adequate. “The likelihood of problems increases with the number of endpoints,” Wagner says, referring to the recent debacle with ChoicePoint, a national provider of personal credit and financial data, which discovered last fall that the privacy of its 10-billion record consumer database had been compromised by access from 50 bogus companies. “If you deal with the unwashed masses, you may have to handle it with a standard Web session,” Wagner adds. In addition, the volume and complexity of Web services processed could affect the defensive measures to be employed.

For most companies, offering sensitive Web services in high volumes is still over the horizon. At Thompson Learning, which is implementing its Web services-based commerce system with partners, the concerns are payload-based denial of service attacks and similar threats. Although XML is bulky, even small amounts can wreak havoc if the transformation instructions embedded inside the schema direct the system to perform a series of endless conversions that become, in effect, the equivalent of dividing by zero.

That’s primarily what Thomson Learning is scanning for in an extranet offering computer-based testing services to commercial training center customers, for which the company has garnered roughly 18 months of experience. Thomson is supplementing the usual perimeter measures with specialized XML appliances from vendors, such as Reactivity, to inspect the contents of every incoming SOAP message. “At the moment, there aren’t XML viruses, so we’re primarily looking for something that exploits the SOAP stack, such as entity expansion or poorly formed schema,” said Thomson Learning’s Crowhurst.

In many cases, security issues are due to the immaturity of Web services technologies, as best practices and holes in the standards gradually get filled. “Every iteration of the standards is getting better,” Crowhurst says. For instance, he points to improvements in the WS-I Basic Profile, which is used for testing the exchange of messages between systems from multiple vendors. He also singles out Security Assertion Markup Language (SAML), which specifies how message senders declare their identities.

“The latest versions are a huge leap forward in dealing with federated identity,” he says, adding that having such capability is crucial for offering services commercially in a world where there are always going to be multiple sources of identity information. “We need standards to develop trust exchange mechanisms. In a distributed world, you can’t put everybody in one big global directory.”.

ILLUSTRATION BY PETER FERGUSON

Sidebar: Web services not a draw for virus writers, yet
Sidebar: No soup-to-nuts solution