Where should you put your Web services security?
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
According to a new report from the Burton Group, you should put it everywhere as part of a layered defense network incorporating public key infrastructure and identity management as part of the mix.
Key to all of it, according to Anne Thomas Manes, Burton Group vice president and research director, is using both XML security devices for intermediary and access points with Web services management intelligence enforcing policy at the endpoints of the network.
"I don't think it's appropriate to rely on just the hardware devices or just the Web services managers," Manes said. "The combination is the way to go."
She mapped out a proper layered defense as being:
- Network perimeter defenses.
- Identity-based defenses at centralized entry-point.
- Identity-based defenses at each intermediary and endpoint.
- Security monitoring for attack and fraud detection.
- Transport-level and application-level message protections.
If that doesn't sound easy to do, Manes contends that's because it's not easy to do. She recommends that security be abstracted away from applications and services as much as possible and put in the hands of IT security professionals who know their craft.
"Make security as automatic as possible," she said, adding that developers should be able to attach security to a Web service once it gets built without having to understand the specifics of how that security works.
To achieve that, governance is needed. Some sort of intelligence in the network has to define security policies, deploy a security infrastructure and institute formal processes and procedures.
Manes believes Web services management tools like the ones offered by Actional Corp., Infravio Inc. and SOA Software Inc. are best suited to handle that task, acting both as a policy management authority and placing network agents at policy decision points. In particular, she said Web services management software can provide better monitoring for attack and fraud detection inside of a loosely coupled service-oriented architecture.
Perhaps when the WS-Policy specification becomes a formal standard and support for it becomes widespread, the Web services management software won't be as critical to ensure policy adherence, but for right now Manes warned "policy administration is going to cause you a big headache if you don't have that in place."
She looked to traditional firewalls, VPNs and intrusion detection tools to handle the traditional entry points for the network, but stressed that XML security gateways, offered by companies like DataPower Technology Inc., Reactivity Inc. and Layer 7 Technologies Inc., are needed to add identity management and packet-level security at the intermediary points inside the network.
"You need to build a single environment for managing and enforcing security," Manes said. "The good news is smaller vendors are playing well together and their products can share administration and management."
In the grand security schematic, an external Web service call should enter through an XML security gateway for vetting, be passed to the Web services manager for policy adherence and distributed to the host system Web services via the agents provided by the management tool.
Manes added that the WS-Security standard is a good choice for defining corporate policies inside an SOA and that a UDDI registry should be integrated with the Web services manager in order to provide governance during design time as well as runtime.