SOA Security: One Treacherous Journey - InformationWeek
IoT
IoT
Software // Enterprise Applications
News
7/26/2007
03:30 PM
Andy Dornan
Andy Dornan
Features
50%
50%

SOA Security: One Treacherous Journey

Are you ready to deal with the risks of opening your service-oriented architecture to business partners?

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.

InformationWeek Download

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?

Imapct Assessment: SOA Security

(click image for larger view)

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Previous
1 of 5
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
6 Tech Trends for the Enterprise in 2019
Calvin Hennick, Technology Writer,  11/16/2018
Commentary
Tech Vendors to Watch in 2019
Susan Fogarty, Editor in Chief,  11/13/2018
Commentary
How Automation Empowers the CIO to Think Outside the IT Department
Guest Commentary, Guest Commentary,  11/20/2018
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
Enterprise Software Options: Legacy vs. Cloud
InformationWeek's December Trend Report helps IT leaders rethink their enterprise software systems and consider whether cloud-based options like SaaS may better serve their needs.
Slideshows
Flash Poll