Security is not a reason to stay away from SOA. Although full SOA security maturity is yet to come, 30 percent of organizations now \n\nuse SOA for external integration with customers and partners. For standard Web services using SOAP, WS-Security has achieved critical mass \n\nas a foundational standard. On the other hand, advanced SOA security \u2014 involving federation among partners, nonrepudiation, and \n\npropagation of user identities across multiple layers of service implementations \u2014 is in its early days. To navigate the path from what's \n\npractical today to the future of advanced SOA security, establish an iterative design process for evolving your SOA security architecture that \n\nconsiders your current and future security requirements, emerging industry specifications, overlaps in product functionality for SOA security, and \n\npossibilities for custom security integration.\n MORE ON SOA\n \n SOA Security: the Basics\n \n SOA Definition and Solutions\n \n SOA Security: How Irish Luck Went a Long Way\n \n Are you Insecure about SOA Security?\n As a baseline for designing SOA security, the simplest way to secure SOA requests and responses is to place them within a virtual private \n\nnetwork (VPN). The most common method for external SOA security is two-way Secure Sockets Layer (SSL), which: 1) allows each of the \n\ncommunicating partners to authenticate the other, and 2) sets a high bar for security: Hackers cannot even connect to an SOA-based service \n\nunless they steal a certificate and key from a service consumer. Although VPNs are relatively easy to establish, VPN-based SOA security is \n\ncoarse-grained and offers no ability to support advanced functions such as: propagation of user identity across multiple layers of service \n\nimplementations; coordination and federation among multiple security domains; and strict nonrepudiation. Also ongoing management of certificates \n\ncan be an administrative burden.Other major alternatives for SOA security include leveraging existing SOA security features in Java or .NET application platforms and \n\nconcentrating SOA security within an SOA specialty product such as an enterprise service bus, SOA and Web services management solution, \n\nSOA security server, or SOA appliance. Appliances provide the simplest and most focused "drop-in" solution for SOA security, but there are \n\nintricate trade-offs to consider among the SOA specialty products as you build your overall SOA platform.Even with the emerging features of application servers and SOA specialty products, simple SOA security solutions can be compelling, \n\nHistorically, organizations have been reticent to tackle the difficulties of implementing advanced application security requirements. As SOA security \n\nimplementations mature \u2014 along with broader architectures for security federation \u2014 it will become easier to implement advanced \n\nsecurity scenarios. Many user organizations will find that advanced SOA security becomes mandatory \u2014 especially with increasing data \n\nprivacy and other regulations. Thus it is important, even if you start with a simple SOA security solution, to anticipate the need for and leave paths \n\nopen to build additional, deeper security functionality as business requirements demand and SOA security maturity allows.Forrester strongly recommends that you design a solution that does not require application developers to do security-related coding. Even with \n\nstrong guidelines and code reviews, embedding security into application code is risky both in terms of achieving consistent security and of allowing \n\nfuture flexibility and enhancement of application security. Note that keeping developers from having to write code for security does not eliminate \n\nthe need to train application developers to use secure coding practices. Secure coding is a separate realm of application security practice, involving \n\nconcerns such as ensuring that application failures do not open security holes.Finding the right combination of industry standards, products, integrations, and frameworks for your security strategy is an iterative process \n\nwhere you:1.\tIdentify Your Security Requirements. Assess your requirements against a broad, strategic list of security functions. This forms the \n\nfoundation for designing your SOA security strategy and solution. Organize requirements according to the major design focal points of your \n\nSOA-based solution. Forrester uses a model organized around the service consumer, the request-response, the service provider, and the security \n\nenvironment. As you continue through the iterative process for SOA security design, you may have to reconsider selected requirements as you \n\nlearn more about standards, products, and your organization's ability to pay for the SOA security your requirements imply. \n\n2.\tDetermine Your Use of SOA Security Specifications. Your SOA security requirements set the stage for determining the range of \n\nSOA security specifications that might meet your requirements. When choosing the actual specifications you will use, however, you must account \n\nfor which specifications the products in your infrastructure (existing products, plus new ones that you may buy for SOA) will support. Core \n\nspecifications include WS-Security, WS-I Basic Security Profile, XML Encryption, and XML Signature. Advanced specifications include \n\nWS-Trust, WS-SecurityPolicy, WS-Federation, XACML, and WS-SecureConversation.\n\n3.\tSelect the Products that will Provide Your Core SOA Security Functions. Many functions within an SOA security solution, such \n\nas performing authentication using WS-Security headers, can be performed by multiple product types in different product categories. Your design \n\nprocess will have to consider each option, assess the trade-offs, and select one product (or a coordinated set of products) to provide the core \n\nfunctions for SOA security. Key product categories that might contribute to your SOA security solution include: SOA appliances, SOA \n\nmanagement solutions, enterprise service buses, SOA security servers, application servers, security token servers, entitlements management \n\nservers, and identity and access management solutions.\n\n4.\tConfigure and Integrate Products to Work Together. It's likely that you will have multiple products that perform a given SOA \n\nsecurity function, and the products will have to be integrated to work coherently together. Much of this integration may be done with product \n\nconfiguration options (e.g., configuring an SOA appliance to delegate authentication to a particular single sign-on product), but it may require \n\nbuilding integration components using product programming interfaces. \n\n5.\tFill in the Holes with Frameworks. After the product integration is done, it may be useful to build helper frameworks for \n\napplication developers so that they will not have to write security code within their SOA-based applications.\n\nForrester recommends using an iterative process for two primary reasons. First, typically not all applications need all of your security \n\nrequirements; initial applications may be able to do with a lighter-weight pass on building your SOA security solution, while later applications \n\nrequire you to fill in your solution with additional features. Second, each time you make a pass through, you will learn more about how to build the \n\nmost effective SOA security solution with the pieces that you have.SOA leaders are still paving the road for the rest to follow. For some organizations, there may be a business scenario where advanced security \n\nhas a high value. Such organizations can justify the cost of building advanced SOA security solutions. These leaders will, along the way, help \n\nsolidify industry specifications and help vendors mature their products. If your organization is one with immediate needs for advanced SOA \n\nsecurity, there are many available products and standards to build on, but proceed with caution: You should build extra time into project plans for \n\nprototyping, product debugging, and performance and scalability testing.Randy Heffner is a Vice President at Forrester \n\nResearch, serving Enterprise Architecture professionals. He is a leading expert on architectures and design approaches for building enterprise \n\napplications that are secure and resilient in the face of continuous business and technology change. Do you Tweet? Follow everything from CIO.com on Twitter @CIOonline.