Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

SOA security solutions: Four patterns to grow on

Randy Heffner | Dec. 2, 2009
Architects must plan carefully for which specifications they will use and when to use them. We run through four exemplary scenarios here.
At least 10 product categories can play a part in SOA security architecture, and there are major areas of functional overlap among them. The building-block structure of SOA and Web services security specifications means architects must plan carefully for which specifications they will use and when to use them. Business scenarios with different security requirements may require different combinations of specifications and products. Adding even further to the complexity, the standards and specifications are still maturing, so there is little industry experience with best practices for many of the specifications. Architects may face additional challenges including divergent SOA infrastructure, multiple SOA messaging exchange patterns, the need to federate security across multiple environments, and the need to propagate identity across layers as one service calls another. This is not to mention common issues like organisational friction, cost and difficulties with architecture governance.

Because of these complexities, few can afford to invest upfront to build a complete and comprehensive SOA security solution that addresses all future requirements, which means that architects final challenge is to evolve a comprehensive solution over time. To assist in pursuing an incremental approach, here is a continuum of four broad solution patterns that show how to combine diverse products into an SOA security solution for today's needs as well as how today's solution can leave a path open for tomorrow's needs.

Scenario No. 1: Simple VPN Provides A Basic Solution In A Short Time

As a common starting point, some SOA users have immediate scenarios that require them to quickly find an acceptableeven if suboptimalSOA security solution. In these scenarios, SOA requests and responses are secured using only transport-level security. With SOAP and REST, this is typically accomplished via two-way secure socket layer (SSL). With VPN connections, even requests over the public Internet are confidential and secure. Often, simple VPN approaches use implicit authorisation: Any request that comes in over the VPN is allowed to access the available services. Although a simple VPN can support identification of individual users, this is rare because of the administrative overhead of managing certificates for every user. A simple VPN is often configured as a direct transport-level connection between the service consumer's platform and the service platform, which may be either an application server or a simple Web server environment. In a Forrester survey, two-thirds of SOA users said that using only a simple VPN is an important option in their SOA security arsenal.


1  2  3  Next Page