Service-oriented architecture (SOA) is a paradigm for organizing and using distributed services that may be under the control of different ownership domains [32].
An SOA provides a uniform means of offering, discovering, and interacting with and using services to produce desired effects consistent with measurable preconditions and expectations. Being service oriented requires services to be only loosely coupled to operating systems and other technologies that underlie applications. An SOA separates functions into distinct units, or services [33], which developers make accessible over a network so that users can combine and reuse them when developing applications.
These services communicate with each other by exchanging data or by coordinating an activity between multiple services. An SOA can be implemented by a software system such as Web services [34], which make functional building blocks accessible over standard Internet protocols independently of platforms and programming languages.
These services can be new applications or wrapped around existing legacy systems to make them network-enabled.
The most common security scheme available for today’s Web services is SSL (Secure Sockets Layer) [35], which is typically used with HTTP. Despite its popularity, SSL has some limitations related to Web services. Achieving Web services security requirements of authentication, confidentiality, data integrity, and nonrepudiation requires numerous security standards, such as WS-Security, WS-SecurityPolicy, and WS-Trust. The WS-Security standard was designed to use the XML Encryption and XML Signature specifications for message-level confidentiality and integrity. By signing and encrypting at the message level, senders can control whether
intermediaries are allowed to modify or view the content in transit. Additionally, the entire message can be stored intact, which maintains integrity and confidentiality.
Because message integrity is provided by digital signatures, nonrepudiation can be achieved by logging individual messages for later retrieval [36]. WS-SecurityPolicy defines a set of security policy assertions used in the context of the WS-Policy framework that describe how messages are secured on a communication path [37].
WS-Trust defines extensions that build on WS-Security to provide a framework for requesting and issuing security tokens, and to broker trust relationships [38]. However, in general these existing Web-service security models only consider the access control and data security of individual services, and can only be applied to fulfill the security requirements of a point-to-point service invocation. These works have helped to build the foundation for Web-service security, but are inadequate for applications in which the service invocations form a calling chain.
Each building block in a Web-services-based system can play one or both of two roles: (1) the service provider creates a Web service and possibly publishes its interface and access information to the service registry, and (2) the service consumer (or Web-service client) locates entries in the broker registry using various discovery operations and then binds to the service provider in order to invoke1 one of its Web services. The service provider and service consumer perform the invocation and response in a point-to-point manner.
The invocation of a Web service can be either synchronous or asynchronous. In a synchronous invocation of a Web service, the client connection remains open from the
1 In this dissertation we use the two terms “call” and “invoke” interchangeably.
time the invocation is submitted to the service provider. The client will wait until the service provider sends back the response message. The advantage of using synchronous communication is that the client application is rapidly informed of the status of the Web-service operation (either it receives a response or it times out). An asynchronous invocation is made to a service while the client continues execution, until either the specified callback is made or, if the callback is not provided, until blocking or polling occur or waiting for the call to complete. The Web service can handle an asynchronous call competently without requiring any additional functionality. The client decides whether to call synchronously or asynchronously.
Many methods are available for performing asynchronous calls, with the most common being to use a call-back handler.
A calling chain occurs in ordinary programming language when a called subroutine calls another subroutine before it is finished [39]; this is also referred to as nested subroutine calls, and can exist in distributed computation models such as RPC [40], RMI [41], and Web services. This dissertation employs Web services to demonstrate the proposed security framework that we believe can be applied to any SOA framework. Karp presented an example of why information about calling chains is required for access control in an SOA environment [42]. Figure 3 shows an SOA application with three domains that are provided by different service providers.
Domain 1 provides weather prediction services, services in Domain 2 access satellite images, and services in Domain 3 return topographic data. An arrow represents a service invocation, such as Alice first calling A6 for starting this calling chain, and then A6 calls B5, B5 calls both A3 and B2, etc. In this scenario Alice is considered to
be the originator of the invocation. If Alice has the authority to use service D5, when she is the originator she can use the service. However, if the originator is Bob who does not have the authority, he cannot use the service. Although we can employ security standards such as WS-Security, WS-SecurityPolicy, and WS-Trust to support the point-to-point security requirements, there is no way to capture the ID of the originator due to the lack of calling-chain information—this access control requirement will not be accomplished. In this scenario it seems that authentication of the originator of a calling chain is required for the access control. Below we present a more complicated example in which nonrepudiation is required when a calling chain
Figure 3. An example SOA application from the literature.
Alice (Originator)
Digital-photo printing
service
Payment service
Photo retouching
service Printing service
Shipping service
Figure 4. An SOA application.
Figure 4 shows an SOA application that provides a digital-photo printing service.
When this service receives an order, it will invoke the “payment service” with the credit card information in the order. Then, according to the requirements of this order, it will send the photos that need retouching to the “photo retouching service.” Finally the “digital-photo printing service” sends the photos after retouching and also the photos that do not require retouching to the “printing service” for printing and ships them with the partnered “shipping service.” In this scenario, the order message that Alice (the originator) sends to the “digital-photo printing service” has to contain all of the information needed by this service, including the relevant photo images, the sizes and how many copies are needed for each of them, which photos require retouching for improving their image quality, the credit card information for the payment, and the address and contact information of the receiver for shipping. The services involved in
this scenario need to specify the policies according to certain information in a dynamically formed calling chain. First, the “payment service” needs to ensure nonrepudiation for the service invocation of the originator, and that the credit card information can only be read by the payment service. Second, the “photo retouching service” needs to confirm that the originator has been registered. Third, the “photo retouching service,” “printing service,” and “shipping service” must ensure that the
“payment service” has been successfully invoked. It is obvious that existing standards such as WS-Security, WS-SecurityPolicy, and WS-Trust are insufficient for implementing the security requirements described in this scenario because the definable security policies cannot refer to the context of the formed calling chain. In this situation, the system developer may have to employ an entity such as a trusted third party to facilitate interactions between service providers and a third-party repository service, which appears to make it necessary to record service invocations.