Security Issues in the Service-Oriented Architecture

Jul. 1, 2003 12:00 AM

Who doesn't love the service-oriented architecture (SOA)? You get efficiency in your application development, revolutionary ability to interoperate with partners and suppliers, and mastery over change management that was never before possible.

With the technologies available today to take advantage of SOAs in enterprise settings, organizations can quickly find themselves faced with many concurrent decisions and implementations. Your staff is exposing legacy applications as Web services in Visual Studio .NET and JBuilder. Partners are clamoring for access to your systems using Web services. Your boss wants to connect the company to key customers using Web services. No problem? Big problem: security.

SOA security is the two-ton elephant stomping through the data center. According to ZapThink, "Security is the immediate roadblock facing widespread implementation of Web services technologies across the enterprise." Security problems have hampered many organizations in advancing SOA ambitions.

The good news is that help is on the way. The complicated truth about SOA security is that it is a manageable, straightforward matter if addressed intelligently at the outset. There are a number of promising SOA and Web services security solutions, particularly in the focused Web services management platforms, coming onto the market today that help tackle security issues. With reasonable planning and understanding of the issues involved, it becomes possible to design and implement a successful, secure SOA.

The Issues
The SOA's inherent security problems stem from the ways in which the SOA replaces traditional security parameters with new, open standards. The efficiency of Web services is in interoperability standards, and with that efficiency comes a proportional increase in risk. Imagine exposing your data in a manner that makes it accessible to anyone who just bought SOAP for Dummies at the local bookstore. The security problem is twofold in that not only are the new standards completely open - i.e., no one owns them - but they were also developed without security in mind.

Why do SOAs inherently contain security risks? The answer lies partly in the origins of the SOA. Web services were developed over a period of years by industry consensus as a way to, among other things, enable the creation of reusable code, simplify development, and streamline system integration. While these goals were met, the open standards that emerged neglected to address security. Specifically, XML, SOAP, WSDL, and UDDI are open standards that enable the transmission and description of data and procedure calls between systems. However, none of these open standards contain any inherent security aspects of their own. If left alone, they are completely insecure. In fact, Web services were designed to be able to move efficiently through firewalls. Their very openness actually exposes their insecurity all the more.

The nature of the SOA also disrupts the traditional security paradigm in several critical ways:

Machine-to-machine communication: Most security infrastructure is geared toward human-to-machine interaction, while Web services involve machine-to-machine interaction. Unauthorized users may find it simple to penetrate and evade detection in SOAs, as compared to traditional architectures, because they are going after exposed application functionality that has no human screening. In addition, these exposed interfaces are offered in a convenient standards-based form. It's similar to posting your home address in the phone book, and then handing out keys to your house with every copy.

Securing unknown third parties: By their nature, SOAs may require that an entity authenticate and grant authorization to users from outside its system. To be secure, an SOA must have a way to address the security apparatus of a third party in order to authenticate and authorize use of the service.

Flooding: Malicious, unauthorized users can "flood" an SOA with service requests and render it inoperable - a denial of service (DoS) attack.

Unwanted "listening in": In contrast to traditional architectures that allow messages to be exchanged either exclusively within the firewall or through private networks, Web services messages may travel across the Internet, where they are vulnerable to eavesdropping by unknown individuals.

Service-level agreement (SLA): The SOA has no way of monitoring or assuring the service levels of Web services, crippling the ability of system administrators to identify and respond to security problems in a timely manner.

No logging: The unsecured SOA has no message- and transaction-logging mechanism. After a service has been called and used, there is no way to determine who has used the service and from where the request originated. As a result, there is no audit trail that can be used later to investigate possible breaches in security.

No encryption: The unsecured SOA has no encryption protocol embedded in its architecture. Messages that are intercepted can be read by anyone.

These challenges can be somewhat intimidating when it comes to transitioning to an SOA. However, it is important not to overlook the incredible cost savings and efficiency that come from an SOA in addition to the inevitability of this computing model. Those looking to implement an SOA should be encouraged that Web services security products, techniques, and standards are fast proving to be ready for prime time.

Example - Supply Chain Management
To illustrate the security problems inherent in SOAs, let's look at a typical supply chain management process that involves a manufacturer and three vendors. Figure 1 represents the traditional business-to-business security environment:

Each vendor communicates with the manufacturer using a private network.

Encryption may be used, but the manufacturer and vendor can both be fairly confident that communication is private.

Authentication is coded into the application, so the manufacturer can be relatively confident that Vendor A is actually Vendor A.

Authorization is, in addition to being coded into the applications, also handled by the security infrastructure of the entity originating the transmission.

Though secure, this traditional setup is costly and complex to maintain:

Modifications to the manufacturer's application will automatically require custom revisions to the vendor's application or else they will not be able to communicate.

Flexibility in extending the functionality of these connected applications is limited to the amount of custom interface development that each trading partner wants to finance.

If the manufacturer and its vendors decide to expose applications as Web services in an SOA, they benefit from greatly increased flexibility, but face security risks. Figure 2 shows what this SOA would look like. Applications developed in this environment have numerous potential functional advantages over the traditional model, including:

The vendor's ability to create applications that easily interact with the manufacturer's ERP system - "pulling" order data out of the system based on anticipated demand.

The manufacturer's and vendor's mutual ability to process financial matters between their respective accounting systems.

This is all accomplished without needing any proprietary software to create custom interfaces and remote procedure calls, without requiring a dedicated private network, and without even having to develop any code - it may already exist as a reusable Web service.

Unfortunately, however, the SOA shown in Figure 2 also contains a variety of security risks. Because the messages may travel across public networks, they can be "listened to" by others, they can be intercepted and changed, and they can be rerouted for the purpose of fraud or malicious mischief. In addition:

Whatever hard-coded authorization process existed in the traditional model does not exist here.

Neither the manufacturer nor the vendor knows who is authorized to access specific Web services.

A hacker could configure a machine to impersonate a vendor's system and make erroneous or fraudulent service calls.

The SOA can be overloaded by service calls, resulting in a DoS attack, and there is no audit trail to determine who has done what and at what time.

Building Security into Your SOA Through a Web Services Management Platform
To secure an SOA, it is best to identify, acquire, and implement a robust Web services management platform that will intercept SOAP messages and enforce security policies. Ideally, the platform selected will have the capability to connect with any existing security framework currently in use in the enterprise, even if stand-alone implementation is chosen in the first stage.

A suitable Web services management platform will tackle the most pressing security issues in an SOA. It should monitor the SOAP requests, authenticate users, establish authorization, encrypt, provide signatures and certificates, and assure contractually promised service responses. Figure 3 shows the standard Web service request and response transmitted in SOAP over HTTP. In Figure 4, the Web services management platform adds security to this process by authenticating the requesting user and encrypting both the request and the response using an SSL. The result is an SOA that operates in HTTP-S.

The following is a checklist of features that must be delivered in the Web services management platform that you select to secure your SOA:

Federated authentication: A framework should utilize Security Assertion Markup Language (SAML), Web Service Security (WS-Security), and Java Authentication and Authorization Service (JAAS) open standards to implement a flexible, federated security architecture that can be easily integrated into existing enterprise environments as needed.

Application proxy: The platform should provide a secure proxy for the Web services exposed in your enterprise. It should decouple and protect internal Web services from external users and trading partners, as well as proxy-approved external services from users and applications within the organization.

Secure Sockets Layer (SSL): The platform should support SSL, thereby facilitating 40-bit or 128-bit secure communications at the HTTP level.

Contract management: You should be able to configure the platform to permit access to a service through a service contract. The contract specifies the terms between a service provider and consumer and is associated with an SLA. For example, start date and time, end date and time, and access count.

Digital signing: Digital signatures facilitate an implicit trust relationship between a service provider, the service consumer, and the Web services management platform.

XML encryption: The platform should enable you to perform XML encryption at the element level in the SOAP message. This allows service providers to increase the level of security for a particular operation within a service.

Replay attack protection: The platform should provide Web services within your enterprise with protection from replay attacks by keeping track of SOAP requests and ensuring that the same request is not replayed. This helps eliminate DoS attacks and errors in contract usage and billing.

Auditing: It is essential to track and log all service calls to provide a mechanism to audit and reconcile all service transactions.

Conclusion
Though it may seem as if there is a myriad of complex issues surrounding security in the SOA, the bottom line is that you can accomplish most if not all of your security goals with the more robust Web services management platforms on the market today. By managing a vendor-neutral, standards-based architecture in this manner you can take advantage of all the capabilities of existing security vendors (Netegrity, RSA, CA, etc.) in the context of a robust SOA framework. Then, if you work carefully to design security into the SOA from the outset, extending the same level of attention and concern for security that you have used in previous enterprise architecture efforts, you will find that your SOA will be able to operate smoothly and securely, even as it grows.

Related Links

About Eric Pulier
Eric Pulier has been a pioneer in the software and digital interactive industries for over 15 years. As CEO of Digital Evolution, Mr. Pulier devotes himself to a singular focus: the standards-based real-time enterprise. Toward this end, Mr. Pulier is currently driving Digital Evolution's development and joint venture relationships with some of the largest companies in the world.

In 1997, the Presidential Inaugural Committee selected Mr. Pulier to create and execute the Presidential Technology Exhibition in Washington D.C. Subsequently, the President and Vice President personally unveiled DE's work for the Starbright Foundation, and Mr. Pulier became an advisor to the Vice President on National Health Care initiatives for the Family Reunion Conference. The most successful and best-known venture capital groups in the world have financed companies that Mr. Pulier has founded or co-founded. Mr. Pulier has been instrumental in establishing ground-breaking technology companies in several sectors including media management (IVT), Professional Services (US Interactive), voice systems (VoiceTap), and peer-to-peer networking (Mediator).

Recently named one of 30 e-Visionaries by VAR Business, Mr. Pulier is a popular public speaker at elite technology conferences around the globe. Mr. Pulier is a member of the board of directors for the Center for Telecommunications Management and a Magna cum laude graduate of Harvard University.