Security Challenges in Utilizing Web Services

Get Complete Project Material File(s) Now! »

Service-Oriented Architectures

The concept of Service-Oriented Architecture (SOA) has existed for many years. As such, it has a low sensitive dependence on the original state, having evolved with time primarily in relation to the technologies used to implement it. The concept of SOA, in terms of its objectives and fundamental mechanism of operation, will first be examined. Existing SOA technologies will then be briefly explored to identify pros and cons which have necessitated the evolution of SOA. These technologies include Remote Method Invocation (RMI), Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA). All of these provide remote services by way of a stub/skeleton-based architecture. Web Services – as the successor to these technologies – will subsequently be examined to ascertain why it has become the SOA A FRAMEWORK FOR PROMOTING INTEROPERABILITY IN A GLOBAL ELECTRONIC MARKET-SPACE 42 technology of choice. The current related standards for Web services will also be described

Stub/Skeleton-Based Architectures

The stub/skeleton architecture is intended to allow access to a remote service as if it were a local one. Two modules are needed to build a stub/skeleton architecture: a stub on the client side and a skeleton on the server side. The skeleton exposes the available methods or services, via the stub, to the client. The stub “is aware” of the services available on the server and acts as a translator between the client and the skeleton. The skeleton marshals communication between the stub and the server (Potts and Kopack, 2003). The interface communication layer is provided transparently by the corresponding SOA infrastructure. This process is illustrated in Figure 3.2.

DCOM

DCOM differs from RMI in that the end-points need not be written in a specific language. It is, however, considered a Microsoft-dependant mechanism (Potts and Kopack, 2003). DCOM also performs remote calls. It is based on COM (Component Object Model) which defines how clients communicate with application components. With COM, a COM-interface receives a call or request from a client application, which it forwards to the component. DCOM simply extends the wire protocol that connects the client and component and replaces the local inter-process communication with a network protocol (Microsoft Corporation, 1996). The difference can be seen in Figure 3.5.

XML

At this point it can be pre-emptively declared that XML is favoured as a base technology in the B2B-collaboration context; this is common knowledge. It is the foundation upon which Web services have come into being. Its suitability in a GEMcontext will be explored in this section. XML is a markup language designed to define the structure of data. It uses a set of tags to describe elements of data, which can be either simple or complex types. An unlimited set of these tags can be defined by the author of an XML-document to describe data and data structures. XML is a widely-adopted standard due to its simplicity and platform-independence. It separates style and content, thus enabling data to be integrated from various sources.

READ Centrality-Based Eventual Leader Election in Dynamic Networks

The significance of Web Services to a GEM

A Web service, in simple terms, is an application providing a service (Wall and Lader, 2002: 220-221), for example, a calculator application that calculates mortgage bond repayments, accessible via standard Web protocols. It, therefore, resides on a Web Server (such as Internet Information Server or Apache), which might be on an intranet, an extranet or the Internet. In its simplest form, a Web service may be accessed from any platform-type as follows: The uniform resource identifier (URI) of the Web service is entered on a Web browser.

Web Services infrastructure

The W3C’s Web Service Architecture Group defines a Web service (more comprehensively) as follows: “A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described and discovered by XML objects and supports direct collaborations with other software applications using XML-based messages via Internet-based protocols” (Jenz, 2002). This extends the simplistic definition provided in the earlier section somewhat; a Web service represents more than just an application interface. It represents the most interoperable SOA to date.

TABLE OF CONTENTS :

SUMMARY
ABBREVIATIONS AND ACRONYMS USED
Chapter 1 The Nature and Context of the Problem
- Introduction
- The Nature of the Problem
- The Context of the Problem
- A Simple Analogy
- A More-Formal Information Systems Perspective
- Initial Contentions Raised in the GEM-Context
- The Problem Statement
- Methodology
- Brief Chapter-Analysis
Chapter 2 GEM: The Nature of the Beast
- Introduction
- B2B-Collaboration Defined
- Key Concepts in B2B-Collaboration: Integration and Interoperability
- An Analysis of Inter-Business Collaboration
- How real is the incentive for a global market-space?
- The Multiplicity Paradox
- Conclusion
Chapter 3 Arriving at a Standardized GEM Interface
- Introduction
- Service-Oriented Architectures
- The Essence of SOA
- Short-Comings in Existing SOA-Technologies
- Stub/Skeleton-Based Architectures
- Security Challenges in Utilizing Web Services
- Web Service Countermeasure Standards and Technologies
- Security Assertion Markup Language (SAML)
- Extensible Access Control Markup Language (XACML)
- XML Key Management Specification (XKMS)
- XML-Encryption
- XML-Digital Signatures
- Transport Layer Security (TLS)/ Secure Sockets Layer (SSL)
- Secure IP (IPSec)
- The WS-Security Framework
  - (a) WS-Policy
  - (b) WS-Trust
  - (c) WS-Privacy
  - (d) WS-SecureConversation
  - (e) WS-Federation
  - (f) WS-Authorization
  - (g) Supplementary specifications for inclusion in SOAP-headers
- WS-Security – extended considerations
- Conclusion
Chapter 4 An Analysis of Existing Business-to-Business-Collaboration models
- Introduction
- ebXML
- ebXML Technical Architecture
- Product Architecture Overview
- Process Architecture Overview
- An Appraisal of ebXML vis-à-vis the GEM
  - The Common Business Process aspect
  - The Common Semantics, Common Vocabulary and Common Expression Aspects
  - The Common Character Encoding Aspect
  - The Common Data Transfer Protocol Aspect
  - The Common Network Layer Aspect
  - The Common Security Implementations Aspect
- ebXML: Concluding Remarks
- Other Current B2B Models
Chapter 5 A Proposed Framework for a GEM