Type your search and hit enter
SOA security: good enough and getting better

SOA security: good enough and getting better

Forrester Research SOA expert Randy Heffner discusses how to establish an iterative design process for evolving your SOA security architecture that considers your current and future security requirements.

Security is not a reason to stay away from SOA. Although full SOA security maturity is yet to come, 30 percent of organizations now use SOA for external integration with customers and partners.

For standard Web services using SOAP, WS-Security has achieved critical mass as a foundational standard. On the other hand, advanced SOA security - involving federation among partners, nonrepudiation, and propagation of user identities across multiple layers of service implementations - is in its early days. To navigate the path from what's practical today to the future of advanced SOA security, establish an iterative design process for evolving your SOA security architecture that considers your current and future security requirements, emerging industry specifications, overlaps in product functionality for SOA security, and possibilities for custom security integration.

As a baseline for designing SOA security, the simplest way to secure SOA requests and responses is to place them within a virtual private network (VPN). The most common method for external SOA security is two-way Secure Sockets Layer (SSL), which: 1) allows each of the communicating partners to authenticate the other, and 2) sets a high bar for security: Hackers cannot even connect to an SOA-based service unless they steal a certificate and key from a service consumer. Although VPNs are relatively easy to establish, VPN-based SOA security is coarse-grained and offers no ability to support advanced functions such as: propagation of user identity across multiple layers of service implementations; coordination and federation among multiple security domains; and strict nonrepudiation. Also ongoing management of certificates can be an administrative burden.

Other major alternatives for SOA security include leveraging existing SOA security features in Java or .NET application platforms and concentrating SOA security within an SOA specialty product such as an enterprise service bus, SOA and Web services management solution, SOA security server, or SOA appliance. Appliances provide the simplest and most focused "drop-in" solution for SOA security, but there are intricate 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, Historically, organizations have been reticent to tackle the difficulties of implementing advanced application security requirements. As SOA security implementations mature - along with broader architectures for security federation - it will become easier to implement advanced security scenarios. Many user organizations will find that advanced SOA security becomes mandatory - especially with increasing data privacy 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 open 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 strong guidelines and code reviews, embedding security into application code is risky both in terms of achieving consistent security and of allowing future flexibility and enhancement of application security. Note that keeping developers from having to write code for security does not eliminate the need to train application developers to use secure coding practices. Secure coding is a separate realm of application security practice, involving concerns 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 where you:

1.Identify Your Security Requirements. Assess your requirements against a broad, strategic list of security functions. This forms the foundation for designing your SOA security strategy and solution. Organize requirements according to the major design focal points of your SOA-based solution. Forrester uses a model organized around the service consumer, the request-response, the service provider, and the security environment. As you continue through the iterative process for SOA security design, you may have to reconsider selected requirements as you learn more about standards, products, and your organization's ability to pay for the SOA security your requirements imply.

2.Determine Your Use of SOA Security Specifications. Your SOA security requirements set the stage for determining the range of SOA security specifications that might meet your requirements. When choosing the actual specifications you will use, however, you must account for which specifications the products in your infrastructure (existing products, plus new ones that you may buy for SOA) will support. Core specifications include WS-Security, WS-I Basic Security Profile, XML Encryption, and XML Signature. Advanced specifications include WS-Trust, WS-SecurityPolicy, WS-Federation, XACML, and WS-SecureConversation.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags SOA

More about etworkForrester Research

Show Comments