Web services have always been sold as a way to share data among organizations: An enterprise can selectively open internal systems to customers, partners, and suppliers, automating transactions that once required human intervention. While most businesses have so far steered clear, keeping Web services tucked safely behind the firewall, the growth of service-oriented architecture and the emergence of Web 2.0 look set to change that.

Will the rewards be worth the risks of exposing internal services to the Web? It's not helping that interoperability woes are exacerbated by the immaturity of SOA security standards. 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. Virtualization adds yet another twist.

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. Two incompatible standards have emerged here, offering much the same functionality. 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.

Got that crystal ball handy?

(click image for larger view)