To lock down a large Web services network involving multiple enterprises, everyone must agree on technologies, even security policies: There’s no use demanding that your employees use biometrics and physical tokens if a partner’s staff accesses the system with weak passwords.
Before buying the elements of SOA security, do your homework, because the market is in flux. On balance, the movement we’re seeing is good news for IT because it means more choices and potentially fewer vendors to deal with. But it also makes buying decisions a lot more complex.
For example, Web services exposed to the Internet need XML firewalls, also known as SOA security gateways. However, this product category is disappearing thanks to ongoing SOA consolidation.
Meanwhile, with XML firewall functionality rolled into everything from management platforms to core switches, what kind of product to use–even basic decisions such as whether to use hardware or software–will depend on the scale and predicted growth of each enterprise’s Web services, as well as any existing SOA infrastructure.
Decisions around encryption and authentication are harder, as they don’t depend on a single organization. Everyone in a Web services extranet needs to be using the same technologies, and right now, there are several competing standards. The biggest conflict is over identity management, the complex exercise of ensuring that a user or process logged on to one company’s systems is authorized to use those of a partner. The first, SAML (Security Assertion Markup Language), is supported by almost everyone–except Microsoft. Redmond prefers the newer WS-Federation, which is more tightly bound to other Web services standards. Although both use XML, the two are incompatible, meaning enterprises with public Web services must either support both or ensure that all their business partners using secure Web services choose the same standard.
To help, Oasis (Organization for the Advancement of Structured Information Standards) created WS-Security, a standard for applying XML Security and XML Encryption in Web services. Its main weakness is that, like all the WS-* standards, WS-Security requires SOAP–anyone doing business with Web services running REST (Representational State Transfer, a way of describing XML Web services that don’t use SOAP) need not apply.
Though WS-Security helps encrypt and sign SOAP messages, it doesn’t say anything about AAA (authentication, authorization, and accounting) or security policies. The exception is federated identity, where the relatively new WS-Federation and WS-Trust are competing with SAML 2.0, an established standard also published by Oasis. The main practical difference is that SAML uses XML Encryption and XML Signature directly, meaning it can work with REST, whereas WS-Federation requires SOAP. SAML also has a large installed base, though this may not count for much because Microsoft has thrown its weight behind WS-Federation and said it will not support SAML.
Unlike some other standards battles, this isn’t simply a case of Microsoft vs. everyone else.
On the public Internet, firewalls were one of the earliest drivers for Web services. Although different organizations have different security policies, almost all need to keep Port 80 open, so vendors and standards bodies gravitated toward text-based protocols that run over HTTP. And, for the same reason, so did attackers and malware. As a result, companies publishing Web services to the Internet have traditionally used application security gateways, appliances that can read and understand application-layer documents, filtering out potential attacks. The deep-packet inspection and understanding of XML required to recognize attacks also makes security gateways useful for XML transformation and routing, and often better at it than management software, thanks to specialized SSL or XML acceleration hardware. The other independent security gateway vendors–Layer 7, Vordel, and Xtradyne–are moving in the opposite direction, toward software and virtualization. Vordel and Xtradyne have always distributed their gateways as software, intended to be installed on dedicated blade servers.
http://www.informationweek.com/news/showArticle.jhtml;jsessionid=AWX5VKJHPYNXCQSNDLRSKH0CJUNN2JVN?articleID=201201384