SOA/Web Services

SUBSCRIBE TO TMCnet
TMCnet - World's Largest Communications and Technology Community

 

January 12, 2007

Managing Enterprise Risks: Security Considerations in the Deployment of SOA

By TMCnet Special Guest
Lori MacVittie, Technical Marketing Manager, F5 Networks


One of the core value propositions of deploying a service oriented architecture (SOA) is the ability of the organization to better mitigate risk. Whether the organizational concern focuses on regulatory compliance or fine-grained control over the access of services, a well designed SOA can enable organizations to consistently apply security policies across all applications. Yet the distributed nature of a SOA results in a challenging environment in which to apply organizational security policies and can lead instead to a fragmented and inconsistent security infrastructure with serious performance implications.
 
Reducing Business Risk and Exposure
Security is no longer focused solely on restricting access to resources. In the enterprise it must also necessarily concern itself with regulatory compliance as the penalty for non-compliance can impact both the company’s financial position as well as the liberty of its executives. Regulations like Sarbanes Oxley, the PATRIOT Act, and Basel II as well as myriad state regulations focused on data privacy and protection are the concern of both business and IT. While generally accepted best practices for safeguarding data have long been implemented through the control of access to that data, the enterprise must also have a planned defense against the potential failure of those controls.
 
In a service-oriented deployment there are a number of touch-points at which control over access can fail. An application is no longer a self-contained entity with only a few external resources, it is now comprised of multiple services, which may or may not be self-contained and which almost certainly access external sources of data.
 
In addition to the increase in the number of touch points that must be secured against unauthorized access, a SOA changes the way in which credentials are carried from one system to another. Nearly all SOA implementations are based on XML messages, the majority of those utilizing SOAP (Simple Object Access Protocol) as its primary application-layer transport protocol. SOAP intentionally carries with it no authentication or authorization data, leaving such specialized protocols to be defined by other standards such as SAML (Security Assertion Markup Language) and WS-Security.
 
Regardless of the security protocol used as the basis for authorization and authentication it will be transported in the clear and is, because of the nature of XML, human readable. Best practices dictate that a proven method of securing the transport of sensitive data across the network be used to prevent prying eyes from gleaning information from messages. SSL has long been used as a mechanism through which trust can be established — certificates — and data can be secured — encryption.
 
But the use of SSL has always come at the cost of performance, and traditionally it has been accepted that such compute intensive processes as encryption and decryption be offloaded from Web and application servers to an application delivery controller. This has the effect of providing for the establishment of trust through certificates and better performing encryption and decryption while providing centralized management of certificates and increased capacity on Web and application servers by offloading SSL-based functions.
 
This traditional wisdom is even more true in a SOA environment where distributed certificates and encryption/decryption services will be applied multiple times per application rather than once, as is the case with traditional applications. Imagine a single application (a business process) comprised of five business services: billing, provisioning, account management, customer management, and self-service options. If each server on which these services reside is required to maintain its own certificate and encrypt/decrypt messages to and from the service there will certainly be a significant negative impact on the overall performance of the application.
 
Utilizing an application delivery controller at the entry and control point to the application removes the need for each service to provide encryption/decryption functionality and creates a single enforcement point through which all security policies can be applied – included authentication and authorization. The use of an application delivery controller centralizes control over resources and the security of messages in flight by acting as an application front end through which requests and responses must necessarily flow. This has the additional benefit of providing a consistent security model for all services and therefore all applications.
 
The Possibility of Failure
No one likes to admit to failure nor do they enjoy playing devil’s advocate when the issue arises during planning. But just as several disasters in the past five years have taught us the value of disaster recovery planning and implementation, so should the numerous cases of information leaks that have occurred in the past few years. While it would be great if the controls placed upon the services that make up your SOA worked perfectly and no data was ever accessed that was not expressly allowed, with each service deployed the possibility of unauthorized data access increases.
 
Assume for a moment that somehow a service has been coerced by a malicious request to respond with far more data than the credentials normally allow. How will you stop that data from leaking outside the bounds of your corporate network and into the hands of unauthorized users? Even worse, perhaps the transport has been encrypted using SSL, but the credentials passed were forged or failed to adequately shield data from breaches protected by regulatory agencies. Once the data is encrypted how can you inspect it to determine whether or not sensitive data is about to leave your network?
 
Consider, also, the handling of SOAP faults and exceptions. These messages carry a plethora of information that can be used by attackers to piece together a fairly accurate map of your application infrastructure, which can in turn be used to exploit those systems. While these messages are necessary for proper inter-service application handling, they should not be permitted to flow across the network and into the user’s hands.
 
An application-fluent application delivery controller easily deals with both the issue of SOAP faults and exceptions and the encryption-inspection conundrum. The application delivery controller is capable of terminating the SSL session and can therefore decrypt and inspect outbound messages that might contain sensitive data. A truly application-fluent delivery controller can then perform a number of actions on messages containing sensitive data, including masking the data or refusing to deliver the message. Similarly, the application-fluent delivery controller can inspect outbound messages for SOAP faults and exceptions and replace them, mask them, or go a step further and become a part of the business process by retransmitting the original message based on user-specified options.
 
While this functionality could certainly be implemented at the service level, in a SOA there are multiple services, which would need to contain such checks, requiring duplication of code and efforts every time those services need to be updated. By centralizing this risk mitigating behavior in a network device such as an application controller, all services and applications in a SOA are automatically protected.
 
The SON
In addition to the broader issues of authentication, authorization and security of the transport layer is the need for the network to understand SOA messages, for a Service Oriented Network (SON).
 
A (SON) is constructed around network devices that are far more intelligent than those found on traditional networks — devices that recognize that SOA traffic is fundamentally different from other network traffic. The SON must clearly and unambiguously understand Web services language while loosely coupling network resources such as SSL, certificate management, and centralized authentication.
 
What are needed as part of the SON, are intelligent full-proxy devices, which can identify SOAP faults or exceptions. Smart network devices in the SON can also prioritize requests based on enforce rules and logic, actually removing the overhead from the servers that support the requests.
 
There are other complicating factors that further point to the need for significant changes in the underlying network infrastructure to support SOA and Web services traffic. Many companies seeking to either dive into or at least dip their toes into the SOA waters turn initially to various development tools vendors to build connected applications and services. With the right considerations and strategies in place, companies can securely and reliably support SOA traffic well.
 
Services-oriented Networks checklist
  • Carefully assess the network impact of Web services and SOA prior to deployment.
  • Make sure that representatives from each of the security, application and network groups are involved in SOA planning.
  • Devise strategies and deploy network devices that intelligently offload the additional overhead that XML and related traffic places on CPUs.
  • Rethink security requirements due to the new threats XML can bring to SOA deployments.
  • Choose network products that are inherently flexible within an architecture that can easily accommodate future applications and protocols with enterprise-grade security.
 
Lori MacVittie is a Technical Marketing Manager for F5 Networks (News - Alert). She can be reached at l.macvittie@f5.com.
 



Technology Marketing Corporation

35 Nutmeg Drive Suite 340, Trumbull, Connecticut 06611 USA
Ph: 800-243-6002, 203-852-6800
Fx: 203-866-3326

General comments: tmc@tmcnet.com.
Comments about this site: webmaster@tmcnet.com.

STAY CURRENT YOUR WAY

© 2019 Technology Marketing Corporation. All rights reserved | Privacy Policy