Analysis: SOA Security
July 28, 2007
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.
