Establishing trust in a service-oriented marketplace by means of Information Security

CONTENTS

List of Abbreviations List of Figures

List of Tables

List of Code Samples

Introduction
Motivation
Definitions

1 soma: A Service-oriented electronic Marketplace
1.1 Overview
1.2 Technology
1.2.1 Architecture
1.2.2 Implementation

2 Web Services and Security
2.1 Security Implications of Web Services
2.1.1 Web Services Basics
2.1.2 Opportunities and Risks of Web Services
2.2 Infrastructure Standards in a Nutshell
2.2.1 SOAP
2.2.2 WSDL
2.2.3 UDDI
2.2.4 BPEL
2.3 Security Standards
2.3.1 XML Encryption
2.3.2 XML Digital Signature
2.3.3 Security Assertion Markup Language
2.3.4 WS-Security
2.3.5 Web Services Policy Framework

3 Security Analysis of soma
3.1 Overview
3.2 Security Cube Approach
3.3 Results
3.4 A Basic Security Policy for soma
3.4.1 Development
3.4.2 Frontend Pages
3.4.3 Backend Web Services
3.4.4 Third Party Web Services
3.4.5 Process Composition
3.4.6 Underlying Technology
3.4.7 Message Exchange
3.4.8 Virus Protection
3.4.9 Firewalls
3.4.10 Accountability
3.4.11 Detection and Reaction

4 The soma Security Infrastructure
4.1 General Aspects
4.1.1 Building a Security Domain
4.1.2 Security Services Placement
4.1.3 Confidentiality
4.2 Security Services
4.2.1 Authentication
4.2.2 Authorization
4.2.3 Auditing
4.2.4 Security Administration

5 Summary and Outlook

Bibliography

LIST OF ABBREVIATIONS

illustration not visible in this excerpt

List of Figures

1 Biggest Obstacle to Implementing Web Services

2 Web Service-oriented Architecture

3 Layer Architecture of soma

4 Frontend of soma

5 Web Services Technology Stack

6 Digital Signature Verification Process

7 Dynamic Security Process

8 IT Security Perspectives Cube

9 soma Technology Stack

10 Computer Systems Abstraction Layers

11 Encryption Using TLS in the ISO/OSI Layer Model

12 Web Services Process Chain

13 Login Process

14 Role Based Access Control

List of Tables

1 UDDI Data Structures

2 WS-Policy Operators

3 Threats

4 Countermeasures: Prevention

5 Countermeasures: Detection

6 Countermeasures: Reaction

List of Code Samples

1 SOAP Message

2 BPEL Process Definition

3 XML Encryption

4 XML Digital Signature

5 Web Services Security Language

6 Web Services Policy Framework

Introduction

Motivation

Advantages of electronic procurement via the Internet are manifold. Low transaction costs, independence of location and a broad scope are promising features.^[1] Nonetheless, problems occur when moving traditional negotiation forms to the Internet. Classic ne- gotiations give the participants the freedom to use whatever protocol they agree upon. Contemporary electronic marketplaces in contrast are restrictive and facilities for cus- tomization are often unavailable or rudimentary at most.^[2]

Individual composition of arbitrary business processes could provide what electronic mar- ketplaces lack today. On top of a service-oriented architecture providing standard ser- vices, marketplace systems could allow the dynamic integration of external services into custom processes. This way, corporations no longer depend on predefined schemes, but are able to reuse their own infrastructure to build highly specialized business processes that suit their needs.^[3]

Another important factor in any business is the establishment of trust between business partners, as well as a trusted infrastructure. Marketplace participants must rely on the validity, confidentiality and integrity of their transactions. As a consequence, any reliable electronic marketplace system must provide means to establish and maintain a satisfactory level of information security.^[4]

Especially in the case where arbitrary process composition is allowed, adequate security is hard to achieve, because the marketplace system cannot control the degree of security in external services. A typically employed non-technical solution is contracting security levels and consolidating potential losses via contract penalties. Though this procedure can hugely increase the amount of trust, it cannot substitute technical remedies that aim at avoiding losses in the first place.

The goal of this research project is the analysis of a Web Services-oriented marketplace in terms of information systems security as defined in the next section. In particular, privacy and reliability issues are not considered part of information systems security.^[5] The Web Services-based framework “soma”^[6] (service-oriented marketplace) is used as reference. This document tries to increase the trustworthiness of soma by turning attention to issues inhibiting trust and suggesting remedies whenever appropriate.

Until lately, Web Services projects concentrated primarily on functionality. Since real- world applications are coming up, the question of security comes more and more into fo- cus. Unfortunately, security was omitted when the fundamental Web Services standards^[7] SOAP, WSDL and UDDI (Universal Description, Discovery, and Integration) were devel- oped. Only recently, efforts by various organizations and corporations have led to quite a number of promising new security standards for Web Services as well as enhancements to existing standards.

Interestingly, Web Service security is not a hot topic in the security community. An explanation for this discrepancy between Web Services functionality and security could be the widespread use of existing security investments and thus slow adoption of more sophisticated Web Services security technologies. Web Services technology is still in the fledgling stages where security often plays a minor role—and is often overlooked even when it becomes vitally important.

A survey^[8] consucted by Evans Data Corporation among 400 enterprise development man- agers showed, that the main obstacle to implementing Web Services is lacking security support. Detailed results can be taken from Figure 1.

illustration not visible in this excerpt

Figure 1: Biggest Obstacle to Implementing Web Services

Definitions

- Web Service

“A Web Service is a software system designed to support interoperable machine-to- machine interaction over a network. It has an interface described in a machine- processable format (specifically WSDL [Web Services Description Language]). Other systems interact with the Web Service in a manner prescribed by its descrip- tion using SOAP messages, typically conveyed using HTTP [Hypertext Transfer Protocol] with an XML [Extensible Markup Language] serialization in conjunction with other Web-related standards.”^[9]

- Service-oriented Architecture

“[Service-oriented Architecture] is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their own- ers.”^[10]

- Information Systems Security

“Protection of information systems against unauthorized access to or modification of information, whether in storage, processing or transit, and against the denial of service to authorized users, including those measures necessary to detect, docu- ment, and counter such threats.”^[11]

1 soma : A Service-oriented electronic Marketplace

1.1 Overview

soma is a prototype system realizing a service-oriented electronic marketplace.^[12] It serves as a platform for business to business electronic commerce. The innovative notion behind soma is to provide a basic set of services that is constituent for an electronic market- place and subsequently let users build their own complex business processes. soma is therefore equipped with a powerful and easy to use process definition mechanism that al- lows users to design business processes relying on soma ’s basic services and—even more important—arbitrary third party services including users’ own services.

The main motive for the development of soma was the insight that contemporary elec- tronic marketplaces are not flexible enough to allow for a convincing substitution of many traditional markets. Electronic marketplaces should strive to give trading partners an amount of flexibility that comes as close as possible to negotiations in the real world. Another important ambition was facile integration into a corporation’s existing business processes, thus reducing expenses and increasing the overall acceptance of the system. Finally, soma aims at achieving a high degree of trust by dint of information systems security.

Two aspects are especially important to increase flexibility: service-orientation and cus- tom business process definition. Service-orientation implies that the system is divided into encapsulated components exposing only their interfaces. These services can eas- ily be reused in different marketplace settings. In addition, these services facilitate the integration of soma into corporations’ information technology landscape.

The second aspect regards individual user-side business process definition and dynamic execution. Users are provided a means for composing business processes in an XML- based language called Business Process Execution Language (BPEL). These processes can then be used as a pattern for negotiations. In doing so, the process composer can 12 For the following, see Rolli et al., 2004.

choose the negotiation scheme that promises to be most advantageous to him. Thus, the user no longer depends on the mechanisms provided by electronic marketplaces. In addition, soma brings along some predefined processes users may customize according to their needs.

Increasing flexibility goes hand in hand with decreasing effort and cost of integration. With the help of soma, business processes can be adapted to corporations’ present IT infrastructures instead of laboriously adjusting well-tried systems to an proprietary elec- tronic marketplace. Corporations are thus enabled to transparently integrate soma into their own business processes.

The mentioned flexibility issues are already covered in-depth.^[13] The question of trustwor- thiness is examined in detail in the sections following this introduction to soma.

1.2 Technology

1.2.1 Architecture Web Service-orientation

soma is a Web Services-based system. As such, it incorporates the standard Web Ser- vices Architecture^[14]. A simplified general model is depicted in Figure 2. On an abstract layer, the three roles described on the next page can be identified. Each Web Service can incorporate one or more roles depending on its current task.^[15]

illustration not visible in this excerpt

Figure 2: Web Service-oriented Architecture

- Service Provider

A Web Service acting as a service provider implements some business logic and allows other Web Services to access it. Apart from actually providing his function- ality, the main objective of a service provider is to register or publish itself with the help of a service broker.

- Service Consumer

A Web Service requesting another service to perform some specified action is called service consumer (sometimes also called service requestor). The service consumer obtains the location of the service provider by looking it up via the service bro- ker. Equipped with this information, it can directly invoke the service provider’s functionality.

- Service Broker

The main task of the service broker is to store information about registered service providers and let service consumers search for them. The service broker is typ- ically implemented as a UDDI^[16] registry or ebXML (Electronic Business XML) repository.

In the context of this plain model, everything is considered a service. This is obviously the case with Web Services, but holds true even for human beings accessing other services by e-mail or web frontend.

Layer Model

Apart from the service-oriented architecture, soma uses a layer model to reduce redun- dancy and complexity (See Figure 3). On the lowest layer, a set of fundamental services with commonly required functions provides a basis for services on the layer above. The services on this third layer are specific for each market service on the second layer. Top- layer market processes are in turn composed of market services.^[17]

The highlighted security services belong to the basic layer as they are a necessary part of the soma system. Nevertheless, satisfying information security cannot be achieved by just placing static security services in a system. In fact, it is moreover indispensable to

illustration not visible in this excerpt

Figure 3: Layer Architecture of soma

consider possible security threats at every layer to avoid overlooking security holes. This insight is addressed in detail in Section 3. In addition, security policies can be enforced most effectively on the highest layer, where information from lower layers can be taken into account.

1.2.2 Implementation

Core concepts of the implementation are Web Services component design, dynamic busi- ness process definition and execution with BPEL as well as high performance and scal- ability with the aid of the modern middleware technology J2EE (Java 2 Enterprise Edition).^[18] As for information security, traditional approaches and sophisticated Web Ser- vices security solutions work hand in hand to form a trustworthy infrastructure.

soma enhances the general Web Service Architecture by adding the functionality of pro- cess definition and a dynamic process execution engine. A registry is used to handle information about the services provided by soma.

The basic services that build the backend of the framework are implemented as Java ses- sion beans. For performance reasons, persistent data is stored in a MySQL relational database instead of using built-in container-managed persistence of entity beans. The framework’s small set of necessary services can be complemented by arbitrary third party Web Services, be they simple components or composed processes specified in BPEL. These services can be integrated by customization of existing processes or by composi- tion from scratch.

soma provides a human-machine interface via a publicly accessible web frontend im- plemented as Java Server Pages (JSP) which run on a JBoss application server. As an example, the login screen used in soma is depicted in Figure 4. Users can access soma through this frontend to execute administrative tasks or take part in processes if manual proceeding is required. The frontend also provides the facility for process design.

illustration not visible in this excerpt

Figure 4: Frontend of soma

2 Web Services and Security

2.1 Security Implications of Web Services

2.1.1 Web Services Basics

Two main technical factors limit the evolution of software systems: Complexity and in- compatibility. During the software development process, the developer translates a prob- lem of the real world into a formal model that can be processed by computers. Due to reutilization and customization of existing solutions and fast growing performance of computer systems, these models are constantly getting more complex. Human capabil- ities in contrary stay limited. The typical step taken against this growing complexity is the encapsulation of functionality in components, which hide their actual implementation (often referred to as “black boxes”) and expose a fixed interface to outside components. This way, a component needs to know only the interface of another component, but no details about its inner life.^[19]

Incompatibility issues are even harder to deal with, because typically each organization chooses the infrastructure that optimally suits its needs. In such decisions, compatibility is only one aspect of many that have to be taken into account and often plays a minor role. Especially among business units using heterogeneous hardware or software platforms, it is essential to enable interoperation. An early solution to this was the Common Object Request Broker Architecture (CORBA) developed by the Object Management Group.^[20]

As an answer to both growing complexity and incompatibility, Web Services have been a promising alternative for some years now. Web Services are a new approach in enterprise application integration (EAI) as well as a software design and engineering paradigm. Web Services unify well-tried features and auspicious properties such as loose coupling of components, platform independence, standardized and open communication protocols, easy integration into existing technologies and widespread acceptance.^[21]

2.1.2 Opportunities and Risks of Web Services

A common method of building Web Service applications is to wrap existing proprietary software components so that they expose standardized interfaces (i.e., they understand SOAP). This way, compatibility problems can be solved: business partners or even dif- ferent divisions within a single corporation are now able to interact because they share a common protocol layer above their incompatible infrastructure. This approach has both positive and negative consequences: On the one hand, well-tried and expensive informa- tion systems can further be operated, thus avoiding high acquisition costs for a completely new system. On the other hand, it makes the affected software systems easier to access— and consequently, attack—from both the inside and the outside. The majority of Web Services in use today is built as wrappers without dealing with emerging security threats: The ensuing risks were often overlooked or even ignored. This is the main reason why Web Services security has not gained a significant role in Web Services systems today.^[22]

The Web Services technology stack is shown in Figure 5. The approach of “defense in depth” demands security means on every layer to avoid leaving a weak spot unpro- tected.^[23] On the HTTP layer, TLS (Transport Layer Security) or an equivalent should be used whenever appropriate to establish strong point-to-point encryption. On the XML layer, XML Digital Signature and XML Encryption should be used to sign and encrypt portions of messages using strong encryption algorithms such as AES (Advanced En- cryption Standard). On the SOAP layer, WS-Security (Web Services Security Language) should be used to integrate all used security technologies while SAML (Security Asser- tion Markup Language) can append security tokens to messages.

Though the impact of Web Services may be revolutionary, the underlying technology is not. Web Services are a combination of popular technologies rather than a technical rev- olution. The concepts Web Services technology relies on have been around for over a decade.^[24] All that is new to Web Services is the widespread adoption of its standards, namely SOAP, WSDL and UDDI. As stated above, the integration of incompatible sys- tems through loosely coupled components and standardized interfaces was already ac- complished by CORBA since the early 1990s. The consequences for security of Web

illustration not visible in this excerpt

Figure 5: Web Services Technology Stack

Services are that solutions for many problems have already been discussed and even re- alized in some cases. Nevertheless, Web Services pose a series of special security issues that need special handling and new solutions.^[25]

The traditional approach of developing isolated software systems and proprietary integra- tion solutions between them is not only an interoperability problem, but also prevents a holistic perspective on the system’s security. Web Services technology gives the oppor- tunity to build an integrated security system based on a dynamically distributed system wide security policy.^[26]

The level of security applied to a system is almost always a trade-off between time, money, and convenience on the one side, and availability, integrity, and confidentiality on the other side. The decision which security issues should actually be solved depends on many non-technical questions. The optimal security level in general lies somewhere between no security at all and no functionality at all (i.e., maximum security). It is obvious that the latter solution is undesirable in almost any case. The former can be sensible and is often found in early stages of software development projects. Nevertheless, most software systems need security in one form or another. Adding security at a later development stage could cause unnecessary costs that could have been avoided if security would have been taken seriously from the start.^[27]

2.2 Infrastructure Standards in a Nutshell

2.2.1 SOAP

As far as Web Services are concerned, the base protocol for communication between service consumers and service providers is the XML-based message exchange protocol SOAP (see Code Sample 1).^[28] It defines an ENVELOPE element that wraps around all contents of the message (line 1).

illustration not visible in this excerpt

Code Sample 1: SOAP Message

The ENVELOPE contains an optional HEADER (line 2) and a mandatory BODY (line 5). The payload is embedded inside the BODY, while the HEADER is the root element for meta data characterizing the message and its content. Such meta data may include routing or timing information as well as security statements.

2.2.2 WSDL

The language commonly used for describing a Web Service’s interface is the Web Ser- vice Description Language (WSDL) developed by the W3C. With the aid of WSDL can be defined what methods a Web Service provides and which parameters these methods accept. Each Web Service is associated with a WSDL file that is typically published in a repository. Service consumers may retrieve this file and invoke the service provider using the WSDL information.^[29]

2.2.3 UDDI

The most popular^[30] repository for Web Services is Universal Description, Discovery and Integration (UDDI). UDDI is not a XML-language like SOAP and WSDL, but a spe- cialized database containing descriptions of service providers, Web Services and how to access them. The UDDI specification defines a so-called UDDI Registry, which provides a set of data structures to store this information (Table 1 gives a short overview). Ser- vice consumers can search a UDDI Registry by a Web Service’s interface definition, its classification or simply by keywords.^[31]

Table 1: UDDI Data Structures

illustration not visible in this excerpt

2.2.4 BPEL

BPEL is a relatively new XML standard developed by an IT industry consortium. Its goal is to provide a means to describe Web Services-based business processes in a formal way. A BPEL engine parses the process definition and executes the process flow. The main tasks are invocation of Web Services, data conversion and storage, and exception handling (e.g., if an invoked Web Service cannot handle a SOAP message).^[32]

The structure of BPEL resembles a programming language: In a first section, so-called PARTNERLINKS describe the interfaces of Web Services that are invoked during process- ing (like method signatures in programming languages). All variables needed for tempo- rary data storage must be declared in the VARIABLES section. FAULTHANDLERS may be used to handle exceptions during process execution.

[...]

---

^[1] See Kauffman and Mohtadi, 2004.

^[2] For a list of electronic marketplaces on the Internet, see http://www.berlecon.de/output/b2bdb/ en/.

^[3] See Patankar and Segev, 2003.

^[4] See Hartman et al., 2003, c. 1.

^[5] For privacy issues in Web Services-based electronic marketplaces, see Christoffel and Killat, 2004.

^[6] See Rolli et al., 2004.

^[7] To increase interoperability, the WS-Integration Organization specifies which standards should work with each other. See WS-I, 2004.

^[8] See Evans Data Corporation, 2002.

^[9] W3C, 2004a, p. 7.

^[10] He, 2003.

^[11] US Committee on National Security Systems, 2003, p. 33.

^[12] For the following, see Rolli et al., 2004.

^[13] See Rolli et al., 2004.

^[14] See W3C, 2004a.

^[15] See Open GIS Consortium, 2001, p. 43–44.

^[16] See Section 2.2.3.

^[17] For a detailed description see Rolli et al., 2004.

^[18] See Rolli et al., 2004.

^[19] See Milewski, 2001.

^[20] See http://www.omg.org.

^[21] See W3C, 2004a.

^[22] See Aoyama et al., 2002.

^[23] See McGuiness, 2001.

^[24] See Kossmann and Leymann, 2004.

^[25] See Hondo, Nagaratnam, and Nadalin, 2002.

^[26] See Chang, Chen, and Hsu, 2003.

^[27] See McGraw, 1999.

^[28] For the following, see W3C, 2003.

^[29] See W3C, 2004b.

^[30] For a list of public UDDI Registries, see http://www.uddi.org/find.html.

^[31] See OASIS, 2003.

^[32] See Andrews et al., 2003.