Secure Provision of Composite Services in an Insecure Networked Environment

Transcription

1 Secure Provision of Composite Services in an Insecure Networked Environment Vo Dinh Hieu MSc Distributed Multimedia Systems 2004/2005 The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student)

2 Summary As an implementation of Service-Oriented Architecture, Web services support service developers to compose existing services to build new services. On one hand, service composition offers service developers many benefits such as the reuse of services and reduction in the complexity of systems. On the other hand, service composition opens several challenges. One of these challenges is security. The aim of this project is to provide security for composite service. The project identifies main security issues relating to service composition and proposes an architecture which is used to provide security for composite service. The proposed architecture focuses on addressing the security problems arising from the heterogeneity of security policies of composed services. A case study is established to evaluate designed architecture. I

3 Acknowledgements I finished this project with a lot of help from Professor Jie Xu, my supervisor. I sincerely thank Professor for his guidance. I would like to thank Mr WS Whyte for his ideas in the interim report and in the progress meeting. I would like to thank Mr Nam Lam and Mr Dacheng Zhang for their help with my project. I would like to take this opportunity to thank Mr Tran Vu Pham and his wife for many help. They have helped me a lot with my study and my life in Leeds. I would like to thank Miss Dang Huong for her encouragement. Finally, I would like to thank all the members of my family for their love. II

4 Contents Chapter 1 Introduction Project Overview Project Management Minimum Requirements Research Method Project Plan Outline of the Report... 4 Chapter 2 Web Services and Web Services Security Service-Oriented Architecture Web Services Web Services Architecture SOAP, WSDL and UDDI Web Services Security Techniques Supporting Web Security XML Security WS-Security...15 Chapter 3 Security Issues of Service Composition Service Composition Security Issues Chapter 4 A Proposed Architecture The Security Engine: A Security Solution for Composite Service III

5 4.2 System Design Chapter 5 A Case Study A Scenario: A Composite Service for Computer Retailer Design of Composite Service Implementation Chapter 6 Evaluation of the Security Engine...35 Chapter 7 Evaluation of the Project...39 Chapter 8 Conclusion...42 Appendix A: Personal Reflection Appendix B: Aim and Requirements 47 Appendix C: Marking Scheme.. 49 Appendix E: Source Code of the Project.. 52 Appendix F: Install. 53 Appendix G: Computer Service s BPEL File IV

6 Figures Figure 2-1: Service-Oriented Architecture...6 Figure 2-2: Internal Architecture of Web services...8 Figure 2-3: External Architecture of Web services[3]...9 Figure 2-4: XKMS Service...15 Figure 3-1: Composite service and composed services...16 Figure 3-2: Communication path between composite service and a composed service...17 Figure 3-3: Intermediary Service...21 Figure 3-4: Composed services belong to different adminstrative domains...22 Figure 4-1: Interaction between a composite service and a composed service...25 Figure 4-2: Architecture of Security Engine...26 Figure 4-3: Process a received message...27 Figure 4-4: Process a sent message...28 Figure 5-1: E-business system of Computer Retailer...29 Figure 5-2: The logical view of Computer Service system...30 Figure 5-3: Sequence of messages in the system...31 Figure 5-4: The demonstration webpage of Computer Service...34 Figure 6-1: Processing time of the Security Engine...36 V

7 Chapter 1 Introduction This chapter presents a view about non-technical aspects of the project. The first part of this chapter is an overview of the project. In second part, facets of project management are given. These include minimum requirements stated at the beginning of the project, research method and plan for achieving those requirements. The last part of this chapter is about the structure of this report. 1.1 Project Overview In the Internet age, most companies consider this global network as a part of their businesses. The Internet has been exploited to promote many business activities of a company which include enterprise resource planning, human resources, customer relationship management, supply chain management and so on. In many cases, these enterprise applications need integrating to automating and optimising business activities of companies. The integrations may take place not only within a company but also between companies. Web services have emerged as an ideal solution for enterprise application integration. As an implementation of Service-Oriented Architecture, Wed services have ability to combine existing services to built new services. This combination process is call service composition. Service composition offers system developers many benefits such as easier to provide value-added services and reducing the complexity of systems which are built from a set of services. However, many challenges need overcoming to exploit benefits provided by service composition. Security is one of these challenges. The security issues of service composition arise from the fact that service interactions may take place between services belonging to different providers. This project focuses on addressing security problems of service composition. The main tasks of the project are to use Web service technologies, such as XML, SOAP, WSDL and UDDI to simulate Web services composition and design a scheme for the composite service to effectively detect tampered data and results from the composed services so as to provide a more secure service to the client. 1.2 Project Management Minimum Requirements Following are minimum requirements that were agreed upon at the beginning of the project. Understand the Service-Oriented Architecture (SOA), Web Service Architecture (WSA) and the use of Web services in overcoming problems which happened in Business-to-Customer (B2C) and Business-to-Business (B2B) applications. Secure Provision of Composite Services in an Insecure Networked Environment 1

8 Understand Web service standards such as WS-Addressing, WS-Routing, WS-Security, WS-Policy, WS-Coordination and how to apply these standards. Understand XML, XML security (XML Signature, XML Encryption, SAML, XACML, XKMS) and the use of XML security in developing secure Web services and secure composite Web services. Ability to develop and deploy Web services (mainly on Linux platform) Clearly understand Web and Web services security problems. Identify security issues of Web services compositing. Review current solutions addressing security issues of composite web services. Design a prototype for developing composite Web services which focus on addressing security issues. Implement an application example for the demonstration of secure service provision. The project can be enhanced by providing intrusion detection system or design a prototype for secure automatic composing Research Method In the first stage of the project, all security issues of service composition are identified. There are many issues relating to service composition, however, the project only focuses on the security of data sent and received between services. In the next stage, the project reviews existing solutions that address identified security problems. Base on this information, a scheme for providing security for service composition is designed. This design then will be implemented and applied for an example application. Attacks will be simulated to collect data for evaluate the designed scheme Project Plan Initial Plan The table below shows the initial plan of the project. This plan is revised several times during the project. ID Task Name Duration Start Date Finish Date 1 Background reading 1 (SOA, WS, WS-*) 15 days Mon 07/03/05 Fri 25/03/05 2 Creating and Deploying web services 15 days Mon 07/03/05 Fri 25/03/05 3 Background reading 2 (WS composition) 5 days Mon 04/04/05 Fri 08/04/05 4 Creating composite web service (Deploy a composite service) 5 days Mon 04/04/05 Fri 08/04/05 Secure Provision of Composite Services in an Insecure Networked Environment 2

9 5 Background reading 3 (Security) 5 days Mon 11/04/05 Fri 15/04/05 6 Implement security features for above composite service 5 days Mon 11/04/05 Fri 15/04/05 7 Synthesis, evaluate existing solutions 5 days Mon 18/04/05 Fri 22/04/05 8 Mid report draft 35 days Mon 07/03/05 Fri 22/04/05 9 Synthesis, evaluate existing solutions 10 days Mon 02/05/05 Fri 13/05/05 10 Design prototype 55 days Mon 23/05/05 Fri 05/08/05 11 Implement prototype 55 days Mon 23/05/05 Fri 05/08/05 12 Testing 55 days Mon 23/05/05 Fri 05/08/05 13 Report draft 10 days Mon 08/08/05 Fri 19/08/05 14 Finalize report and prototype 5 days Mon 22/08/05 Fri 26/08/05 15 Submit 1 day Mon 29/08/05 Mon 29/08/05 Table 1-1: Initial plan of the project Revised Plan During the project, the plan was revised several times. The first revision took place after finishing background reading. More time is needed for understanding service composition. The reason is service composition relates to many other aspects of distributed systems such as workflow and coordination so these aspects also need examining. Besides that, there are several composition approaches. The plan was revised second time after a specific composition language (BPEL) was chose. Also at that time the lacking of supporting WS-Security of Apache Axis was aware. The revised plan was as following (the first part of the plan is omitted because it is the same as the initial plan) From 1/6 to 15/6: Choosing composition approach. Objective: Choose the composite approach and corresponding composition language from many composition approaches. From 15/6 to 1/7: Understanding related topics and establish scenario for service composition Objectives: To understand other topics in distributed computing that relates to service composition. These topics include workflow, coordination management, and transaction management. At this time, the scenario in which service composition is used also be established. This scenario will be used to Secure Provision of Composite Services in an Insecure Networked Environment 3

10 develop a demonstration for service composition in the project. The composite service and composed services are designed at this time. From 1/7 to 15/7: Security issues of service composition Objectives: Analyse and understand security issues of service composition. Current solutions for Web services security and service composition are examined. From 15/7 to 1/8: Design the prototype Objectives: Design a prototype for provision secure composite service From 1/8 to 25/8: Coding and Evaluating Objectives: Implement the composite service and composed services. Implement the security prototype. Test the system for evaluation. From 15/8 to 31/8: Writing report Objectives: Writing project report. From 1/9 to 5/9: Finalize Objectives: Reviewed code and report. Prepare for submitting. 1.3 Outline of the Report The first chapter of the report (this chapter) is the introduction to the project. As may be seen, this chapter gives readers the overview of the project, minimum requirements, and the plans of the project. The next chapter, Chapter 2, provides background knowledge about Web services and Web services security. Information in this chapter sets up a security context in Web service environment for further discussion in the following chapters. In the first part of Chapter 3, fundamental of service composition including definition of service composition and composition approaches is described. The main part of this chapter is the analysis of security issues in service composition. The aim of the Chapter 3 is identifying the security challenges of provision composite services. Based on analysis in Chapter 3, Chapter 4 presents a proposed architecture to address security issues of composite service. Chapter 5 describes a case study in which the proposed architecture is implemented and applied. Secure Provision of Composite Services in an Insecure Networked Environment 4

11 Chapter 6 is the evaluation of the proposed architecture. This evaluation is based on the implementation in the case study described in Chapter 5. Overall of the project is evaluated in Chapter 7. This evaluation is based on minimum requirements stated at the beginning of the project. Chapter 8 is the conclusion and a brief discussion about future directions. Secure Provision of Composite Services in an Insecure Networked Environment 5

12 Chapter 2 Web Services and Web Services Security This chapter, as a part of background research, provides an overview of Web services technologies. Service- Oriented Architecture is presented first to explain the need Web of services technologies then Web services architecture, SOAP, WSDL, UDDI, and emerging Web services standards are reviewed. The last part of this chapter is about Web services security. 2.1 Service-Oriented Architecture Service-Oriented Architecture (SOA) [1][2][3] is a form of distributed system architecture. This architecture defines a loosely relationships between components of a system. Three components in SOA are Service Provider, Service Requester, and Service Broker [1] (Figure 2-1: Service-Oriented Architecture). Figure 2-1: Service-Oriented Architecture Service Requester is an application, a service or some kind of software that uses services. Service Provider is the software receiving and processing requests from Service Requesters. Service Broker acts as a directory service where requesters can find information about published services. Three operations in SOA are publishing, finding, and binding. After implementing a service, Service Provider publishes the service to Service Broker (publishing). The requesters contact Service Broker to obtain information about available services (finding). Upon having information of a published service, the requester binds and uses the service (binding). Some more concepts in SOA are Service Contract, Service Proxy and Service Lease. Service Contract is the specification used by requesters and providers for communication. It specifies the format of request/reply messages. Service Proxy is a piece of software which helps requesters to communicate with providers. It is Secure Provision of Composite Services in an Insecure Networked Environment 6

13 Service Proxy to find the contract which then used by requesters to interact with providers. Service Lease specifies a mount of time that a contract is valid. SOA is typically characterised by following properties: Logical view: Everything is service. Message orientation: The services in SOA are defined in term of exchanging messages between Service Provider and Service Requester. Description orientation: Services are described by using machine-processable meta-data. Platform neutral: Messages are sent in a platform-neutral, standardized format delivered through interfaces. Services are discoverable and dynamically bound: That is a service can be discovered at run-time. Interoperability: That is the ability of systems to use different platforms and languages to communicate with each other. Interfaces of services play an important role in supporting this characteristic. Loose coupling: This characteristic is achieved by using contract and dynamic binding. The main goal is the changes in services will not effect the implementation of services customers. Location transparency: Location of a service is not known by requesters until they located it from the broker. This feature improves service availability and performance. Composability: The ability of combining services to make a service which has more features. Self-healing: That is the ability of recovering from errors of systems. These characteristics make SOA become a perfect architecture for distributed systems. SOA was introduced in DCOM [4], CORBA [5], and Jini [6]. However, using these technologies for implementation distributed systems has faced difficulties when integrating or implementing large-scale systems. Today, Web services is a set of technologies which ideally for implementing SOA. In the next section we will discuss main aspects of Web services. 2.2 Web Services Web services technologies is the solution for the problem of how to integrate applications which are developed on top of different middleware such as CORBA, Jini, MQ Series etc. These middleware are suitable for building enterprise applications managed by only one company. However, in the cases of integration of applications which are administrated by different companies these middleware have many limitations. The principal limitation is that each of these middleware is built with different technologies so they cannot communicate with Secure Provision of Composite Services in an Insecure Networked Environment 7

14 each other directly. By exploiting the advantages of Service-Oriented Architecture and providing standard protocols with the addition of the ability of wrapping conventional middleware Web services is the ideal solution for Business-to-Business integration. There are many definitions of Web services. In this report, the term Web service refers to the Web service in the definition of W3C: 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). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards [2] Web Services Architecture Web Services Architecture (WSA) [2] defines Web services, components in Web services environment and relations between them. When mentioning about Web services architecture two aspects should be considered. The fist aspect is the communication between Web services and the conventional middleware. That is the way Web services expose the business functionalities of underlying IT system. The second aspect is the interaction of different Web services. We have two architectures, internal architecture and external architecture, corresponding to two above aspects. Conventional Client Web services Client Service interface Web service interface Web services middleware (BEA WebLogic, IBM WebSphere, ) Conventional middleware (CORBA, Jini, MQ Series,... ) Figure 2-2: Internal Architecture of Web services The above diagram shows the internal architecture of Web services. In this architecture, Web services acts as the wrapper for the conventional middleware. All business functions are implemented by conventional middleware. Web services middleware exposes these functions to the outside world in a Web services standard manner. Note that conventional middleware can still provide direct service interface for traditional clients. Secure Provision of Composite Services in an Insecure Networked Environment 8

15 Figure 2-3: External Architecture of Web services [3] The external architecture of Web services is similar to Service-Oriented Architecture shown above. This architecture describes how Web services discover and interact with each other. The important feature of external architecture is that the interactions between Web services rely on SOAP, WSDL, and UDDI SOAP, WSDL and UDDI Web services technologies are based on three building blocks: SOAP, WSDL, and UDDI. SOAP is the protocol for services to exchange data whereas WSDL is the language for describing services and UDDI is the framework for discovering service. SOAP Simple Object Access Protocol (SOAP) [7] is a specification of W3C which main goal is to define the way how to organize data in XML structure for exchanging between services. Following are more detail about which are specified in SOAP: Message format for one-way communication A set of conventions for using SOAP messages to implement RPC. A set of rules for processing SOAP message A description of how a SOAP message should be transported by using HTTP and SMTP. SOAP can be seen as a communication protocol which has the unit of information is message. Each message has an envelope. Each envelope has a header part and a body part. While the body is mandatory, the header is optional of the envelope. The body is where the core information is conveyed. The information in the header is Secure Provision of Composite Services in an Insecure Networked Environment 9

16 for intermediate processing. The body part can contain one or many body blocks whereas the header may contain one or many header blocks. SOAP messages can be transported by any transport protocol. However, the most popular protocol used now is HTTP. When using HTTP for conveying SOAP, each SOAP message will be sent within a HTTP request. Both GET and POST methods can be used. WSDL Web Services Description Language (WSDL) [9] is a specification which specifies the way of using XML to describe interfaces of Web services. WSDL is used by Web services clients to determine how to invoked Web services. Information provided by a WSDL document includes the interface of that service, the location of the service and the transport protocols can be used to establish communication. A WSDL document may contains information about quality of service of a Web service. In general, WSDL has a role similar to that of IDLs of conventional middleware. However, WSDL is more complex than conventional IDLs. The first point which makes WSDL more complicated than IDL is that WSDL need to define the mechanism for clients to access services. In conventional middleware, IDLs need not to concern about this because middleware themselves have implicit context. A WSDL specification has two parts. The first part, called abstract part, is similar to conventional IDLs. This part contains port type definitions which in turn contain operations. Port type and operation are respectively similar to interface and method in traditional IDL. The second part is the concrete part which defines protocol binding (e.g. HTTP, SMTP, etc) which is used to communicate with service. UDDI Universal Description Discovery and Integration (UDDI) [8] is the specification of a framework for describing and discovering Web services. UDDI defines data structures and APIs for publishing and finding information about Web services. There are two main goals of UDDI. The first goal is to support developers to finding information about a particular Web services in order to develop Web services client. The second goal is to enable dynamic binding for client. In UDDI registry, a description of a service includes four types of information: businessentity: Describes an organization providing Web services. It contains company s name, contact information, and brief description of business. businessservice: Describes a group of related services provided by businessentity. A businessentity may have many businessservice elements but a businessservice belongs to only one businessentity. Secure Provision of Composite Services in an Insecure Networked Environment 10

17 bindingtemplate: Describe technical information which is used to communicate with a Web service. Address, tmodel, and operations parameters of a service also defined in this type of information. tmodel: (technical model), describes any kind of specification. As can be seen, tmodel is used by above elements. This is where important information of a service description is stored. Above sections give us an overview about main aspects of Web services. SOAP, WSDL, and UDDI seem enough for implementing three operations of SOA (i.e. publishing, finding, and binding). However, in reality more standards are needed for implementing complex systems. Examples of these standards are WS-Addressing, WS-Routing, WS-Transactions, WS-Coordination, and WS-Policy. These standards concern about different aspects of a distributed system such as addressing and routing SOAP messages, transaction management, and interoperating between services. Besides these aspects, security is always one of the biggest issues in Web services technologies. We will examine this topic in the following section. 2.3 Web Services Security As many other technologies relating to distributed systems, security is one of the most challenged issues of Web services. Web services technologies work on top of other technologies such as TCP/IP and HTTP so security issues of these underlying technologies also impact Web services. Followings are some specific challenges of Web services security: Clients and services can negotiate their mutual constrains and capabilities only when interacting. This means that they usually know nothing about each other before exchanging messages A message (SOAP) can be routed and processed through many intermediate services while some parts of the messages need keeping secret. Services are managed by different security policies so a robust trust management mechanism is needed. For the purpose of understanding Web services security issues, in this section we will review Web security issues. The reason for this is that in the present most Web services use HTTP for transporting SOAP messages. The first part is about techniques supporting solve the problems of Web security. This part is followed by a brief description about XML security, the main solution for Web services security. After all, WS-Security is mentioned. Secure Provision of Composite Services in an Insecure Networked Environment 11

18 2.3.1 Techniques Supporting Web Security Cryptography Cryptography is the basic method for information security. Cryptography mainly solves the problem of privacy and integrity of security. Cryptography includes two processes, encryption and decryption. Encryption is the process of transforming original data (usually called plaintext) in to meaningless data (called encrypted data or ciphertext) whereas the decryption is the reverse process. There are two kinds of cryptographies, symmetric cryptography and asymmetric cryptography. Symmetric cryptography, which is also called secret-key cryptography, uses the same key for encryption and decryption. With this type of cryptography sender and receiver must have a common key in order to exchange information. The problem of this cryptography is how to exchange keys between participants. Examples for this kind are Data Encryption Standard (DES) algorithm, 3DES algorithm and Advance Encryption Standard (AES) algorithm. Asymmetric cryptography, also known as public-key cryptography, uses two different keys for encryption and decryption. One of these key is called private key, the other is the public key. One can give his public key to anyone but he must keep his private key secretly. The sender uses the public key of receiver to encrypt data before sending. Upon receiving encrypted data, the receiver uses his private key to decrypt this data. The requirement of this kind of cryptography is that only private key can decrypt the data encrypted by corresponding public key and vice versa. The advantage of this kind of cryptography is the elimination of the issue of exchanging keys. However, this cryptography takes more time than symmetric cryptography for encrypting and decrypting. Examples for this cryptography are RSA and ECC. Digital Signature Digital signatures use public key cryptography to solve the problems of authentication, integrity, and nonrepudiation. A digital signature is generated by applying a hash function on data. The output of this process is a message digest. The sender signs the sent data by encrypting message digest with his private key. The output of signing process is the digital signature. This digital signature is sent along with data to receiver. On receiving data and signature, receiver decrypt signature with sender public key to get message digest. He also computes message digest by applying the same hash function. If two digests are the same the receiver can ensure that the message is intact. As can be seen, digital signature is depended on the signed data. Public Key Infrastructure Public Key Infrastructure (PKI) [19] is the integration of digital certificates, public key cryptography, and certificate authorities to build up an authentication system. A digital certificate is a digital document which is Secure Provision of Composite Services in an Insecure Networked Environment 12

19 used to identify a user. Digital certificates are issued by certificate authorities (CA). The most important information in a digital certificate is name of subject, public key of subject, and the signature of CA. The most popular digital certificate is X.509. CA is a trusted third party. CA signs a certificate by encrypting public key or has value of public key of certificate s subject. Before signing any certificate, CA has to verify all information in that certificate. Security Protocols Above technologies have been used to establish security protocols in Web environment. Examples of these protocols are IPSec and Secure Socket Layer. IPSec provides security services at IP layer. These services include access control, data integrity, authentication, protection against replay attack, and confidentiality. Secure Socket Layer (SSL) is a transport layer security protocol. SSL uses public-key cryptography and digital certificates to authenticate and to encrypt data when being transmitted over the Internet. SSL addresses three issues in security: authentication, privacy, and integrity. Techniques discussed so far have been used widely to solve security problem in Web environment. However, in case of Web services these technologies are not enough. XML security, which is mentioned in the next section, is considered as a main solution for Web services security XML Security XML Security a set of security technologies based on XML which includes XML Signature, XML Encryption, SAML, XACML, and XKMS. XML Signature XML Signature [16] is a specification about signing XML documents and inserting signature into XML documents. XML Signature provides integrity, nonrepudiation, and authentication. While other techniques such as SSL and IPSec can also provide these features, XML Signature has more advantages. Asymmetric encryption and hashing technologies are still applied for XML signature. Before XML Signature, PKCS#7 Signature is used to sign digital document whereas S/MINE is for attaching signature to document. Although PKCS#7 can be used to sign a XML document, this technology has some drawbacks. The first weak point is that it was not possible to express the signature in a standardized XML format. Another drawback is it cannot be used to sign just a part (or some parts) of an XML document. There are three manners to place XML Signature. They are XML Signature is contained within signed document, XML Signature contains signed document, and signature and signed document are stored separately. Secure Provision of Composite Services in an Insecure Networked Environment 13

20 XML Encryption XML Encryption [17] is a specification about encrypting and decrypting XML documents. The main purpose of XML Encryption is to ensure the confidentiality of data. SSL and IPSec also provide this functionality. However, these technologies do not fulfill the requirement of confidentiality in Web services environment. An example is the case where a SOAP message is processed by some services and each service just can read a part of data. This requirement is called persistent encryption. Similar to XML Signature, XML Encryption uses previous encryption algorithm such as DES, 3DES, and AES. What makes XML Encryption different from previous encryption methods are XML Encryption can express encrypted data in a standardized format and portions of an XML document can be selectively encrypted. XML Encryption may be applied in three cases: encryption of an XML element and its content, encryption of the contents of an XML element, and encryption of arbitrary data. SAML Secure Assertion Markup Language (SAML) [11] is a specification developed by Organization for the Advancement of Structured Information Standards (OASIS). This specification allows trust assertions to be specified using XML. These assertions can concern authorizations, authentications, and attributes of specific entities. The key role in the SAML model is played by authorities for attributes and authentications. SAML enables portable trust between different domains. This feature allow requesters of a chain of Web services developed in different domains with different security policies to authenticate only one time (which means single sign-on). XACML Extensible Access Control Markup Language (XACML) [12] is a specification which is used to express the rules on which access control decisions are made. Rules are based on characteristics of the requester, characteristics of the protocol used by requester, and the authentication context. XACML also defines rules for how to create, combine, and process rules. Rules in XACML include a target, an effect, and a set of conditions. Target is referred as an action on resource such as read file. An Effect is either permit or deny. Conditions are additional information about the context in which effect chosen. XKMS XML Key Management Specification (XKMS) [15] is a specification for building a Web service supporting public keys infrastructure. This Web service provides an interface to a public key infrastructure. The objective of XKMS is to allow a programmer to use PKI with just a little knowledge about it. Secure Provision of Composite Services in an Insecure Networked Environment 14

21 Figure 2-4: XKMS Service XKMS specification defines two Web services for managing public key credentials. The XMK Key Registration Service Specification (X-KRSS) deals with operations that manage life cycle of public key credentials while the XML Key Information Service Specification (X-KISS) supports query operations that obtain and validate public key credentials. An XKMS can just implement one of these services or both. X-KISS protocol supports two services, locate and validate. Both of these services deal with the query What are the public key credentials that I should use to communicate with X using protocol Y? While locate service s answer has not been validated as trustworthy the answer of validate service must be trustworthy with a specific trust policy. This means in case of using locate service, it is the responsibility of client to validate the returned information. X-KRSS supports four services namely register, recover, reissue, and revoke. Register service binds a public key with information of specific object. Recover service deals with the problem of losing private key. Reissue service updates the period in which a credential is valid. Revoke service eliminates a binding between a public key and a specific object WS-Security WS-Security [14] is an extension of SOAP in order to provide security mechanism for exchanging SOAP between Web services. WS-Security is based on XML Security. The main aim of WS-Security is to deal with the security in end-to-end context (compare with point-to-point or hop-to-hop context). A scenario where WS- Security applied is a SOAP message is routed through and processed by many Web services. Each of these services just processes a particular part of the message while leaving other parts intact. WS-Security defines the way to attach and encoding security token such as X.509 and Kerberos into SOAP message. WS-Security guarantees the integrity of the message by using XML Signature. The confidentiality of message is also provided by leveraging XML Encryption. In this chapter we have already reviewed service-oriented architecture and Web services technologies and Web services security technologies. All of these technologies are the bases for a Web services environment. In the next chapter we will concern security of Web services in a specific aspect: service composition. Web services, as a SOA implementation, have ability to be composed to build new services. The process of composing Web services is called service composition. One of the biggest challenges of service composition is security. This issue is discusses in the following chapter. Secure Provision of Composite Services in an Insecure Networked Environment 15

22 Chapter 3 Security Issues of Service Composition In Service-Oriented Architecture, services are core elements for developing applications. In the early days of SOA, most of researches are about modifying conventional information system infrastructures to SOA and directly using services to develop applications. Today, more researches are focusing on how to build new services from existing services. The process of building this kind of services is called service composition. This chapter discusses service composition and security issues of composite service. The word service refers to several kinds of services in distributed systems field. This project only focuses on Web services. The reasons of this choice are Web services are the best known technologies for implementing SOA and most of the research tasks for service composition are working on Web services. In this report, the term service composition means Web service composition. 3.1 Service Composition Service composition is the process of combining existing services to build new services. The new services are called composite services while existing services that used to build the composite service are called composed services. Composed services are sometimes referred as component service, basic service, or constituent services. A composed service may be a composite service. Figure 3-1: Composite service and composed services Service composition offers Web services developers many benefits. Firstly, service composition helps developers to master the complexity of systems. This is similar to building a huge program in structured programming or object-oriented programming. It is easier to manage if the program is divided into components, developed separately and combined when finished. Secondly, service composition increases flexibility of systems. Composite services act as a middle layer between applications which uses the composite services and composed services. Any changes of composed services will only impact on composite services, not the Secure Provision of Composite Services in an Insecure Networked Environment 16

23 applications. Thirdly, service composition gives third-parties opportunities to provide value-added services by using existing services. This means deployed services can be reused to build new services. Service Composition Approaches Service composition can be divided into two types. In the first type, the composite services are built by using conventional languages such as Java and C#. This process is similar to developing applications from Web services. In this case, the application is also a Web service. The middleware is not aware about service composition. The results are the composition process becomes cumbersome and the developers have to focus on both low-level processing of SOAP messages and processing of business logic. Moreover, changes in composed services may make the implementation of composite services be changed significantly. It is clear that this type of composition cannot satisfy requirements described above. The second type of composition is to use a high-level language for describing composite services with the support of middleware. The language focuses mainly on describing composed services and how to combine them. The invocations of composed services are left for middleware. BPEL and WSCI are two examples of these languages. This report only focuses on this type of composition. Composite Service Composed Service Composition Engine SOAP Engine SOAP Engine HTTP Engine HTTP Engine TCP/IP Figure 3-2: Communication path between composite service and a composed service Above is a diagram about communication path between a composite service and a composed service. Service composition defines how to build a service by combining existing Web services. The composition middleware, therefore, should provide facilities to define and execute composite services. Generally, a composition middleware includes: - A composition model and composition language: enable the specification of composite services, the order in which the composed services are executed, and how to execute them. Secure Provision of Composite Services in an Insecure Networked Environment 17

24 - A development environment: provide a graphical user interface tool for developers to develop composite services. - A run-time environment: this is the composition engine which executes the composite service by invoking composed service according to the specification of composite service. Obviously, composition language is the main element. The composition language determines the development environment and the composition engine. Because of this, in this section, only composition languages are concerned when discussing about approaches for service composition. At the moment, there are several languages for service composition. Examples of them are BPEL4WS [22], BPML [23], WSCI [25], WSCL [26], and OWL-S [24]. While BPML focuses on describing executable process (e.g. the flows of control inside composite services) WSCI and WSCL only address the issues of describing the abstract processes (e.g. interactions with composed services). There are not many vendors support these languages. BPEL4WS and DAML-S have emerged as two leading languages for service composition. BPEL4WS Business Process Execution Language for Web Services (BPEL4WS, BPEL for short) is a specification created in 2002 by Microsoft, IBM, BEA, Siebel Systems, and SAP. In 2003, OASIS formed a technical committee (TC) for this specification. This TC is currently working on version 2.0 called WS-BPEL. BPEL specification is used to model the behaviour of Web services in a business interaction and create composite services. BPEL is layered on top of WSDL. While WSDL defines the interfaces, BPEL defines how to arrange operations of those interfaces to build up business functions. One of the most important notions in BPEL is Partner Link. This notion is used to define roles of services in peer-to-peer interactions. BPEL supports both basic and structured activities. Examples of basic activities are <receive>, <reply>, and <invoke>. <receive> is used to receive a message sent from other services in blocking wait manner. <reply> is used to send a reply message corresponding to a received message. <invoke> is used to execute an operation supported by another service. Structured activities support conditional loop and dynamic branching. This means structured activities manage flow of execution of basic activities. Data in BPEL process is transferred as variables in conventional programming languages (e.g. C/C++, Java). BPEL supports exception handling in try-catch-throw manner. BPEL works on top of WS-Coordination and WS-Transaction so transaction management is supported. OWL-S Web service composition may be solved by using Semantic Web [24]. Semantic Web views the World Wide Web as a globally linked database of resources. Relationships between resources in this database are described using Resource Description Framework (RDF) [28]. RDF is a XML-based language to describe resources. A relationship is described by using RDF triple: subject, predicate, and object. RDF Schema (RDFS) [29] is used to Secure Provision of Composite Services in an Insecure Networked Environment 18

25 describe classes and properties of classes. This language, in another word, is the language for people to define vocabularies of RDF. DAML+OIL is a semantic markup language built on RDF and RFDS. OWL is the language derived from DAML+OIL which is used for publishing and sharing ontologies on the WWW. OWL-S (formerly DAML-S) is an OWL-based Web service ontology which provides Web services providers the ability to describe their Web services properties and capabilities in a computer-interpretable form. OWL-S models a Web services with properties presents, describedby, and supports. Ranges of these properties are ServiceProfile, ServiceModel, and ServiceGrounding respectively. As the properties imply, each instance of Service class presents a ServiceProfile description, be described by ServiceModel description, and supports a ServiceGrounding description. ServiceProfile gives a high-level description of the features of the service. These features help clients to discover the service. Examples of information provided by this class are what are accomplished by the service, limitations on service applicability and quality of service. ServiceModel gives clients information about how to use the service. These include the inputs, outputs, preconditions, and postconditions of the service. ServiceGrounding provides clients with information of how to access the service such as communication protocols, port number, and message format. S. McIlraith and T.C Son proposed an approach to transfer this information to Prolog syntax [30]. Business processes, which are considered as subclasses of ServiceModel, will be described by goals and logical steps to reach them. Inference rules then are applied to composed existing services to achieve the goal. Neither BPEL nor OWL-S has specification of nonfunctional QoS properties such as security, dependencies, and reliability. At the moment, BPEL approach has received considerations from many software vendors while OWL-S approach is still in research. Some BPEL engines were released. Examples of them are IBM BPEL4J engine [35], Oracle BPEL Process Manager [36], ActiveBPEL [37], and PXE [38]. ActiveBPEL and PXE are open source projects. Note that one may consider π-calculus [31] and Petri Net [32] as composition approaches [33]. However, it seems that these solutions are only for describing composition processes. Web component [34] is another approach of service composition but this solution lacks of scalability so there are not many supports. Another classification of service composition which based on the flexibility of composition process is introduced by Jian Yang and his colleagues in [20]. Service composition is divided into three categories including explorative composition, semi-fixed composition, and fixed composition. In explorative composition, the composition is generated depends upon the requests from clients. Requests are specified using a high-level language which helps composite service to choose correct composed services based on information about composed services held by directory services. The composition is considered as semi-fixed composition if the specifications of composed services are statically defined at design time whereas the actual composed services are only bound at run time. In the last type of composition, fixed composition, both the specifications of composed services and composed services themselves are specified at design time. Secure Provision of Composite Services in an Insecure Networked Environment 19

26 Service Composition vs. Service Coordination Service coordination is about organizing activities of Web services when interacting with others. Service composition also concerns the interactions of Web services. What are the differences between them? The main difference between them is service composition is about implementation a composite service and this implementation is internal. Other Web services should not know any about this implementation. Service coordination, in contrast, is about how to interact with a Web service. Service coordination specifies the order in which messages are exchanged to complete a business process. This means information describing service coordination of a Web service should be accessible from other Web services. Service coordination imposes constraints on how service composition is to take place. 3.2 Security Issues Security issues of composite services include those of Web service and more additional issues. On one hand, the composite service itself is a Web service so it implies all security challenges a Web service may face. On the other hand, the composite service interacts with several composed services therefore it has to address the problems arising from the heterogeneity of composed services. Composite Service as a Web service client When interacting with a specific composed service composite faces all security issues which a conventional Web service client may face. Because Web services work on top of other technologies any security issues of these underlying technologies will impact on Web services. In addition to this, some security issues may be caused by the loosely coupling characteristic of Service-Oriented Architecture. To analyse security issues of communications between composite services and composed services we consider two phases: requests are sent from composite services to composed services and results are sent from composed services to composite services. In the first phase, when a request is sent from composite services, there are some security issues need considering. Firstly, an attacker can read the sent message. The attacker can do this by listening on communication channel between the composite service and the composed service. Secondly, the destination of the request may be changed while being transferred. The request is then routed to attacker s service which will return a malicious result. Changing destination of a request may be done at SOAP level or at underlying transport layers (e.g. HTTP, TCP/IP). Attacks on UDDI registries or Domain Name Servers also lead to the same result. The third situation is the attacker changes the content of the request before it arrive at the composed service. The result is the composed service return a response which is not what the composite service expects. However, neither the composite nor the composed service is aware of this. Another kind of attack that an Secure Provision of Composite Services in an Insecure Networked Environment 20