Why traditional security doesn't work for SOA

Many organizations are embracing SOA as a way to increase application flexibility, make integration more manageable, lower development costs, and better align technology systems to business processes. The appeal of SOA is that it divides an organization's IT infrastructure into services, each of which implements a business process consumable by users and services.

For example, a service may expose the functionality to add a new employee to the employer's payroll and benefits system. To make services usable in multiple contexts, for both lowered cost and increased process consistency, each service provides a contract describing how it may be used and what functionality it contains.

But the SOA approach turns on its head the traditional security approach used by enterprises today. The mix-and-match nature of SOA services, and the use of messaging as the orchestration mechanism for SOA's composite applications, eliminates the ability to build clear boundaries around -- and security barriers for -- enterprise apps. The very thing that gives SOA its flexibility also increases its security risk.

Service contracts expose your treasures

Consider how a typical service executes on a typical SOA infrastructure: Users and services communicate by passing messages between each other across the ESB (enterprise service bus). The ESB acts as a message conduit for the organization and understands the available services, their semantics, and how to get an application message from one point to another. Each service on the ESB must be addressable using the ESB's standard message-passing protocol (usually SOAP).

To make services easier to consume, each service must also have a way of describing itself and how the service is to be used. This description is called a service contract and is most commonly described via WSDL (Web Service Description Language). Few development methodologies have embraced the principle of interoperable contracts as tightly as SOA. To ease collection and discovery of new contracts, in many SOA architectures each service possesses a method for clients to query and retrieve the contract. This method for retrieving contracts is often standardized, if not by the application framework vendor, then by SOA practitioners themselves.

Standardized contracts and contract retrieval methods make SOA systems more discoverable. And therein lies one of the new security risks of SOA.

Such freely available contracts are very helpful for developers as they build new services and reuse existing services across the enterprise. Unfortunately, what works for the developer is equally helpful for attackers looking to understand the enterprise and its services. Attackers can collect these contracts and use them to easily create an internal treasure map of an organization. To identify high-value targets, the attacker uses the map and reviews the contracts for services that have weak authentication or are responsible for high-value services such as security management.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark