The simplest and most common approach to security for service-oriented architecture (SOA) is to route service requests over a virtual private \n\nnetwork (VPN). This provides adequate security for simple, coarse-grained requirements, it works with SOAP, REST, and non-Web services \n\nprotocols, and it is adequate even for many external integration scenarios. Yet not all security scenarios are simple, and for more complex needs \n\nand fine-grained SOA security, architects must do considerably more planning and design. To craft a comprehensive strategy and architecture for \n\nSOA security, architects must consider a wide diversity of security requirements, business scenarios, and application infrastructure, weaving \n\ntogether multiple products, standards, and custom-built components into a flexible and robust SOA security solution.[ For timely data center news and expert advice on data center strategy, see CIO.com's Data Center Drilldown section. ]At least 10 product categories can play a part in SOA security architecture, and there are major areas of functional overlap among them. The \n\nbuilding-block structure of SOA and Web services security specifications means architects must plan carefully for which specifications they will use \n\nand when to use them. Business scenarios with different security requirements may require different combinations of specifications and products. \n\nAdding even further to the complexity, the standards and specifications are still maturing, so there is little industry experience with best practices for \n\nmany of the specifications. Architects may face additional challenges including divergent SOA infrastructure, multiple SOA messaging exchange \n\npatterns, the need to federate security across multiple environments, and the need to propagate identity across layers as one service calls another. \n\nThis is not to mention common issues like organizational 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 \n\nfuture requirements, which means that architects final challenge is to evolve a comprehensive solution over time. To assist in pursuing an incremental \n\napproach, here is a continuum of four broad solution patterns that show how to combine diverse products into an SOA security solution for today's \n\nneeds 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 TimeAs a common starting point, some SOA users have immediate scenarios that require them to quickly find an acceptable \u2014 even if \n\nsuboptimal \u2014 SOA security solution. In these scenarios, SOA requests and responses are secured using only transport-level security. With \n\nSOAP and REST, this is typically accomplished via two-way secure socket layer (SSL). With VPN connections, even requests over the public \n\nInternet are confidential and secure. Often, simple VPN approaches use implicit authorization: Any request that comes in over the VPN is allowed \n\nto access the available services. Although a simple VPN can support identification of individual users, this is rare because of the administrative \n\noverhead of managing certificates for every user. A simple VPN is often configured as a direct transport-level connection between the service \n\nconsumer's platform and the service platform, which may be either an application server or a simple Web server environment. In a Forrester survey, \n\ntwo-thirds of SOA users said that using only a simple VPN is an important option in their SOA security arsenal.Scenario No. 2: Application-Server-Based Fulfills Audit And Compliance Requirements The middle of the continuum divides between two approaches, single intermediary and application-server-based, each of which is able to \n\nhandle authentication and authorization of individual users. The application-server-based approach builds on the SOA security features in service \n\nimplementation platforms (e.g., application servers, integration servers, packaged applications, and software-as-a-service). By allowing service \n\nplatforms to maintain security contexts based on the actual end user, this approach facilitates implementation of advanced authorization strategies. It \n\nalso allows audit logs to record actual end-user service request activity, which can be important for detailed auditing and compliance for privacy \n\nand other regulations. While it has the advantage of requiring no cash outlay for new SOA specialty products, if one has multiple platforms, the \n\nconfiguration and integration work required may cause the solution's cost in work hours to equal or exceed the cost of buying and configuring SOA \n\nspecialty products.Application-server-based SOA security will often use a simple VPN connection as a foundation. A possible extension of this scenario might \n\ninclude using an SOA or application server security plug-in from a single sign-on or identity management environment to provide for consistent \n\nsecurity between SOA services on an application server and other application assets controlled by the identity management product.Scenario No. 3: Single Intermediary Consolidates Security Processing The other side of the middle of the continuum is the single intermediary approach, which concentrates SOA security functions into a policy \n\nenforcement point that sits in front of ones service implementation platforms. This simplifies SOA security, providing a single solution (consisting of \n\nthe intermediary and its administrative tools) that can provide security across any and all SOA services (at least for the message formats and \n\nprotocols the intermediary supports). However, in the pure implementation of this approach, service platforms, in essence, turn off user-level SOA \n\nsecurity features in favor of trusting the intermediary for all SOA security. The intermediary might be provided by products from several different \n\ncategories including SOA appliances, SOA management solutions, enterprise service buses (ESBs), integration-centric business process \n\nmanagement suites (IC-BPMSs), or specialized SOA security products.A single intermediary approach might also use a simple VPN connection as a foundation. The intermediary handles all SOA security \n\nprocessing; therefore, service platforms are not required to have any specific SOA security support, which allows the solution to support a wide \n\nrange of service platforms. Scenario No. 4: Brokered, Layered, Federated Provides Comprehensive SOA Security At the far advanced end of the continuum, the SOA security solution is deeply integrated across multiple layers of service calls, ensuring that \n\neach service platform has access to the user's identity, and it supports advanced security scenarios such as federation and token exchange. Today, \n\nfew firms even approximate this type of solution. However, as SOA security solutions, standards, and products mature and as privacy and financial \n\nregulations get more stringent, advanced SOA security solutions will become more feasible (both financially and technically) and, indeed, may be \n\nmandatory for some scenarios. A brokered, layered, federated SOA security solution will use multiple standards, integrate multiple products, and \n\nvery likely require custom-built integration to pull all the pieces together.To account for evolution of your SOA security strategy over time, bake into your design as much consistency as possible between simpler \n\nSOA security patterns and more-complex ones. Although your organization may be accustomed to making security compromises to avoid the cost \n\nof an advanced brokered, layered, federated security strategy, an advanced strategy will become both easier to attain and more mandatory \n\novertime as SOA security matures and as requirements for cyber security increase.Randy Heffner is a Vice President at Forrester Research, serving Enterprise Architecture professionals. He is a leading expert on \n\narchitectures and design approaches for building enterprise applications that are secure and resilient in the face of continuous business and \n\ntechnology change.Follow everything from CIO.com on Twitter @CIOonline.