DESIGNING A LOGICAL SECURITY FRAMEWORK FOR ENTERPRISE SERVICE ORIENTED ARCHITECTURE (ESOA) ALAEDDIN KALANTARI

Transcription

1 DESIGNING A LOGICAL SECURITY FRAMEWORK FOR ENTERPRISE SERVICE ORIENTED ARCHITECTURE (ESOA) ALAEDDIN KALANTARI A thesis submitted in fulfillment of the requirements for the award of the degree of Master of Computer Science (Information Security) Centre for Advanced Software Engineering (CASE) Faculty of Computer Science and Information System Universiti Teknologi Malaysia MARCH 2009

2 iii DEDICATION To my parents, wife and family for their love and support

3 iv ACKNOWLEDGEMENT In the name of kindly God, the best guide for human and world. I would like to express my sincere appreciation to my supervisor Associate Prof. Dr. Zailani Mohamed Sidek. He has been extremely helpful and offered great guidance throughout this project. I am also grateful to the Information Security lecturers, in particular to my program coordinator, Dr. Rabiah Ahmad and all staffs. I also wish to thank Mr. Seyed Gholam Hassan Tabatabaei (PHD Student, UTM) who helped me to understand Web Services and guide me throughout this project. It is difficult to express my thanks to my parents and family. I just want to say I love you father, mother, and my lovely wife and daughter. Thanks for your help and support.

4 v ABSTRACT Enterprise Service Oriented Architecture (ESOA) is an appropriate strategy to provide an integrated, flexible, adaptable, and cost efficient enterprise Service-based that derives from various set of Web Services combined with business logic to support a particular business process. Despite the benefit of SOA, integration of application makes security design more complex. It brings several security problems. There is no comprehensive security framework for helping developers to design an adequate security solution. In order to alleviate these problems, some additional nonfunctional security requirements are needed. This project aims to analyze the security requirements raised by real world SOA in an enterprise and proposes a logical security framework to meet these needs. This framework can support all three security levels (content, communication, and network) of IT infrastructure. The proposed Security Service Oriented Reference Architecture (SSORA) shows which security service defined by the proposed security framework can be applied on each layer of Service Oriented Reference Architecture. In the real world, the location of each service is an important element of security design. In order to decrease the holes of the inner firewall, a Service Routing Coordinator (SRC) is located in the internal network. This service acts as an intermediary between the Web Services and the internal network servers. The proposed framework is applied on the logical SOA deployment architecture in order to design a security solution for an enterprise. Designing a security solution for Razavi Financial Institute (RFI) shows that proposed security framework can be applied for any SOA based environment.

5 vi ABSTRAK Seni Bina Orientasi Servis Enterprise (ESOA) adalah satu strategi bagi menyediakan satu asas servis integrasi, fleksibel dan berkesan yang terhasil daripada gabungan pelbagai servis web dengan logik perniagaan untuk menyokong satu proses khusus perniagaan. Selain daripada faedah SOA, integrasi applikasi menjadikan rekabentuk keselamatan bertambah kompleks. Ini akan membawa beberapa masalah keselamatan. Tidak terdapat rangka keselamatan yang menyeluruh untuk membantu pembangun-pembangun sistem bagi merekabentuk penyelesaian keselamatan yang terrbaik. Untuk mengatasi masalah ini, beberapa keperluan keselamatan yang tidak berfungsi adalah di perlukan. Projek ini bertujuan untuk menganalisi keperluan keselamatan yang di bangkitkan oleh dunia sebenar SOA dalam satu enterprise dan mencadangkan satu rangkakerja keselamatan logik untuk mencapai keperluan tersebut. Rangkakerja ini boleh menyokong kesemua tiga peringkat keselamatan infrastruktur teknologi maklumat seperti kandungan, komunikasi, dan rangkaian. Cadangan servis keselamatan berorientasikan Seni Bina Unjukkan (SSORA) mencadangkan servis keselamatan yang dicadangkan oleh rangkakerja keselamatan yang boleh diaplikasikan ke atas setiap lapisan Seni Bina Berorientasikan Servis (SORA). Dalam dunia sebenar, lokasi setiap servis adalah elemen penting dalam merekabentuk keselamatan. Untuk mengurangkan kelemahan yang terdapat di dalam firewall, perkhidmatan Service Routing Coordinator (SRC) akan di tempatkan di dalam rangkaian. Servis ini bertindak sebagai pengantara di antara servis web dan rangkaian dalaman server. Satu cadangan rangka kerja digunakan ke atas logik seni bina SOA bagi merekabentuk satu penyelesaian keselamatan bagi sesuatu perusahaan. Merekabentuk satu penyelesaian keselamatan untuk RFI mempamirkan rangka kerja yang dicadangkan boleh diaplikasikan kepada mana-mana persekitaran asas SOA.

6 vii TABLE OF CONTENTS CHAPTER TITLE PAGE DECLARATION DEDICATION ACKNOWLEDGEMENT ABSTRACT ABSTRAK TABLE OF CONTENTS LIST OF TABLES LIST OF FIGURES LIST OF ABBREVIATIONS ii iii iv v vi vii xii xiii xvi 1 INTRODUCTION Background of the Problem Statement of the Problem Aim Objectives of the Study Scope of the Study Significance of the Study 6 2 LITERATURE REVIEW Overview of Information Security Security in a Network-Centric Environment Definition of Web Service Security Standards and Technology Transport-Level Security: SSL XML Encryption XML Signature 14

7 viii XML Key Management Specification (XKMS) Security Assertions Markup Language (SAML) XML Access Control Markup Language (XACML) X.509 Certificates Web Services security specifications Kerberos Overview of Service Oriented Architecture (SOA) Definition of Service Oriented Architecture (SOA) Basic components of a SOA Enterprise Service Bus Understanding Enterprise SOA (ESOA) The ESOA development lifecycle S3: A Service-Oriented Reference Architecture Operational Systems Layer Service Component Layer Services Layer Business Process Layer Consumer Layer Integration Layer Quality of Service Layer Information Layer Governance Layer Service Oriented Modeling and architecture (SOMA) Business modeling and transformation Solution management Identification phase Specification phase Realization phase Implementation, deployment, and management phases Understanding SOA security Applying security at the message level Converting Security into a Service Declarative and Policy-based Security Related works 48

8 ix SOA Security Framework for N C E IBM SOA Security Reference Model SOA Infrastructure Reference Model Current ESOA security solutions and products SOA Software Solutions IBM SOA Security Solutions Oracle SOA Security Solution JBoss ESOA Platform Vordel solution Comparison of current solutions Summary 60 3 RESEARCH METHODOLOGY Research Design and Procedure Literature Review Analysis of Requirement Design Development Verification Instrumentation Assumptions and Limitations The Gantt chart of Research Activities 67 4 LOGICAL SECURITY FRAMEWORK FOR AN ESOA ESOA security requirements Identity Trust management Authorization Audit End-to-End Security Privacy Interoperability Secure Configuration Availability 74

9 x Quality of Service Secure Development Assurance Firewall Service discovery Security policy Physical security Time management Logical Security Framework Content Security Services Compliance and Reporting Identity and Access Services Infrastructure Security Services Privacy Service Audit Service Trust Management Service Time Management Service Security Policy Management Service Governance and Risk Management Security Service Oriented Reference Architecture (SSORA) Logical Security Deployment Architecture of ESOA SOA Security Solution Design Conclusion CASE STUDY: RAZAVI FINANCIAL INSTITUTE Introduction to the case study Business process Solution overview Service Modeling Identification Specification IMPLEMENTATION Apache Axis 117

10 xi Axis Architecture Install Apache Axis WSO2 Web Services Framework/PHP (WSO2 WSF/PHP) Installing and Running on Microsoft Windows Implementing case study Customer Service Proxy Service Authentication Service Portal Secure Web Service Client CONCLUSION AND FUTUER WORK Conclusion Contributions Future work 134 REFERENCES 135

11 xii LIST OF TABLES TABLE NO. TITLE PAGE 2.1 The comparison of ESOA security solution Security Services Standard Goal-service model for the case study 112

12 xiii LIST OF FIGURES FIGURE NO. TITLE PAGE 2.1 Security levels XML Framework and non-xml Framework standards Components of an XML Signature Web Service security specifications SOAP message security with WS-Security SOA shift IT from an application-centric to service centric Elements of a SOA Stacks Presented by IBM SOA components and operations Enterprise Service Bus (ESB) An ESOA framework presented by [23] The emerging ESOA infrastructure The ESOA development lifecycle presented by SAP Logical layers in Service Oriented Reference Architecture Interactions in the integration layer SOMA phases a fractal model of software development SOMA Life-cycle high-level flow The different envelope can be placed inside the main envelope One of the possible ways in which a security service can work Security service can be implemented as part of ESB Security framework for SOA presented by Catharina Candolin 49

13 xiv 2.21 IBM Security Reference Model SOA Infrastructure Reference Model Research Design and Procedure Research Flow Chart The Proposed Logical Security Framework for ESOA End to End security in the SOA Identity propagation in the SOA Identity and Access Service framework The six main layers of Service Oriented Reference Architecture The proposed Security Service Oriented Reference Architecture IBM Typical logical deployment architecture The Proposed Logical Deployment Architecture of ESOA The sequence diagram of ESOA Deployment Architecture Decryption Service sequence diagram Reference Architecture for the Authentication Service Authentication of browser-based user identity Authentication of WS-Client request sequence diagram Use of SAML and XACML in Implementing ABAC The proposed Service Routing Coordinator Architecture Service Routing Coordinator Architecture sequence diagram STS Architecture Security Token Service sequence diagram Service-Oriented Audit Architecture Security solution class diagram The Complete Proposed ESOA Security Solution Design A holistic business processes of RFI 109

14 xv 5.2 Logical SOA deployment architecture for this case study Identity and Access management Complete security solution design for case study The Axis engine uses chains of handlers The Tomcat localhost home page The Apache Axis home page The Axis Happiness page WSDL list of Web Service The sequence diagram of case study (web customer scenario) The view of NetBeans and the location of services The web based client to send username and password The portal service main page 129

15 xvi LIST OF ABBREVIATIONS SOA - Service Oriented Architecture ESOA - Enterprise Service Oriented Architecture SOMA - Service Oriented Modeling and Architecture XML - extensible Markup Language WSDL - Web Service Description Language UDDI - Universal description Discovery and Integration SOAP - Simple Object Access Protocol RFI - Razavi Financial Institute MSIC - Mazan Salamat Insurance Co. PKI - Public Key Infrastructure SSL - Secure Socket Layer MEP - Message Exchange Pattern XKMS - XML Key Management Specification SAML - Security Assertions Markup Language XACML - XML Access Control Markup Language WSDL - Web Security Policy Language SSO - Single Sign On ESB - Enterprise Service Bus WBS - Work Breakdown Structure GSM - Goal Service Modeling SSORA - Security Service Oriented Reference Architecture

16 xvii DMZ - Demilitarized Zone DCS - Decryption Service AZS - Authorization Service ATS - Authentication Service PS - Policy Service CSS - Content Security Service SRC - Service Routing Coordinator

17 1 INTRODUCTION CHAPTER 1 INTRODUCTION In this chapter an introduction to research proposal is provided. First of all, the background of the problem to be solved is described. After that, the problem statement, and also objective, scope, and importance of the study are described respectively. 1.1 Background of the Problem Nowadays, the demands of collaboration, integration and Web Service based application increased and, organizations need to share their databases and application to work together efficiently, reliably and cost-effectively [1]. To meet these needs, organizations are embarking on to use infrastructure strategy based on Service Oriented Architecture (SOA). SOA uses services as building blocks with several different ways to organize and architect the application within an enterprise. SOA shifts IT from an application-centric to service-centric [4]. Despite the benefit of SOA, designing and implementing an enterprise SOAbased involves some challenges. One of the critical issues is security in Enterprise Service Oriented Architecture (ESOA). To meet such issue, the philosophy of SOA should be investigated. That is, security should keep the services as open and easy to use as possible, and interoperability should not suffer because of security. There are

18 2 three main approaches to secure SOA [1] such as message-level security, security as service, and Policy-driven security. Notice that, the boundaries between these three aspects of classification are not always strictly defined. Moreover, there are several standards such as XML Signature [41], XML Encryption [42], WS-Security [44], XKMS [47], SAML [43], and XACML [45] that have been developed to provide comprehensive security schemes for Web Services to achieve aforementioned approaches in SOA. In order to achieve an ESOA, a typical ESOA will encompass a complete infrastructure composed of various software and hardware components, partners and standards [12]. Some of the existing SOA security solutions can be adopted. However, due to the nature of Enterprise, they are still not enough. Moving data from one place to other place securely within an enterprise is a hot issue. This problem derives from heterogeneous use of security standards [37]. In fact, incorrect use of them may lead an enterprise to loss data and be failed. For example, if two parsers format the same message differently, XML-Signature validation will be failed [37]. In an enterprise where multiple applications come together to provide a service, security breaches may increase much higher than in a single application especially, when an enterprise communicate with external service provider such as partners and agents. In such case, data should be protected itself even during a transportation through the trustable intermediary and policy management should be placed. Furthermore, new SOA developers who do not security expert make SOA implementation errors or end up with security loopholes. It occurs when developers don t understand SOA clearly. However, there are several providers that have been provided their products to consider security feature during SOA development lifecycle such as IBM [17], SAP [56], Vordel [34], and Oracle [22].

19 3 1.2 Statement of the Problem Enterprise SOA (ESOA) is a blueprint for an adaptable, flexible, and open IT architecture for developing enterprise Web Services-based that derives from various set of Web Services combined with business logic to support a particular business process [2]. Integration of applications makes security design more complex than it would otherwise be [12]. Unlike other integration technologies, SOA is positioned well to deal with security challenges in integration. Due to the nature of SOA and by being standards-based, SOA lets standards to alleviate old problem of integration security. As mentioned before, 1) these techniques are not yet known widely enough to practitioners of SOA and most practitioners are often not very clear on how to address security challenges. In order to provide security within an enterprise SOA-based, most developer and products use WS-Security [44] that defines a standard set of SOAP extensions that can be used to provide message content integrity and confidentiality. Theoretically, it accommodates a variety of security models and encryption technologies and is extensible to support multiple security token formats. 2) In practice, improper use of them can make SOA environment vulnerable as SOAP message could be modified by unauthorized parties [6]. According to [13], tools and technology will not automatically give SOA. Implementing SOA within an enterprise evolves different concepts of business process. In the real world, the location of a security service is an important element of security design that needs to take into account network design and user locations. Because of this concept, developers have to build their own architecture strategy related to enterprise business requirements. ESOA introduces new security threats that need to be considered within SOA life cycle. Therefore, a security framework, guideline or model for Enterprise SOA must consider all security aspects in SOA environment. According to two problems that mentioned above, the heterogeneous use of security standards and products lead Enterprise SOA to be failed. Some current

20 4 scenarios and solutions can be used to tackle this problem. But, the most important problem is the lake of unified security framework for Enterprise SOA. The general research question that this research will answer is: What comprehensive security framework can be used to design infrastructure architecture for an Enterprise SOA to assure its business process? In order to be able to answer this question, a set of research questions that address the problem in detail are defined, as follows: 1. RQ1: What is SOA and how it is deployed? o What is the interaction within the SOA? o What platforms are required to support the designing, implementing and maintaining of SOA? 2. RQ2: why security is important to SOA? 3. RQ3: what is ESOA? o How an ESOA is designed? o What platforms are required to support the designing, implementing and maintaining of ESOA? 4. RQ4: what security architecture and framework can be considered for securing an ESOA? o What security model and framework can support existing approaches and standards to design ESOA security solution? 1.3 Aim The aim of this project is to propose a logical security framework for ESOA by analyzing the security requirements raised by real world ESOA and based on current standards and technologies that meet these requirements.

21 5 1.4 Objectives of the Study Based on the above description of problem statement the objectives of this project are: (i) To identify all known security challenges and requirements in ESOA. (ii) To investigate current security approaches for ESOA. (iii) To analyze and determine a logical security framework to support ESOA based on current approaches and standards. (iv) To design typical logical ESOA deployment architecture. (v) To demonstrate ESOA security solution design based on proposed Security framework and using a case study such as Razavi Financial Institute (RFI). 1.5 Scope of the Study This project was inspired by research directions such as Web Services, Service Oriented Architecture (SOA), security standards and technology in SOA, and Enterprise SOA. Those directions are presented here as the scope of the research subject in this proposal. First of all, this research was inspired by the concepts of the Web Service and its initiatives proposed both in academic and in industry. This concept is XML based and uses standard protocols such as Universal Description, Discovery, and Integration (UDDI) [26], Web Services Description Language (WSDL)[27], and Simple Object Access Protocol (SOAP) [28]. Web Services are described in section 2.3. Secondly, this project only focuses on using conceptual aspects of current security standards and technologies in SOA to propose a security framework. Any problem of these standards is beyond the scope of this project. Those standards are described in section 2.4.

22 6 SOA is a way of planning, designing, implementing and testing IT systems. This project is going to propose a logical security framework for ESOA and design a security solution architecture based on proposed framework. It only focuses on design as security architecture. It does not go through the other phases of SOA lifecycle. In addition, this project using a case study such as Razavi Financial Institute (RFI) to demonstrate the security solution based on the proposed framework and logical deployment. Finally, this project focuses on those enterprises that are designed based on Service Oriented References Architecture (S3) [63]. 1.6 Significance of the Study SOA is an architectural style for an enterprise system composed from a set of loosely coupled services that interact with each other by sending message. In this architectural style, applications are created by coordinating and assembling services. A key principle about services is that they should be easily reusable and discoverable in a securely manner. The significant of this study can be described as following items: The channels of communication between the participating entities in a SOA are much more vulnerable than in operating systems or within the boundaries of an organization s computer network, since they are established on public networks. Many efforts have been made to alleviate those security vulnerabilities that were induced in the complex context of SOA. They principally consisted in the production of numerous, often overlapping security standards by the industry actors [8],[9]. But there is still no clear view of how to use them in order to produce secure ESOA.

23 7 SOA enables the design of flexible and modular software application that can be used in cross-organization context. Unfortunately, those qualities generally have a negative impact on the security of software application.

24 2 LITERATURE REVIEW CHAPTER 2 LITERATURE REVIEW In this chapter, some background on Information Security, Web Services, security standards and technology, Service Oriented Architecture (SOA), SOA security, and ESOA are provided. In addition, current security solutions have been classified, described, and evaluated. The purpose of this chapter is to describe the basic concepts and present current approaches for ESOA Security. 2.1 Overview of Information Security It is important to have a general understanding of information security before to embarking on design an SOA environment. There are six general security aspects that can encompass security requirements of an enterprise. These can also be considered as requirements that define information security [36]: Authentication: Ensures that the sender is who really send a message and receiver is who he claims to be and intruders should not be able to masquerade as a receiver or sender. It is a service related to identification [4]. There are several mechanism can be used to ensure authentication such as username/password, smart cards, and Public Key Infrastructure (PKI).

25 9 Authorization or Access Control: Only authenticated entity can access to the data, system, and services. Access control lists are used to implement this. Availability: Ensures that system able to provide uninterrupted services to authenticating and authorizing users. Confidentiality: Is a service to keep the content of information from everyone except who are authorized to read them. This assures that no one can read information in storage and in-transit. Encryption is used to assure message confidentiality. Integrity: Ensures that information cannot be modified intentionally or unintentionally by unauthorized entity. In fact, it addresses the unauthorized alteration of data. Receiver of a message should be able to verify that this message has not been changed during the transformation. It is important to have a service for detecting data manipulation such as insertion, deletion, and substitution. Digital signatures are used to assure message integrity. Non-repudiation: Ensure that sender and receiver cannot be able to legitimately claim they didn't send/receive the message. It is vital requirement for social interaction on computers, and is similar to face-toface interactions. For example, some one may authorize to buy property by another entity and later claims such authorization was not granted. A trusted third party is needed to rectify the dispute. 2.2 Security in a Network-Centric Environment According to [65], there are three levels security including: content level, communication level, and network level as shown in Figure 2.1. The content level contains all security issues that should be considered to protect the content such as information and services when they are transferring or storing. Typically the information is protected from disclosure and modification. Furthermore, the end

26 10 users must be able to verify the source of the information. The communication level provides a point-to-point security between communicating nodes such as Secure Socket Layer (SSL). Figure 2.1 Security levels Network security refers to the security of the network itself, that is, the network must be secured so that it is able to perform its tasks of routing the right packets to the right place intact and in time without violating specified privacy policies. This level of security differs from the two others in the sense that it is not concerned with the actual content but rather with how to transfer the content from source to destination. 2.3 Definition of Web Service According to [46], Web Services are loosely coupled computing services that can reduce the complexity of building business applications, save costs, and enable new business models. Web Services are application components that using open protocols to communicate and they are self-contained and self describing. Web Service can be discovered using UDDI [26] and used by other applications.

27 11 Extensible Markup Language (XML) is the basic for Web Services. Web Services can be able to publish the functions and data to the rest of the world. Another definition of Web Service is provided by IBM [39], A Web Service is a software interface that describes a collection of operations that can be accessed over the network through standardized XML messaging. It uses protocols based on the XML language to describe an operation to execute or data to exchange with another Web Service. There are two types of uses of Web Services: (i) Reusable application components: there could be only one type of application component as a service which able to perform defined task and anyone can use it such as currency conversion, weather report, and language translation as services. (ii) Connect existing software: with Web Services you can exchange data between different application and different platform to rectify interoperability problem. Web Services have three basic platform elements [40]: SOAP: SOAP [28] is a simple XML-based protocol to allow applications exchange information over the Web. SOAP stands for Simple Object Access Protocol and designed to communicate between applications via internet. Unlike RPC, it allows developer to get around firewalls. SOAP is language and platform independent. It is fundamentally a stateless, one-way message exchange paradigm, but applications can create more complex interaction patterns by combining such one-way exchanges. SOAP provides a distributed processing model where a SOAP message is delivered from a sender to an ultimate receiver via zero or more SOAP intermediaries. This distributed processing model can support many message exchange patterns including but not limited to one-way messages, request/response interactions, and peer-to-peer conversations. WSDL: Web Service Description Language (WSDL)[27] is a XML-based language for describing the mechanics of interacting with a particular Web Service. The abstract functionality of the Web Service is defined in terms of the types of

28 12 messages it sends and receives in WSDL interface. An interface is a set of operations and an operation is a sequence of input and output messages. An operation associates a Message Exchange Pattern (MEP) with the message types that will be exchanged during execution. The message types are defined using a schema language such as (but not limited to) XML Schema. The abstract interfaces are associated to concrete message formats and transmission protocols with binding descriptions. UDDI: Universal Description Discovery and Integration (UDDI) [26] is a directory service and platform-independent framework where businesses can register and discover for Web Services. UDDI is a directory for storing Web Service interfaces described by WSDL and built into the Microsoft.NET platform. The benefit of UDDI that can be mentioned is discovering the right business from the millions currently online and programmatically describing services and business processes in a single, open, and secure environment. There are three main parts of this registry: White Pages that list contact information about the company that developed the Web Service; Yellow Pages that organize Web Services by such categories as geography and industry code; and Green Pages that hold WSDL descriptions. 2.4 Security Standards and Technology Security standards within an Enterprise are implemented in non-xml frameworks at the transport level and in XML frameworks at the application level, as shown in the figure 2-1 [22]. Most SOA industry standards are defined in XML frameworks. The Advancement of Structured Information Standards (OASIS), the World Wide Web Consortium (W3C), and Liberty Alliance have been developing some standards to provide comprehensive security schemes and management for SOA environments. The following sections describe these standards and specification.

29 13 Figure 2.2 XML Framework and non-xml Framework standards Transport-Level Security: SSL Secure Socket Layer (SSL) [61], known as Transport Layer Security (TLS) is placed in non-xml Framework that is the most widely used transport-level data communication protocol providing Authentication, Confidentiality, and Message Integrity. SSL can be used in three modes: No authentication: Neither the client nor the server authenticates itself to the other. In such case, only confidentiality is used. Server authentication: Only the server authenticates itself to the client. Two-way authentication: Both client and server authenticate themselves to each other. SSL use secret-key and public-key cryptography to secure communications between senders and receivers.

30 XML Encryption XML Encryption [42]is a standard that has been developed by W3C to encrypt and decrypt portions of XML documents. In order to decrypt the message, the receiver uses XML DOM (a parser) to extract the cipher text and put it into an algorithm. Through this standard both symmetric and asymmetric cryptography to secure data can be used. This standard assures confidentiality of messages that transfer from origins to destinations. There are five types of XML encryption: Encryption XML Element Encryption XML Element Content (Elements) Encryption XML Element Content (Character Data) Encryption Arbitrary Data and XML Documents Super-Encryption The following example shows how only the credit card number is encrypted. <?xml version= 1.0?> <PaymentInfo xmlns= > <CreditCard> <Name>Marc</Name> <CreditCardNumber> <EncryptedData xmlns= Type= > <CipherData> <CipherValue>A23B4...5C56</CipherValue> </CipherData> </EncryptedData> </CreditCardNumber> <ExpireDate>03/2011</ExpireDate> </CreditCard> </PaymentInfo> XML Signature XML Signature [41]developed with collaboration between the W3C and IETF (Internet Engineering Task Force). An XML signature is equivalent to a digital signature; it is a standard for securely verifying the origins of messages. A fundamental feature of XML Signature is capability to digitally sign portions of an

31 15 XML document with a variety of different digital signature algorithms rather than the complete document. It is used with SOAP messages. XML Signature supports authentication, data integrity, and none-repudiation. It allows for attaching multiple signatures to different parts of the XML documents. For example, a single XML signature might cover character-encoded data (HTML), binary-encoded data (a JPG), XML-encoded data, and a specific section of an XML file. Figure 2-2 shows components of an XML Signature. Figure 2.3 Components of an XML Signature XML Key Management Specification (XKMS) XML Key Management Specification (XKMS) [47]has been developed by the W3C which allows clients to acquire cryptographic key information. Moreover, it describes protocols for the distribution and registration of public keys and supports XML Signature and XML Encryption. XKMS is built of two parts: XMK Key Information Service Specification (X-KISS) which processes and validates public keys.

32 16 XML Key Registration Service Specification (X-KRSS) that used to registration and revocation of public keys. X-KRSS provides four services such as register, recover, re-issue, and revoke that can mange life cycle of public keys and credentials Security Assertions Markup Language (SAML) Security Assertions Markup Language (SAML) [43] has been defined by OASIS. It designs a framework for exchanging authentication and authorization information. Another definition that provided by IBM [5], Security assertion markup language (SAML) is the first industry standard for secure e-business transactions based on XML. SAML is being developed to define a common way for sharing security services between companies engaged in business-to-business and business-toconsumer transactions. SAML allows companies to securely exchange authentication, authorization, and profile information among their customers, partners, or suppliers regardless of their security solutions or platforms. As a result, SAML supports the interoperability between different security systems. The SAML framework includes 4 parts [22]: Assertions: How authentication and authorization information are defined. Protocols: How SAML Request is asked and SAML Response (the required assertions) is got. Bindings: How SAML Protocols ride on industry-standard transport (e.g., HTTP) and messaging frameworks (e.g., SOAP). Profiles: How SAML Protocols and Bindings combine to support specific use cases.

33 17 In the context of WS-Security, only SAML assertions are used and are very popular security tokens within WS-Security. The protocols and bindings are provided by the WS-Security framework. WS-security and SAML assertion can be used to prevent man-in-the-middle and replay attacks [22]. SAML assertions can be embedded (i.e., a SAML assertion can contain another SAML assertion). SAML assertions can be signed (using XML Signature) and/or encrypted (using XML Encryption) XML Access Control Markup Language (XACML) XML Access Control Markup Language (XACML) [45] develops a standard for complex access control and authorization system. Unlike the approach taken by proprietary access control lists (ACL), XACML is an industry accepted standard that provides a well defined structure to create rules and policy sets to make complex authorization decisions. The Web Services Policy Language (WSPL) is a generic language for declaring policy information. XACML addresses several use cases: Define a policy Gather required data for policy evaluation Evaluate policy Enforce policy X.509 Certificates An X.509 digital certificate is designed to send a public key to a receiver and includes standard fields such as certificate ID, issuer's Distinguished Name (DN), validity period, owner's DN, owner's public key, and so on. Certificates are issued by Certificate Authorities (CA) that verifies an identity and gives a certificate, signing it with the CA's private key and then, publishes its own certificate with its public key.

34 Web Services security specifications The Web Service security model [3], introduce a layered approach for securing Web Services that includes individual interrelated specifications. The specifications of WS security are as follows: Figure 2.4 Web Service security specifications WS-Security: The WS-Security specification was ratified by the OASIS to provide message level security such as message integrity, message confidentiality, and message authentication. Unlike SSL, it defines an end-to-end security framework that provides support for intermediary security processing. WS-security uses XML Signature and message XML Encryption to protect message. It can be used to digitally sign and encrypt any combination of message portions. Figure 2-4 illustrate how WS-Security can be used to protect a SOAP message.

35 19 Figure 2.5 SOAP message security with WS-Security WS-Policy: WS-Policy [48]defines a framework and model for the expression of the capabilities and restrictions of the security policies on intermediaries and endpoints. WS-Policy defines a policy to be a collection of one or more policy assertions. Some assertions specify traditional requirements and capabilities that will ultimately manifest on the both wire (for example, authentication scheme and transport protocol selection) and no wire (for example, privacy policy and QoS characteristics). WS-Trust: The Web Services Trust Language (WS-Trust) [49] is used to issuance, exchange, and validation of security token. It uses the secure messaging mechanisms of WS-Security. WS-Trust is able to disseminate the credentials within different trust domains. Two parties must either directly or indirectly exchange their security credentials. However, each party needs to determine if they can trust the asserted credentials of the other party.

36 20 WS-Federation: WS-Federation [50] describes how the existing Web Services security building blocks can be used to provide federation functionality, as well as trust, single sign-on, single sign-off, and attribute management across a federation. Three specification of WS-Federation are: WS-Federation: it focuses on the relationships between parties and the highlevel architecture that supports these relationships and describes how to implement a federation in a Web Services environment. WS-Federation Active Client: describes how to implement federation functionality in the active client environment. Active clients are those able to issue Web Services requests and react to a Web Services response. WS-Federation Passive Client: describes how to implement federation functionality in a passive client environment. A passive client is one that is not Web Services-enabled. WS-SecureConversation: The Web Services Secure Conversation Language (WS-SecureConversation) [51] provides secure communication between services. WS-SecureConversation cannot provide a complete security solution and it join with other Web Service and application-specific protocols such as WS-Security to give a wide variety of security models and technologies. WS-SecurityPolicy: The Web Services Security Policy Language (WS- SecurityPolicy) [52] defines a set of security policy assertions to apply SOAP Message Security, WS-Trust, and WS-SecureConversation in Web Service security. WS-Provisioning: WS-Provisioning [53] is used to make easy interoperability between provisioning systems. It describes the APIs and schema and allows software vendors to provide provisioning facilities in a consistent way.

37 Kerberos Kerberos [31] is a cross-platform authentication and single sign-on system that using symmetric keys to provide joint authentication between two entities. Kerberos uses particular terminology such as a Principal that is an identity for a user and a Realm that is a Kerberos server environment. Each Kerberos realm has at least one Key Distribution Center (KDC). 2.5 Overview of Service Oriented Architecture (SOA) Nowadays, IT executives continuously strive to find a way that decrease costs and exploit of existing technology while they also have to think about serving customers better, be more competitive, and increase business prosperity. In addition, the demands of collaboration, integration and Web Service based application increased and, organizations need to share their databases and application to work together efficiently, reliably and cost-effectively [1]. Furthermore, most enterprises include a range of different applications, systems, and technology. Integrating products from different vendors with different platforms are almost troublesome. In order to alleviate such problems, architecture should provide a platform for building application services with the following characteristics: (iii) Loosely coupled (iv) Location transparent (v) Protocol independent To meet these characteristics, organizations are embarking on to use infrastructure strategy based on service oriented architecture (SOA). SOA uses services as building blocks with several different ways to organize and architect the application within an enterprise. Figure 2-5 depicts that SOA shifts IT from an application-centric (traditional approach) to service-centric (SOA).

38 22 Service1 Service2 Service3 Bus Service5 Service6 Service9 Figure 2.6 SOA shift IT from an application-centric to service centric. Differences between SOA and Object-oriented Programming (OOP) which are the best way to well understanding SOA can be described as follows [29]. OOP principles introduce the best ways to structure the internals of a single software application. SOA presents the best ways to expose the capabilities of software applications to other applications. OOP enhances code reuse within a single application while, the motivations behind SOA are to allow software to become as agile as business requires it and enhance reuse across application boundaries Definition of Service Oriented Architecture (SOA) Service Oriented Architecture (SOA) is an approach for building distributed system that delivers services to end-user or other services. Indeed, SOA is an abstract idea and not a concrete technology. The key terms to describe a SOA are [3]: A service: It is a repeatable business task that is defined and implementation independent. Service can be invoked by end-user or other services. For example, check customer credit card or open a new account. Service orientation: An approach to integrate business processes as linked services and the outcomes that they bring. Service Oriented Architecture (SOA): different things to various individuals depend on their role and context of business, implementation,

39 23 architecture, and operational. In perspective of an architectural, SOA is an architectural style that supports service orientation. A composite application: it is a set of related and integrated services that are composed with each other to support a business process of a SOA. IBM introduced a Service Oriented Architecture Stacks [5]. However, it can be contentious issue but it is just a useful framework for structuring the SOA discussion. It has been categorized into functional and quality of service. Figure 2-6 shows all elements that must be considered in a SOA. Figure 2.7 Elements of a SOA Stacks Presented by IBM This architecture stack is divided into two parts, functions and quality of service that each has some elements. These elements are described in detail as follow: Function aspect includes: Transport: It is a mechanism used to move request from service consumer to service provider and transfer respond from service provider to service consumer.

40 24 Service Communication Protocol: it is a contract between service provider and service consumer that what should be requested and what should be answered. Service Description: it is an agreed schema for describing service refers to WSDL that will be described later. That mean, how it should be invoked and what data must be requested and so on. Service: It is a service to use. Business Process: Set of roles and perspectives of business to meet business requirement. Service Registry: refers to UDDI that will be described later. Quality of service aspects include: Policy: it is a set of roles and conditions that service provider determines for service consumers and have aspects that refer to both functional and quality of services. Security: it is a set of roles that should be applied to authentication, authorization, and access control of the service consumer. Transaction: it is a set of attribute that should be applied to a group of services to accomplish a task. Management: it is a set of attribute that might be applied to managing all services and interactions Basic components of a SOA At the most basic situation, it consists of three components: 1. Service provider: it creates a service and publishes its interface and access information to the service registry. Each provider has to determine the category of services and what type of service partners are required to use

41 25 the service. Provider must determine the cost and what services should be exposed. 2. Service consumer: an application or service that finds available services from service registry and then try to bind to and invoke defined services in service provider. According to [5], The service consumer executes the service according to the interface contract. 3. Service registry: provides an interface for service and implement access information available to consumer. Each component can be considered as each others, for example service provider need a service to perform some task and invoke another service. Indeed, the provider also can be as a consumer. There are two specific kind of service provider such as Service Locator and Service Broker that can act as a registry and pass service request to one or more additional service provider. Figure 2.8 shows the operations that each component can perform. Service Registry Discover 2 1 Publish Service Consumer 3 Invoke Request/Respon Service Provider Figure 2.8 SOA components and operations The service provider does not necessarily know what their service will be used for, but instead provides the UDDI description of the functionality, the WSDL description of the interface, and the service contract to potential consumers. Consumers can call individual services or combine the services using orchestration to meet complex requirements in their own system [14].

42 Enterprise Service Bus Enterprise Service Bus (ESB) is an important software infrastructure for SOA that allows disparate applications to communicate via standards-based and port-level communication [32]. It allows the service communicate with each other via different protocols such as UDP and HTTP. One of the most useful features of an ESB is the ability to convert XML-based data from one format to another when routing it from one endpoint to another. This can be done via Extensible Style-sheet Language Transformations (XSLTs)[33]. Figure 2.9 Enterprise Service Bus (ESB) According to [14], One of the most important features of an ESB is the configuration file that maps the services, endpoints, applications and XSLTs on the bus. The ESB configuration file is used to map incoming data to consumers of the data. The ESB recognizes the form of the data and uses the corresponding XSLT to convert the data from one form to another before sending it to the consumer. This automatic processing enables applications to publish their data in a format such as XML and have it consumed by other users in the format that these users expect. Figure 2.9 depicts an example how ESB can convert XML data into the Keyhole Markup Language (KML) used by Google Earth [24].

43 Understanding Enterprise SOA (ESOA) An enterprise refers to any organization, or collection of organizations with a common set of goals and investment into IT. An enterprise is collection of various set of software, hardware, and people. Integration of applications is not new and many technologies and approaches have been used for integration before. SOA is the latest solution that enterprises, vendors, and developers are using for integration. Enterprise SOA (ESOA) is a blueprint for an adaptable, flexible, and open IT architecture for developing enterprise Web Services-based that derives from various set of Web Services combined with business logic to support a particular business process. In this perspective, SOA is a style of design that leads all aspects of creating and using business services throughout their lifecycle [2]. In practice, ESOA means different things to different people. As an IT Architect, ESOA means the overall enterprise architecture definition and the process that enables IT to develop and deploy business capability rapidly. For the CIO, ESOA is the IT strategy for delivering business capability. SOA usually is as a particular component within an organization and is placed as a Services Tier (Services layer or Enterprise Services Bus) in Enterprise Software Architecture Three Layers [23]. Figure 2.10 depicts an ESOA framework that shows how a services layer is conceptually placed within software architecture. As Figure 2.10 shows, the Application Tier is set of mixed bag of systems that play host to a wealth of intellectual property developed over many years such as CRM, ERP, EAI, custom build, legacy etc. The Business Process Tier executes orchestration/execution of business functions likes BPM.

44 28 Figure 2.10 An ESOA framework presented by [23]. The Services Tier contains governance, security and management functions for services. In this layer Composite refers to individual business processes for example Create New Account and Business category refer to business processes such as Perform Credit Check. System category wraps technical processes (Get user details from Database). In the enterprise, SOA is a necessary path for achieving systems integration and, a supporting infrastructure will be required to demarcate point between Web Services enablement and SOA enablement. In fact, an ESOA encompasses a complete infrastructure composed of various software and hardware components that understanding its requirements for assembling such an infrastructure is important. According to [12], as Figure 2.11 illustrates the author has presented the emerging ESOA infrastructure that can be considered to map an organization s business needs. At first sight, it may appear complex but all the components presented are not always needed, especially in the initial adoption stages. A single solution or server can therefore encompass several parts of the infrastructure. Finally, several components can be custom-made or purchased as off-the-shelf products.

45 29 Figure 2.11 The emerging ESOA infrastructure Each enterprise has its technical environment with specific requirements, and depending on how a service-oriented architecture is being designed and positioned as part of a long-term evolutionary cycle, not all components presented above may actually be required as part of the final infrastructure. However, it is important to consider the potential scope and magnitude of a true SOA enterprise infrastructure in order to ensure that all requirements [12]. In order to successfully utilize SOA on an enterprise level several additional aspects should be considered. All interfaces must be defined and stable clearly and use global data types. Loose coupling and reliability should be considered for service consumers and technically different definitions of semantically identical information that are cause for unnecessary transformations must be avoided. In order to establish additional reliability, all services must follow clearly defined communication and behavioral patterns [56].

46 The ESOA development lifecycle This stage provides details on SOA developments lifecycle as illustrated in Figure 2.12 [56]. The first stage of SOA development lifecycle is defining business requirement in order to understand what the enterprise needs. This includes specifying actual process, required services, user interfaces, and required security protection for the ESOA. When this definition is complete, you need to check your requirements against the existing services to identify missing services. Figure 2.12 The ESOA development lifecycle presented by SAP Secondly, new service should be provided and can be separated into three different phases. In this phase services are modeled to define business context and business semantics of the services. This includes pointing out relationships between the involved services, defining communication patterns, etc. Next, the exact definitions of the services from the created models are provided. Based on the business semantics the service signatures are defined. Once definitions are complete, appropriate functionality is needed to implement.

47 31 The next step is Discovery & Description. This includes adding documentation for services and publishing them to a services registry. Finally, consuming applications is latest phase of lifecycle. 2.7 S3: A Service-Oriented Reference Architecture In order to design an architectural framework with interconnected architectures, transformation capabilities and reusability IBM presented Service Oriented Reference Architecture (S3) [63] which is a high-level SOA model that shows the conceptual building blocks of an SOA solution, and the relationship between them. Each layer represent different business value perspective and they are significantly separate business. S3 can be used as a basis for specific solution models, and also for models of larger SOA systems such as ESOA. The architect can easily create an SOA in concert with methods such as Service- Oriented Modeling and Architecture (SOMA) [64]. Each layer has a logical and physical aspect. The logical aspect includes all the architectural building blocks, design decisions, options, and key performance indicators and so on while the physical aspect covers the realization of each logical aspect using technology and products [63]. This section will focus on logical aspect of the S3. As shown in Figure 2.13, the first five layers contain building blocks whose purposes relate to business functionality. They support each other in a hierarchy, although its layering is not strict. The rest of layers support the layers related to business functionality, but do not support each other in a strictly layered hierarchy.

48 32 Figure 2.13 Logical layers in Service Oriented Reference Architecture Operational Systems Layer The building blocks in this layer are all application asset that running in an operating environment to supports business activity. This layer consists of existing application software systems and data of the enterprise. For example, a bank might have building blocks such as customer relations management (CRM), customer database, internal accounting, and settlement in this layer. These applications functions themselves are the target of the service consumer s request. They include: Applications and data stores with functionality required to deliver the service functionality in the Service Layer; and Infrastructure programs such as operating systems, database management systems, and runtime environments.

49 Service Component Layer This layer contains programs, other than the programs in the operational systems layer that help to perform services. Service components are used as intermediaries to expose existing application functions for those applications that cannot be directly exposed. The building blocks in this layer include: Programs that wrap the programs in the operational systems layer to create services; Programs that are written to perform services and deliver the service functionality themselves; and Groups of such programs. The Service Component Layer enables IT flexibility by strengthening decoupling in the system. Decoupling is achieved by hiding volatile implementation details from consumers. As well as insulating consumers from the service implementation, a service component provides a point at which compliance with the service contract can be monitored or enforced Services Layer This layer contains all the services defined within the ESOA. Each service conforms to a specification that provides sufficient detail to enable a consumer to invoke the functions exposed by the service provider. This is the central layer of the model. Its building blocks support the basic service feature of SOA. Examples of portfolio services, in a banking context, might be identify eligible customer account, validate transfer, submit transfer, move funds, and complete transfer. Portfolio services can be composed of other portfolio services. For example, move funds might be composed of other portfolio services including move funds

50 34 from source and move funds into destination. In an enterprise architecture development, in contrast to a solution design, you are likely to be dealing with groups of related services rather than individual services. An example of such a group might be funds transfer services. The building blocks in this layer include: The portfolio services themselves; Compositions in which portfolio services are composed of other portfolio services; Groups of services and compositions covering functional areas; Data created or used by the portfolio services; and Service descriptions, contracts, and policies Business Process Layer This layer contains the composite services that analog for significant business processes. An example might be transfer funds. Business processes can be composed of other business processes and of portfolio services. For example, transfer funds might be composed of other business processes including create transfer and process transfer. By using technologies such as Web Services for Business Process Execution Language (WS-BPEL), organizations can assemble business processes just by modeling and manipulating a graphical depiction of process flow. The lowest layer typically includes business processes that are composed of portfolio services. For example, create transfer might be composed of portfolio services including submit transfer and move funds. The building blocks in this layer include: The business processes themselves;

51 35 Compositions in which business processes are composed of other business processes and of portfolio services; and Information created or used by the business processes Consumer Layer This layer handles interaction with the user or programs in the SOA environment. It includes users of the system and the programs by which they interface to the portfolio services such as customer and on-line banking portal. S3 is particularly suitable for adopting proven front-end access mechanisms, such as portals, and open standards, such as Web Services for Remote Portlets (WSRP), and technology, such as AJAX. AJAX exchanges XML over HTTP without the need for refreshing. Building blocks in this layer include: People, organizations and programs that take part in the business processes (the consumers); Interface programs that present information to and accept information from the consumers, such as channels, portals, other human-computer interface programs, format converters, and interface configuration programs; Data used by the interface programs, such as user profiles and interface configurations Integration Layer This layer includes building blocks that able to mediate, route, and transport service request from customer to the correct service provider. It gives the ability to decouple service providers and consumers as shown in Figure 2.14 [63], which adds

52 36 flexibility to the architecture and enable organization to integrate disparate systems into new solutions. Figure 2.14 Interactions in the integration layer The messaging, message and protocol transformation, complex event processing, service composition and service discovery features of SOA are supported by building blocks in this layer Quality of Service Layer Due to nature of SOA, existing QoS concerns exacerbate. Increased virtualization, loose coupling, widespread use of XML, the composition of federated services, heterogeneous computing infrastructures, decentralized service-level agreements, and so on; create complications for QoS that clearly require attention in any SOA. This layer includes building blocks that monitor and manage the quality of service of the architected system, including its performance, security, and manageability. The message monitoring, message control and message security

53 37 features of SOA are supported by building blocks in this layer. The layer also includes building blocks such as performance managers, security managers, and configuration managers Information Layer This layer contains building blocks to transfer and manage data. The message transformation feature of SOA is supported by building blocks in this layer. The layer also includes building blocks such as: Information models; Vocabularies; Data models; Data representation models; Programs that expose data as services; Data search engines; Data mining engines; and Document management systems Governance Layer This layer tightly connected to QoS layer and contains building blocks for implementing and operating governance. The layer includes building blocks such as: Governance rules and procedures; and Services and programs that support the application of the rules and the operation of the procedures.

54 38 Security enabling guidelines for composite application 2.8 Service Oriented Modeling and architecture (SOMA) SOMA [78] is a software development life cycle method to provide and develop SOA based approach. It defines technical keys and rules for developing SOA project and a work breakdown structure (WBS). The WBS contains tasks, the input and output work products for tasks, and the Law based guidance needed for detailed analysis, design, implementation, and deployment of services, components, and flows needed to build a robust and reusable SOA environment. The SOMA method contains of seven phase as shown in Figure Due to method component capability SOMA has fractal software development life cycle. Figure 2.15 SOMA phases a fractal model of software development.

55 39 Each phase in this fractal model will comprise of capabilities that can be used by other phases. Governance is considered as a background of service oriented life cycle. SOMA support two main aspects of governance: design-time and runtime governance [79]. Those fractal phases are not linear and they can be applied in an iterative, risk-driven, and incremental manner. Fractal approach is combined of two principles: the application of method tasks to self-similar scope that must be done in similar ways and successive iteration. SOMA is composed of capability pattern that can be executed in all phase in SOMA with different degree of production and accuracy. According to [78], Successive iteration is connected with the notion of service evolution and implies a focus on not only the risks associated with the implementation, but also with the dependencies associated with the service portfolio as services evolve through the life cycle. The notion of service dependencies on other services, and potentially other dependencies on actual back-end systems, databases, and components, must be called out. Therefore, a prioritization of the service model based on a service-dependency diagram is conducted. Figure 2.16 SOMA Life-cycle high-level flow

56 40 Figure 2.16 shows the high-level flow of SOMA life-cycle that illustrates a typical process flow of executing SOMA method. In the following the identification, specification, and realization phases are described Business modeling and transformation The modeling, simulating, and optimizing of business is provided in this phase and a most important part for transformation is identified. This phase is not quite needed but is recommended Solution management SOA solution contains multiple solution types because it is hybrid in nature. The identified and specified services can be realized in subsequent phases of SOMA by different scenarios, such as custom development, legacy integration and transformation, and package application integration. SOMA is intended to support the hybrid nature of SOA solution that advices specific activities and instructions to implement each of those solution types. The common method content of all SOA solution types is separated from the variable method content that is dependent on specific solution types. The variable method content tasks, work products, roles, and guidance specific to each of the solution types is defined and externalized as a method template called a solution template. Once realization decisions for the services are made, the solution types needed to build an SOA solution for a client is discovered and selected.

57 Identification phase The identification phase is belonged to identification of three fundamental concept of SOA including services, components, and flows. It is a best practice to take advantage of a set of complementary service identification techniques. Single technique leads to create an imperfect set of services which impacts release planning and, ultimately, project delivery. Service refactoring and rationalization opportunistically can filter out the business capabilities that will be exposed as services within the scope of the project. Business goal that is known as goal-service modeling (GSM) aligns IT execution with business drivers, imperatives, and objectives as well as monitoring and managing the scope of further business-process modeling and existing asset analysis. SOMA identification is a process of identifying candidate services when the process of assessing existing functionality to see if it can be placed in the service model, and by determining missing IT capabilities that will be needed to support the alignment of business strategy, goals, and processes. Service identification contains three main techniques: Goal Service Modeling (GSM), domain decomposition, and existing asset analysis. GSM uses an approach that is based on business challenges and opportunities, corporate strategy, and business goals. Domain decomposition uses a top-down analysis technique that is focused on business process modeling, rules, information, and variation-oriented analysis. Asset analysis uses an approach to identify which assets of legacy applications can be fit with identified service and requirements in GSM and Domain Decomposition Specification phase In this phase, the high-level design and significant part of detailed design of service component is completed. This phase is used for designing SOA. During the specification phase, the existing assets are leveraged. The service model is used for

58 42 service dependencies, flows and composition, events, rules and policies, operations, messages, nonfunctional requirements, and state management decisions. The two foundational and preparatory activities should be performed before the specification of the services, flows, and subsystems (component boundaries): Information models Fine-grained analysis and specification of existing assets. The high level structure and relationships of business entities are identified during the identification phase. The elaboration of the conceptual data model into a logical data model should be completed to populate the attributes to be implemented, which must be defined in terms of their domains or logical data types (e.g., character, number, date, and picture). In this phase, the service messages which include input, output, and error messages must be designed. In the service layer for getting rid of multiple data transformations, a best practice is to use a common message model that is accepted by the enterprise. The massage flow is defined via this model in the services layer. In the canonical message model, the message format (e.g., Extensible Markup Language or fixed-length record) is described and the set of types, elements, and attributes representing the business entities and their business attributes are defined. The message types are used as building blocks for input, output, and error messages for the services [78]. The leveraging of existing assets through re-factoring and mapping to services is a key aspect of service orientation Realization phase In this phase, the realization decisions should be validated. The technical feasibility is considered in this phase. Selection and instantiation of patterns is fundamental to successful and repeatable SOA deployment. The corresponding pattern categories is selected to manage several problem domains including information service patterns for information realization [80], enterprise service bus (ESB) patterns for integration scenarios, and rule patterns [81] for rule realization.

59 Implementation and deployment, monitoring, and management phases In the implementation phase, service, functional, and technical components that realize services, components, and flows are constructed, generated, and assembled. Creating necessary wrappers or other mechanism by which an existing component can participate in realizing a service is performed in this phase. In some cases, existing assets are re-factored and refined so that they can be used to realize a service. The unit, integration, and system testing for services, components, and flows are performed. The deployment, monitoring, and management phase focus on packaging, provisioning, executing user-acceptance testing, and deployment of services in the production environment. 2.9 Understanding SOA security SOA is a new approach to make widespread integration of diverse IT applications in an enterprise easier and cheaper than before. Therefore, all the security issues that are presented in integration will be presented in SOA as well but, security in SOA is more complex than traditional IT application security. Security management in IT involves network security, platform security and application security. Indeed, only those issues that are needed for application security can be considered for enhancing security in SOA. According to [3], in order to examining the security management in service-oriented environment, enterprise architects should consider the following items: All entities in SOA must have identities and decouple identities from applications. Flawlessly connect to other organizations on a real-time, transactional basis are needed. Proper security control must be applied for each service in composite applications.

60 44 Managing security across diver s environment in required. Protection of business data in transit and at rest Compliance with a growing set of regulations There are three security techniques for securing SOA as follows [1]: Applying security at the message level SOA is a collection of loosely coupled services available in the Word Wide Web and SOAP message exchange is one of the core services required for system integration in SOA environments. These messages may carry vital information within the SOA system [4]. Current applications rely on network layer to secure data that works well for point-to-point message exchange such as Secure Socket Layer (SSL). Indeed, the point-to-point security cannot be adequate for integrating systems where various services derive from different domains. In order to clarify the matter, the following example is illustrated. As Figure 2.17 depicts, John as a customer of the ACME brokerage firm can pay for his order directory from his bank account. John sent his bank account information and secrecy keys by SOAP message to ACME brokerage and this firm uses his account information to transfer money from john account to their account. Perhaps he uses HTTPS to transmit the information. As his HTTPS connection is with the ACME application and not with the bank application, the ACME gets to see his account information. The ACME firm can reuse the information for making additional orders without his permission. Even if the firm be trustable, there is no guarantee that the ACME application handles information securely. For example, the ACME application may store account information in a database that is not well secured against attacks by hackers. Note in this case, ACME brokerage firm knows every thing about john s bank account and an administrator at ACME maybe able to misuse this information.

61 45 In order to rectify this problem, hiding portions of message could be suitable to secure vital information. For example, the account information such as account number, password and key number can be secured as separate part of message within the message. In such situation, nobody can read and use information except bank application. Of course, this information should not be usable more than once to prevent the ACME from simply replaying (rewriting attack [4]) them. Figure 2.17 The different envelope can be placed inside the main envelope In order to ensure the integrity and confidentiality of SOAP message some standards which are used in SOAP message level need to be followed [7]. Message level security provides end-to-end security where as network level security can only provide point-to-point security. WS-Security [44] specifies how SOAP can be extended in secure manner. WS-Security can be used to carry identity information such as usernames and passwords, Kerberos tickets and digital signatures. It can used to encrypt different portion of a message and holds the signatures on different parts of a message, made by different parties involved in a message exchange.

62 Converting Security into a Service Currently, applications rely on their own custom solutions for security issues and have their own user/password stores, resource, activity, and perhaps even internal system status. It could be useful when application assumes that is used by itself and not when the application is integrated with others. In such case, a corporate LDAP [54] directory represents centralization of security enforcement. LDAP directories offer authentication as a service and do not provide everything that a security service should provide in an integration context. For example: LDAP needs the application to obtain and forward credentials from the user. Sending user name and password to other applications is dangerous because some enterprise applications are hosted by external Application Service Providers (ASP) and others are hosted by partners or vendors. If an application using role based access control, the set of roles recognized by the application may not be enough to recognize what a user can do with what a partner. LDAP cannot support other security aspects such as data confidentiality and data integrity. In order to alleviate this problem, a security service can be offered to enterprise that able to authenticate, authorize, encrypt/decrypt messages, and sign messages/verify signatures, log messages and scrub messages to protect applications against known and unknown vulnerabilities. It can decrease the cost of developing, auditing and managing security in each business application (or service). Figure 2.18 shows one of the possible ways in which a security service can work. Security service is not a part of any application. Its security model includes business needs and allows to developers of business services just focus on business logic. As Figure 2.19 shows security service can be implemented as part of Enterprise Service Bus (ESB). This approach alleviates the problems that come from hard-coded security models into applications. There are several technologies that can be used to implement security as service such as Security Assertion Markup Language (SAML) [43], WS-Trust [49], WS-Addressing [55], and Application- Oriented Networking (AON).

63 47 Figure 2.18 One of the possible ways in which a security service can work Figure 2.19 Security service can be implemented as part of ESB.

64 Declarative and Policy-based Security Policy-driven security is a new approach that is evolving to address nonfunctional needs of SOA security solutions such as interoperability, manageability, and ease of development. Security requirements and mechanisms must not be hard-wired into applications. Instead, they should be declared separately as a security policy. security policy separates security logic from business logic and ensure consistency of security enforcement across multiple applications. In order to achieve the business goals through IT in an auditable manner, security policies must be factored as a part of the application life cycle. WS-SecurityPolicy [52] standard can be used to implement this new approach across applications Related works SOA Security Framework for Network Centric Environment As mentioned before in section 2.2, security can be divided in content, communication and network levels. According to the aforementioned levels, Catharina Candolin has presented a security framework for SOA [62] based on network security architecture as Figure 2.20 depicts. In this framework security standards are placed in content layer. They provide means for authentication, access control, policy management, and key management. Confidentiality is traditionally ensured by encrypting the communication. Content based information security (CBIS) ensures protecting the data from its origin. Access control is handled through key management; only authorized users have the cryptographic keys necessary to access the non-encrypted content. Availability is a difficult concept. There are two types of availability classes: the availability of network resources and the availability of the service. The

65 49 availability can be ensured on the network layer by Packet Level Authentication (PLA) architecture. Packet Level Authentication (PLA) adds an extension header to the IP(v6) stack that contains a cryptographic key signed by a given trusted third party, a sequence number, time stamp, validity time of the packet and a signature over the whole packet (except changing fields). The PLA header enables every node recognizes duplicated IP packets from the origin to the destination. It protects networks against denial-of-service attacks. Figure 2.20 Security framework for SOA presented by Catharina Candolin According to [62], privacy encompasses all levels of network and is divided into several classes: data privacy which is defined with integrity and confidentiality of content level, identity privacy, location privacy, existence privacy, transaction privacy, and time privacy. Ensuring privacy is typically built into other security services, such as encryption schemes, network design, cryptographic key management, network utilization, and so on. In this framework, transport security relies on communication level of security such as SSL/TLS and SSH.

66 IBM SOA Security Reference Model The IBM SOA Security Reference Model [3] as shown in Figure 2.21 comes from a set of requirements that are divided into three main layers: Business Security Services, IT Security Services, and Security Policy Management. The Security Enablers Services provide security function for IT Security Services. Figure 2.21 IBM Security Reference Model The main features of the model are: Business Security Services, which describe security from a business point of view. IT Security Services, which provide a common set of services for use by different components in the environment. Security Policy Management, outlining the important aspects around the life cycle and implementation of security policy. Security Enablers, providing the supporting security technology and function for use by the IT Security Services.

67 SOA Infrastructure Reference Model Figure 2.22 shows the SOA Infrastructure Reference Model [20]. This reference model focus on concepts, components, and standard that are needed to build an enterprise SOA-based. It is divided into two main layers; an application and message layer, and an infrastructure layer. This separation of these layers is vital to ensure the true loose-coupling of service and applications within a boundary. Figure 2.22 SOA Infrastructure Reference Model This reference model has been published by SOA Software into the public domain. The definition of these two layers is explained as following: Application and messaging layer: consist of services, applications, and messaging platforms such as Application Servers, Enterprise Service Bus (ESB), and Business Process Management engines. In this layer applications and services expose their interfaces that other services and

68 52 application can focus only on the business logic instead of implementing service clients. Infrastructure layer: provides security, management, governance and monitoring services to the application and messaging layer. It ensures that adequate policies are enforced in service consumers and providers that send and receive messages. In this reference model, the security service serves three goals; a token server, an authorization server, and a PKI certificate authority. This service support SAML assertion, WS-Trust, SAML, Kerberos, XACML, WS-Security, http basic, https certificates, X.509, and others as token formats. It can delegate authentication decisions to external systems like Microsoft Active Directory, CA SiteMinder, and IBM TAM Current ESOA security solutions and products Nowadays, in order to design and implement ESOA in secure manner developers use current approach and products that provided by various companies such as IBM, Microsoft, Oracle, SAP, TIBCO, and HP. Some of these providers introduced security solution with their products like IBM, Oracle, and SAP. Some of these solutions are presented as following SOA Software Solutions SOA Software [16] provides comprehensive implementation of SOA Infrastructure Reference Model [20] based on current standards. It provides intermediaries to deliver core infrastructure services to XML application. SOA Software is the leading provider of enterprise-class SOA management, security, and governance solutions. SOA Software s products contain:

69 Service Manager It provides a high-performance, scalable SOA Management solution. This product provides the security service as Policy Manager. It includes Management Server which provides the management application monitoring functions, Registry Manager, and Alert Manager Network Director Network Director provides mediation and tolerance capabilities, ensuring that services can be consumed by the widest possible range of applications. It implements and enforces policy for Service Manager. It includes a standalone proxy, in-container agents for most Java and.net application servers, and ESBs, and delegates in the form of client handlers and SDKs. It delivers comprehensive governance, security, monitoring, management, and mediation of Web services Partner Manager Partner Manager makes it easy for companies to securely publish B2B Web Services for their partners to consume. It provides a complete trading partner management, and service provisioning workflow solution. It uses service virtualization to securely extend internal services into partners networks SOLA According to [20], SOLA is a Mainframe Web services tool that allows CICS applications to easily, securely, and reliably expose and consume Web services

70 54 without impacting performance. It acts as a policy enforcement and implementation point for CICS Web services IBM SOA Security Solutions IBM (International Business Machines) [60] is one of the biggest and earliest pushers of SOA technology. They were at the root of several SOA standards and are eager to push the way that they think SOA should be. As mentioned before in section , IBM has presented an IBM SOA Security Reference Model [3] to develop security in SOA. In order to achieve an enterprise SOA-based in real world, IBM produces several tools and products such as WebSphere and Tivoli family. The brief description of them is provided as following: WebSphere Application Server [17]: is one of the industry's premier Java-based application platforms, integrating enterprise data and transactions for the dynamic e-business world. Each configuration available delivers a rich application deployment environment with application services that provide enhanced capabilities for transaction management, as well as the security, performance, availability, connectivity, and scalability expected from the WebSphere family of products [17]. The security standards and solution that WebSphere supports are WS-AtomicTransaction, WS-Addressing, standardized logging (JSR 47), WS-Security WSS 1.0, WS-I Security Profile, WS-I Basic Profile 1.1 Attachments support, JAXR 1.0 Java client API for accessing UDDI (Version 2 only), ebxml registries, and UDDI v3 Includes both the registry implementation and the client API library. IBM Tivoli security management solutions address two critical e- business challenges: automated identity management and security event management. The IBM Tivoli identity management solution helps organizations quickly realize return on investment by bringing users, systems, and applications online fast, while effectively managing users,

71 55 access rights, and privacy preferences throughout the identity life cycle. The IBM Tivoli security event management solution helps organizations actively monitor, correlate, and quickly respond to IT security incidents across their e-business Oracle SOA Security Solution Oracle [22] provides a SOA security and management solution that can externalize security outside of applications and Web Services. This solution can combine transport-level and application-level protection, and use a layered defense system. Oracle presented a holistic approach to protecting ESOA deployments, including an identity management infrastructure (Oracle Access Manager, Oracle Internet Directory, Oracle Identity Federation, Oracle Web Services Manager), development and deployment tools (Oracle Security Developer Tools (OSDT), Java Developer (Java Integrated Development Environment), Application Development Framework (ADF), and a secure, governance-aware runtime environment (Oracle Components for Java OC4J, including a UDDI registry). Oracle's strategy is to focus on well established standards such as SAML, essential for identity federation, identity propagation, and end-to-end security from the user s web browser all the way across SOA-based transactions involving multiple Web Services JBoss ESOA Platform The JBoss ESOA Platform [21] enables enterprise to handle business events, integrate services, optimize business performance, and automate business process. It is open source and standards-based SOA platform that can be used individually, together, or with third party components. In addition, this new architecture supports event management and even driven architecture (EDA) deployments.

72 56 According to [35], Thorbjørn Blixen-Finecke, chief architect at Cybercity said, The versatility of the platform allows us to use one development tool, technology and set of standards for many purposes. Also, applications deployed on the JBoss ESOA Platform can be monitored and controlled in a standardized way. It includes some open source middleware such as JBoss Enterprise Service Bus (ESB), JBoss jbpm, JBoss Rules and the JBoss Enterprise Application Platform. The benefit uses of JBoss are: Eliminate Manual Pain Points from your Business Processes Reduce Business Process Execution Error Create Better Customer Experiences Leading to Higher Customer Satisfaction Accelerate Business Execution and Improve Business Performance Increase Return on Existing IT Investment Enterprise-class Reliability and Scalability JBoss supports most Operating Systems such as Windows, UNIX, and Linux. It is interoperable with any JDBC-compliant database including IBM DB2, MySQL, Oracle Database, Microsoft SQL Server, and others. Furthermore, it support standards such as WS-Coordination 1.0, WS-Atomic Transaction 1.0, WS-Business Activity 1.0, SOAP 1.1, WS-Security, MTOM, WSDL 1.1, WS-Addressing 1.0, JAX-WS, UDDI 2.0, Java Management Extension (JMX) 1.2, and Full J2EE 1.4 compliance Vordel solution Vordel [14] is an XML network management company that provides enterprise-level hardware and software products to implement an ESOA. Vordel solutions include:

73 57 Performance: removal of XML processing bottlenecks Access Control: authenticate and authorize access to Web Services Policy Control: central command and control for SOA Policy XML Networking: XML data transformation, routing and acceleration Security: full protection against threats [18] such as XML Structural Attacks, XML content-level attacks, DTD-based attacks, HTTP GET parameters, SOAP attachments, and Brute force attacks. Monitoring: visibility of Web Services performance and usage Governance: gain control of SOA through central service management Some of the most important Vordel tools are presented as follow: Vordel XML Firewall An XML Firewall to provide threat protection for XML applications from malicious attack and unauthorized access. By blocking a wide range of attacks on XML applications, Vordel s XML Firewall shields XML applications and allows them to be deployed in safety and confidence Vordel XML Gateway The gateway delivers XML offload with data transformation, routing and acceleration. Vordel XML Gateway takes complex and processor-intensive tasks off application servers and executes them on a dedicated platform. This provides significant performance gains, and also frees up processing power on the application server which can then be dedicated to processing business logic rather than low-level XML tasks.

74 Vordel Policy Director Provides centralized policy management for networks of XML firewalls and XML gateways. Vordel Policy Directory can archive, version, reuse and migrate policies. This allows Vordel s customers to centrally manage all policies and to quickly and easily provision policies to existing or new gateways, and to manage the development and deployment lifecycle Vordel Reporter Vordel Reporter is a web-based reporting product to provide full visibility reporting on Web Service usage. Fine grained metrics reports customizable to meet the needs of engineers, Quality Assurance personnel and business users Vordel SOAP Box This is an advanced XML policy and performance testing tool. SOAP box simulates XML and SOAP traffic and provides visual feedback of processing results. This allows developers to test the performance, scalability, and security of Web Services while ensuring that new policies have been correctly deployed Policy Studio The Policy Studio is integral to Vordel 5 and provides an easy to use graphical tool with familiar full drag and drop functionality and property sheets which considerably simplify the task of creating simple to very complex policies. Its powerful and intuitive circuits metaphor interface allows for visualization of the

75 59 most sophisticated policies. The Policy Studio is available with both the Vordel Policy Director or standalone instances of Vordel XML Gateway Comparison of current solutions The overall results of comparative evaluation of approaches which were described in section 2.8 can be seen in table 2-1. This table shows current ESOA security solutions as well as a number of criteria. TABLE 2.1: The comparison of ESOA security solution Solution security factors and etc. SOA Software Oracle IBM JBUS Vordel non-rapudiation end-to-end security identity management Security Enablers SSL XML-encryption & XML-signature Ws-security Ws-federation Ws-security policy Ws-metadata exchange Ws-addressing WS-Coordination WS-Atomic Transaction WS-Business Activity WS-AtomicTransaction SAML LDAP Public key infrustructure system Active directory support Authentication/Autorization Third party security support Audit Firewall multi domain security regulator compliance censorship and credential mapping Distributed Security Enforcement standardized logging (JSR 47) Evaluation good medium strong weak Very weak

76 Summary Developing an ESOA security solution is not easy. All ideas and approaches that have been explained in this chapter with right implementation and deployment are needed to create a security solution. In summery, ESOA is a blueprint for an adaptable, flexible, and open IT architecture for developing enterprise Web Servicesbased. SOA uses services as building blocks with several different ways to organize and architect the application within an enterprise. Web Services are loosely coupled computing services that can reduce the complexity of building business applications, save costs, and enable new business models. Web Service can be discovered using UDDI [26] and used by other applications. Extensible Markup Language (XML) is the basic for Web Services. In order to achieve an ESOA, the Service Oriented Reference Architecture (S3) [63] helps to design an appropriate architectural framework with interconnected architectures, transformation capabilities and reusability for SOA-based environment. This is a high-level SOA model that shows the conceptual building blocks of an SOA solution, and the relationship between them. This architecture can create SOA in concert with methods such as Service- Oriented Modeling and Architecture (SOMA) [64]. There are three main approaches to secure SOA [1] such as message-level security, security as service, and Policy-driven security. Some standards and technologies have been developed to achieve these approaches such as XML Signature [41], XML Encryption [42], WS-Security [44], XKMS [47], SAML [43], and XACML [45]. In the end of this chapter, some ESOA infrastructures and frameworks such as IBM Security Reference Model [17], network based SOA security framework [62], and SOA Infrastructure Reference Model [20] have bee explained. Then, some security solutions and products such Vordel [34], Oracle [22], IBM, and SOA Software have been described.

77 3 RESEARCH METHODOLOGY CHAPTER 3 RESEARCH METHODOLOGY In this chapter, the methodology of the proposed framework is presented in principle. This includes the research procedure, the instrumentation, the assumptions and limitations, and the schedule of the research. 3.1 Research Design and Procedure This project has aimed to propose a logical security framework for ESOA. Thus, producing this framework needs some knowledge and investigation of existing approaches. The steps of this stage are as follows: Literature Review In this phase, some background on Information Security, Web Services, security standards and technology, Service Oriented Architecture (SOA), SOA security, and ESOA are studied. In addition, the survey of the current security solutions are classified, described, and evaluated. The purpose of this phase is to understand the basic concepts and current approaches for ESOA Security. Furthermore, the survey on secure ESOA and related issues to support security in ESOA is provided.

78 Analysis of Requirement In order to provide an appropriate security solution in an enterprise, an adequate investigation on security aspects is required. Investigating which security aspects can be used on which layers of Service Oriented Reference Architecture is an important issue. In this phase, the security requirements that are needed for protecting an enterprise (traditional approach and SOA approach) are verified. Then, this project examines whether the IBM security Reference Model and network based framework can support all those requirements. Finally, it evaluates these challenges in ESOA to propose security framework Design In this phase, based on the above requirements and other solutions, a conceptual security framework for an enterprise SOA-based is proposed. The components of this framework should support all security requirements that are needed for ESOA. However, some of these components can come from other solutions (IBM Security Reference Model and network based framework) but, this framework must propose security services for the rest of requirements. The Security Service Oriented Reference Architecture (SSORA) is designed based of proposed framework for supporting security in Service Oriented Reference Architecture. Then a Logical Deployment Architecture for ESOA is proposed Development In order to develop a secure SOA in an enterprise, the components of the proposed security framework should be applied on the proposed logical SOA deployment architecture. The developed security solution design can be used as reference security solution for every enterprise that follows the proposed logical deployment architecture.

79 Verification This project demonstrates that complete security solution design can be used for all SOA based environments. In order to show the capability of the proposed framework and the security solution design a case study such as Razavi Financial Institute (RFI) is proposed. This project analyzes this case study and figures out all security requirements needed for this case study. Then, it shows whether the complete security solution and the proposed security framework can support those requirements. In Figure 3-1, the steps of the research procedure is shown and Figure 3-2 shows the flow chart of the research activities. Liteerraat tuurree Reevvi ieew The survey on secure Enterprise SOA: in this step investigation of relevant research efforts are considered. The survey on related issues to security in Enterprise SOA: this step includes an investigation of the most related issues to support security in Enterprise SOA such as Web Service, SOA, and Enterprise SOA Annaal lyyssi iss oof f Reeqquui irreemeennt tss An investigation of state-of-the-art challenges in secure Enterprise SOA Deessi iggnn Propose a logical framework to support security in Enterprise SOA. Propose a Security Service Oriented Reference Architecture and propose a logical SOA deployment architecture. Deevveel looppmeennt t Applying security services of the proposed framework on the proposed logical SOA deployment architecture to provide a security solution design. Veerri ificcaat tioonn Demonstrate security solution design using a case study such as Razavi Financial Institute (RFI) Figure 3.1 Research Design and Procedure

80 64 START Literature reviews Project 1 publication Investigation of state-of-the-art Challenges in secure ESOA Design a security framework The logical secure ESOA framework Adapting the proposed logical deployment architecture with the proposed logical ESOA security framework Validation of the propose framework using a case study No Satisfactory results? Yes Writing up Dissemination of the research results END Figure 3.2 Research Flow Chart

81 Instrumentation In order to create a Web Service some tools and SOAP processing engine to pars the message are needed. These tools can parse the messages that they received and call the functions and methods that those messages need. There are many vendors that provide these processing and many of them provide other tools that can help developers to write the code needed simply. This project aims to use Apache Software Foundation s Axis product that is an academic product and WSO2 Web Services Framework/PHP (WSO2 WSF/PHP) for implementing RFI case study Security Web Services. Furthermore, NetBeans 6 is selected to provide all the Web Services in java and PHP. This project aims to use HTML and XML for providing web-based interface. In order to provide this interaction between the users and the services, Macromedia Dreamweaver application can be used. 3.3 Assumptions and Limitations An ESOA encompasses various kinds of services, hardware, and middleware. A security system for ESOA has to be based on different requirements and take into account specific limitation of data interaction. The following assumptions and limitations are made in this project: The network facilities (firewall, wire, hardware, and etc.) used in the system is fully reliable and ideal. This project does not attempt to deal with network unreliability or other quality of service issues about network. This project assumes all services and applications themselves are provided by appropriate security manner. This project only focuses on security

82 66 aspect in interaction and collaboration between services both within the enterprise and out of it. For the purpose of this project, all Web Service security standards and technologies are in place for providing Secure ESOA and focus on using current security standards and tools to propose a framework. This project assume the business functions of case study are ready and it just focuses on designing a security solution based on proposed logical deployment architecture and the proposed security framework. This project is not going to analyze and design the business requirements and functions of the case study.

83 The Gantt chart of Research Activities TASK Literature reviews Literature review on Secure ESOA Literature review on related issues such as SOA, ESOA, WS, and Security problems Year2008 Year2009 M1 M8 M8 M4 M5 M6 M7 M8 W1 W3 W3 W4 W1 W2 W3 W4 W1 W2 W3 W4 W1 W2 W3 W4 W1 W2 W3 W4 W1 W2 W3 W4 W1 W2 W3 W4 W3 W4 Analysis of requirements Investigation of state-of-the-art challenges on Security in ESOA Framework development The development of conceptual framework Adapting the proposed logical deployment architecture with the proposed logical ESOA security framework MI 1 MI 2 Experimentation using the prototype Validation of the framework using a case study to be applicable Documentation of the results Technology Transfer Activities Presentation of research results as a consequence of project 2 MI 3 Notes : M1,M2,M3 : Aug, Sept, Oct M4,M5,M6 : Nov, Dec, Jan M7,M8 : Feb, Mar : Progress : Milestone

84 Milestones and Dates The important expected milestones and their respective dates are given below: Milestone Description Date M1: Current challenges on Secure ESOA The results of the investigation of current ESOA Security challenges such as authorization, En-to-end security, Interoperability, Quality of Service (QoS), Auditing, Migration of Legacy Application, and so on. 18 Oct 2008 M2: The Proposed Conceptual Framework This framework will be developed based on security in Enterprise Service Oriented Architecture. 13 Dec 2008 M3: Dissemination of the research results The results of this project will be documented and presented. 31 Mar 2009

85 4 LOGICAL SECURITY FRAMEWORK FOR AN ESOA CHAPTER 4 LOGICAL ESOA SECURITY FRAMEWORK This chapter aims to analyze the security requirements raised by real world SOA in an enterprise and propose a logical architecture framework to meet these needs. First of all, the ESOA security requirements are described in section 4.1, then verifying which requirements are needed for each layer of Service Oriented Reference Architecture (S3) [63] is delineated. Next, according to the above requirements, Network based SOA security framework [62], and IBM Security Reference Model [3] a logical ESOA security framework is presented in section 0. After that, a new logical ESOA deployment architecture is proposed in section 4.4. Furthermore, by applying the proposed logical ESOA security framework on the proposed logical ESOA deployment architecture, a security solution design for ESOA is presented in section ESOA security requirements In order to ensure security in enterprise SOA-based, several requirements must be met to support Service Oriented References Architecture (S3) nine-layers. The security requirements of service oriented architectures both from the perspective of the user and the service architecture must be considered [62].

86 Identity An ESOA encompasses various entities contains of Applications, services, Hard wars, Messages, Orchestration, Service components, Enterprise Service Bus (ESB), Users, and Utilities that must be identified. These identities are used for authenticating, authorizing and auditing. Access to resource can differ from one identity to another identity. For instance, some services published in service registry should not be accessible for all service clients and should not be discovered. Thus, identity must be assigned for all clients, registries, and service providers. When a customer send a request to the service for doing a business process, the authority of the customer identity must be checked. After validation, in order to perform customer request, service may needs to generate request to an Enterprise Information Server (EIS), other services, an ESB, or an existing application directly or by service component. All of those applications or services might have their own security solutions and in some case, due to tight coupling of their functionality the new security policy enforcement might be difficult. For example, SQL Server has its security feature for authenticating and authorizing. Some of these applications communicate with other legacy applications to fulfill their processes. With respect of these issues, it is clear that an appropriate identity management, identity mapping and propagating is needed across boundary and applications. Identity mapping can achieved by two ways: one-to-one when back end system needs authenticate and audit using user identity- and administrative approach when back end system only requires a common administrative identity (perhaps the user s role) for authorization and auditing. It does not require knowing who the user is. In some cases where service uses partner applications that placed in other organization, identity mapping and propagating could be different and they often need user and administrator identity together. Other issues that should be considered are identity token format translation and identity provisioning. It is clear from the discussion so far that identity should be considered for all six first layers of S3. Federated Identity Management (FIM) is a solution for the

87 71 management of identities. Achieving single sign-on is the goal that distributed identities hope to achieve. This means that a service client only has to establish its identity once. With this identity, it will be authenticated and authorized to several sources without re-establishing its identity again Trust management In order to address the requirements of identity propagation, mapping, and provisioning, an adequate solution is required. One of the best solutions is establishing trust between entities [3]. Trust management service can be used for Managing trust relationship between business and system and a mechanism to create policies based on business drivers and influencing factors (such as trust and identity) and to distribute them in a consistent manner to all the relevant components within logical deployment architecture Authorization Authorization is needed for every component in line. For example, in an enterprise the proxy can implement service level authorization and ESB can implement an authorization to the data server. Data server provides authorization for sensitive data such as personality information. Service component implements operational authorization. In order to achieve an appropriate solution, a standard based approach is required to deal the authorization issues end-to-end. For instance, extensible Access Control System Markup Language (XACML) and WS-Authentication are standards to provide access control within a boundary [85][82]. The problem in ESOA is if a single system authorization is not set properly, the complete business process might be unusable and might introduce a new vulnerability that allows an attacker to

88 72 misuse the services. In order to ensure security a centralized and integrated authorization management is needed. An Identity Management framework could be placed in such issue [11] Audit Audit information is required to gather from every component along transaction path. This information can be used for future forensic review. In an enterprise every events such as log in, log out, authentication, authorization, identity mapping, and so on should be logged as audit information. In operational layer where existing application, back-ends, and other legacy applications are placed, auditing could be difficult because of their different implementation. Due to differing audit information format between these applications, an appropriate solution is needed to manage audit information along a boundary. Compliance and Reporting can be used as a solution that measures the performance of the business/it system relative to the measures established by the business controls and policies. These can be realized based on reporting on system behavior using audit log information and comparing those behaviors to defined policies. Generating audit events end-to-end for transactions, collates these into a common format, and allow real-time and post processing of events for reporting are needed. It is important to verify events when these events are compliant with policy [3][11] End-to-End Security Current security approach such as SSL encryption is not sufficient in ESOA. They only focus on the low level transport layer and message cannot be protected individually. In addition, enterprises that have communication with other firms to

89 73 complete a process cannot enforce security measures in partner s systems [11]. Thus, a security approach that is independent from the transfer channel is required. That means the data must itself remain protected, even when passed from one service to another beyond company boundaries. One of the best known approaches for Web Service messages is using the OASIS standard WS-Security. It provides confidentiality and integrity protection for messages by means of encryption and digital signatures and has a sufficient collaboration with SAML assertion [5] Privacy In an SOA environment where the sensitive information such as personality records has to transfer and recorded into the data server, protecting these data can be issued. Privacy is a decision to determine when, how, and how much information about individuals, groups, companies, and other entities is exposed and communicated to others. That is, privacy is the ability to control what information is disclosed to other parties and under which situation [66]. Privacy encompasses all levels of network and is divided into several classes: data privacy, identity privacy, location privacy, existence privacy, transaction privacy, and time privacy [62] Interoperability Interoperability is a focal point in ESOA. An enterprise with multiple systems may have several services that have been written in different programming languages and running on various application servers. Thus, a standard that those applications can work without high effort is needed. However, interoperability has been proven to be more difficult than anticipated initially. For instance, there are different implementations of the Enterprise Service Bus (such as provided by IBM, Microsoft,

90 74 Oracle, SAP, or TIBCO) that should be able work with other products. Without a standard, high integration efforts will remain [11] Secure Configuration Due to the accessibility of enterprise services via public networks their services may be exposed to increased threats. According to [11], By deploying an enterprise service, parts of these applications can now be reached from potentially hostile environments. The security configuration of services and their complete application framework is required. In order to configure security within an enterprise the clear and complete documentation of all relevant configuration settings and security functions that provided by the service provider or application vendor is needed. In addition, adequate training of the people who involved with system is mandatory. Using default security configuration usually not enough and regular security audits will be a key success factor for a continuous high security level [2] Availability In order to invoke a service, service consumer must be ensured that required service is available. According to [62], the availability of service may be difficult to ensure on the high level layer alone, so lower layer (such as the network layer) involvement may be required Quality of Service The quality of the services is a crucial issue in ESOA. Both service provider and service consumer need to consider the quality of the service. Service consumers want to ensure about service performance and they expect the service to be available

91 75 and to provide its business functionality in an acceptable time [11]. According to [57], for externally procured services, these factors can only be indirectly influenced via contractual service level agreements and a multi-vendor approach where multiple service providers with comparable services are integrated and can be easily exchanged with each other Secure Development Developing ESOA is not same in several aspects from traditional software development. A service must be easily reusable in various possibly antagonistic contexts; developers do not know how the service is going to be used. Certainly, this is not possible to developers that do not know any information about security of services. Indeed, all assumptions need to be made explicit by documenting them. Only then a service user can consider to use the service (or not) in a responsible way. As most developers are not security expert, they should always use existing security services provided by the runtime environment instead of designing new ones [58]. In order to increase security, developers must not introduce security bugs and flaws themselves. They should avoiding Buffer Overflows, using the appropriate authorization checks, development guidelines, and corresponding test cases Assurance An individual service security is obligatory but not enough for security a complete business process. This is true when an enterprise uses several external services and processes. Trust in a service and its provider needs to be provided by means of certifications and objective audits or reviews. A security certification program that describes and checks security requirements will be useful instead of existing standards such as Common Criteria [59] that are too complex and too inflexible.

92 Firewall Firewalls can be hardware or software which control all traffic (deny or permit traffic) from external organization to internal organization. It based on rules set up by the firewall administrator. SOA uses SSL and HTTP protocol to transfer message and those protocol use TCP port 80 and 443 that can pass through the firewall [65]. Therefore, additional security features have to be implemented to prevent possible threats. Once a message addressed by one component to another, the message gets split into several packets by the network. Each packet carries a part of message, the addressing information and other control fields such as source and destination IP address, Transport protocol, typically TCP or UDP. Network firewall filters one packet at a time based on the rules that developers have defined based on information available within a packet. Firewall rules can be used to block all packets except those that specifically are allowed to come in or go out of the internal network [1]. Firewall can be used around intermediary that exposes the service itself. There are many different types of firewalls including packet filters, state full filters, and application inspection. They can also perform functions, such as network address translation (NAT) [3]. [3] Service discovery In order to assure that the services provided are legitimate, the user should be able to authenticate the service discovery service. The service discovery also should be able to verify the authenticity of the user requesting a list of services and restrict the items seen on the list according to the authorization of the user. In addition, the service discovery must only list the services that have been verified as legitimated services [62].

93 Security policy Policy is document contains of guideline and rules which outlines what steps to take and what procedure must follow in the pursuit of security [69]. Security Policy Management provides the bridge between the Business and IT Security Services [3]. Two different types of security policies are defined [69]: Organizational security policy, which has rules and practices for management, protection and resource distribution of security objectives. System security policy, which defines how a computer system should be designed to support the organizational security requirements Physical security In an enterprise, existing applications keep into the various servers and equipments and they can be inside or outside a boundary. There are many stuff and people work in an enterprise such as Data Center. Thus, physical security policy and environmental security (guard, access control, and awareness) are required Time management Managing time during the collaborations and interactions is crucial. The operation time of each service must be estimated and a policy based service should decide that each security service must perform its operations in what amount of time. Time Management Service decides how many times an identity can be login without using system or service. This service has a nicely communication with the audit and the policy services.

94 Logical Security Framework As mentioned before in chapter two, SOA Security Framework for network centric environment [62] can be used as a reference to support security in an ESOA. This framework presents all security standard required for the communication and network levels. It relies on the Web Service security standards in order to provide security in the content level. This framework provides the privacy for all security levels and supports Multi level Security (MLS). The availability of the services and systems are ensured on both the content and network levels. However, this standard based framework can be used to develop the security in SOA-based environment but there are some limitations that the developers should conceder: i. This framework does not support the secure configuration requirement. ii. This framework does not support the infrastructure security requirements such as physical security, operating system security and so on. iii. This framework does not mention about the auditing that is very important in SOA. iv. There is no standard for the identity repository protection in this framework. The IBM SOA Security Reference Model [3] provides capability to support security in an ESOA. Currently, it is a best known reference model that can support the most security requirements for an enterprise. Regardless of the benefit of this reference, there are still some limitations that developers should take into account: i. Unlike the network based framework, this reference model only conceder privacy in content level and provide policy to protect sensitive data such as personal information, financial information and so on. ii. This framework does not support Multi Level Security (MLS).

95 79 Although, the combination of these two references can help to provide more secure SOA environment but still, there is a problem that should be issued: i. Both of these references do not support the time management that is required for an enterprise. With respect to these references, this project provides a framework to support all security requirements that derive from literature review. The components of this framework come from the IBM SOA Security Reference Model and the SOA Security Framework for network centric environment. The content level security is divided into to three layers; Content Security Services to provide end-to-end message security, Compliance, and Identity and Access Service that provide secure collaboration and interaction. The Infrastructure Security Services is considered to include the communication and network security levels. According to above references, the privacy and audit should encompass aforementioned layers. The Time Management Service is added to support time managing within interaction and the rest. Figure 4.1 depicts a new conceptual security framework for SOA environment that can meet the above security requirements for all layers of the Service Oriented Reference Architecture and their relationships. In this framework, some services are separated by two red boxes that are concerned with business security services and IT security services mentioned in the IBM Security Reference Model. According to [3], Business Security Services drive policies within an enterprise that need to be enforced in all relevant point within the infrastructure. Indeed, they address what security should be accomplished. IT Security Services are the building blocks that address how security functions can accomplish the policies defined in Business Security Services. The definition of each service is explained as following:

96 80 Figure 4.1 The Proposed Logical Security Framework for ESOA Content Security Services These security services are standard-based that provide end-to-end message level security. Confidentiality service encrypts and decrypts documents and provides secure storage to assure confidentiality. Integrity service provides signing document to assure messages integrity. WS-Security specification that is independent of the transport layer protocol (e.g. SSL) provides end-to-end message security (Figure 4.2). XML-Encryption, XML-Signature, and PKI can be used to assure document security.

97 81 Figure 4.2 End to End security in the SOA Compliance and Reporting This service measures IT system performance in terms of rules and metrics that defined in policy. It can extract information manually or automatically from Audit information in order to measure performance [3]. This service provides accountability. Compliance Service verifies performance against a set of internally policies and external laws or regulatory acts such as Basel II [70], Sarbanes-Oxley Act (SOX) [71], Gramm-Leach-Bliley Act (GLBA) [72], ISO/IEC (formerly ISO/IEC 17799) [73]. There are several products that can do this task: Tivoli Compliance Insight Manager (TCIM), SOA Software Compliance Management (SSCM), Oracle Identity Management, and so on Identity and Access Services Consistent Identity and Access Services that can be used by different components of SOA environment such as service consumer and provider, proxy servers, portal servers, application servers, and data servers are required. This set of services must be flexible and standard based. They provide managing, sharing,

98 82 federating, and accessing identity information from a variety of authoritative identity sources. The definitions of these services are explained as following: Identity and Access: this service provides policy for managing password and identity. It can include provisioning and de-provisioning identities and self-care/selfregistration for optimal user interaction. In addition, it can manage policies to access resource based on identity information and resource information. The life cycle of identity is vital and this service can manage identity lifecycle [3]. This service defines the requirements of the authorization policy that is the key input from the business. For example business can define that only the certain partners can access to the information. As the framework depicts this service belong to the Business Security Services. Identity Provisioning Service: this service is responsible for creating, managing, and deleting the accounts in the appropriate identity repositories across a boundary. In traditional applications users know their user names and passwords but in the SOA boundary users might not know their identities information in other repositories. Thus, automated provisioning is needed to manage identities. Standard based federated provisioning such as SPML and WS-provisioning can be used to enable collaboration between different technologies [3]. This service include directory integrator component. Directory integrator: different user repositories are placed in an enterprise. Directory integrator synchronizes those identity repositories for automatically updating identity information. Identity Propagation Service: this service manages identities relationship and mapping them for propagating identities across a trust domain. This service translates identity format and token standard to another format and standard. The Security Token Service can be used to perform this issue and identity mapping. As Figure 4.3 shows Security Token Service can bridge identity between two domains.

99 83 Figure 4.3 Identity propagation in the SOA Authentication Service: this service provides capability to authenticate an identity. It can validate user ID/password and user ID/passticket credentials. According to [3], this service should support multiple authentication mechanisms such as username/password, hardware token-based, or biometric-based. It should support protocols, such as Kerberos. Authentication Service also provides Federated Single Sign-On (FSSO) across the boundary. The standards can be used in this service are SAML, WS-Trust, PKI. Authorization Service: this service provides capability to decision about whether an identity is allowed to access a resource. In order to make a decision, policies are enforced by Policy Enforcement Point (PEP) that depends upon decision made by a Policy Decision Point (PDP). Authorization Service has two key points for decision: Authorization Policy and Authenticated User. Non-Repudiation Service: this service provides policy based action to proof of data origin and delivery. This service ensures the sender and recipient cannot falsely deny that they didn t sent or receive messages. In order to achieve this aim Non-Repudiation Service uses Confidentiality, Integrity, and Audit Services. As [3] said, the digital signature mechanism is commonly the principal implementation of non-repudiation service.

100 84 Availability Service: this service provides a response to a request in a timely manner. Ensuring that services are available when required is a key in many SOA environments. This service ensures two types of availability: Network resource availability Service availability The availability can be ensured in network layer that can be performed with Communication and Network Service by deploying the Packet Level Authentication (PLA) [75] Architecting for high availability includes application clustering, database clusters, and similar techniques [62]. Figure 4.4 shows an abstraction of all services in Identity and Access Services. Figure 4.4 Identity and Access Service framework Infrastructure Security Services Infrastructure Security Services provide communication and network levels security, operating system, data base, and front end security, security development,

101 85 and security configuration. They also provide physical security in each layer of reference architecture. The responsibility of each service is explained in detail as following: Communication and Network Level Security Service: this service is concerned with all security aspect related to communication and network levels of security architecture. On the MAC layer using link encryption and authentication. This service includes Packet Layer using Packet Level Authentication (PLA). Communication and Network Service support transport layer security by SSL/TLS, and SSH. It also provides Host Layer and IP layer security with Host Identity Protocol (HIP) and IPsec [62]. Physical Security: this service insures the physical security of infrastructure such as wire, rack, power, building, and so on. This layer also supports firewalls, Proxies, and Database connection. Intrusion Detection is placed in this service. Operating System and Database Service: this service provides the capability to protect operating system against unauthorized access and threats. It also provides database security, Virus detection, and host based intrusion detection. Front-end Service: front-end security is focal point of any enterprise to protect their application and data against malicious inputs and threats. This service provides input validation, output encoding, secure session handling, secure data replication Privacy Service According to [62] and [2], Privacy Service should support all security levels from the content level to the network level of security architecture. This service provides capability to protect sensitive information across all security levels. This service defines policies to classify sensitively of information for use in transit and at

102 86 rest. It can be accomplished through middleware, data encryption, hardware, and operation system (OS) [3]. This externalization can help to manage data protection. It has strongly relationship with Audit Service because when the sensitive data are acquired, Audit Service must record that event in detail Audit Service Audit Service Records every events across business process. Audit records form the basis of the raw data required for compliance assessments. An audit logging service provides mechanisms to submit, collect, persistently store, and report on audit data submitted as events. The events can be in a common format, such as Common Base Event (CBE) [76]. This service also provides capability to manage Audit data in Application layer where each application or data server has its audit mechanism. Centralization of audit can help to provide capability for investigating of events in future. As proposed framework shown, Audit Service has tightly relationship with other services Trust Management Service Trust Service provides trusted relationship between entities like organization, enterprise, security domains that can be business to business (B2B) and System to System (S2S) [3]. There are two approaches for managing trust: policy-based and reputation-based. Trust Management Service provides capability for an identity to pass through within boundary without authenticating repeatedly. In order to establish trust the request format should be changed to standard format such as WS-Trust.

103 Time Management Service This service provides the capability to manage time during the collaborations and interactions. This service provides the policy to control the operation time of each service and make decision that the security services must perform their operations in defined time. In an enterprise, some identities are only allowed to access resource in specific times, thus this service most control the access time according to their authority policy and audit information. In such case if the access time is over, the Time Management Service should limits the identity access and only operates the latest request that requester have sent to the SOA applications. After that, the identity access must be expired Security Policy Management Service Security Policy Management Service involves managing, articulating, enforcing, and monitoring security policies. It is able to define policies that can authenticate and authorize requesters to access services, propagate security context across service requests based on the trust model, audit events of meaning, and protect information. All of these are done based on a policy-based infrastructure. This service provides policy with common formats such as WS-Policy and XACML Governance and Risk Management Security Governance is a mechanism to implement and enforce security policies within an ESOA. An effective security Governance framework should be able to establish chains of responsibility, authority, and communication to give power people to control the system. SOA extends interactions beyond the enterprise, thus similar groups are needed to achieve a common set of standards for communication across the enterprise boundary.

104 88 Table 4.1 lists the security services that have discussed in framework and shows standards related to those services. Table 4.1: Security Services Standard Security Services Confidentiality and Integrity Services Identity provisioning and Identity propagation Services Authentication Service Authorization Service Compliance Service Non-repudiation Service Availability Service Audit Service Privacy Service Trust Management Security Policy Management Communication and Network Service Standards WS-security, S/MIME, XML-Signature, XML-Encryption, SAML Assertion, PKI, XKMS, WS-secureConversation, WS- SecurityPolicy, SSL/TLS SAML,WS-Federation, LDAP,APML WS-Provisioning, and Liberty WSS SAML token,x.509,pki, ws-trust, kerberos XACML, WS-Authorization, JACC, WS- Federation WS-secureconversation, SOX, GLBA,FISMA, HIPAA Digital Signature Mechanism PLA CBE, CEI,WEF, WS-BaseNotification WS-Privacy WS-trust Ws-securitypolicy, ws-policy, XKMS SSL/TLS, SSH, GSS, HIP, IPsec, IKE, PLA

105 Security Service Oriented Reference Architecture (SSORA) Service Oriented Reference Architecture (s3) can be used as a basis for specific solution models, and also for models of larger SOA systems such as ESOA. Figure 4.5 The six main layers of Service Oriented Reference Architecture As Figure 4.5 shows from up to down approach, service consumers can provide requests for services directly or alternatively. They start a business process that called service. Services are described with service definition. Service components are used as intermediaries to expose existing application functions for those applications that cannot be directly exposed. The proposed logical framework can be applied on Service Oriented Reference Architecture (S3) in order to insure security for each layer. Client is authenticated at the consumer layer as defined identity. The customer layer determines if the user is authorized to access the service layer or business layer. If so, the request and identity are propagated to service provider. All events should be registered as Audit information to verifying performance of consumer layer according to the policy. This information should be stored in audit storage and must

106 90 be applied for all layers. Trust service is needed to establish trust relationship between layers to avoid sign in repeatedly. All messages during transformation should be protected and confidentiality, integrity, and privacy of message should be assured. The availability of the service must be assured. Service consumer and business process layer should be able to access to the correct service in an exact time. The federated identity provisioning and appropriate identity integrator are required for all layers. Security infrastructure encompasses almost all layers. Security infrastructure is concerned with all aspect of security development, communication and network security, firewall, intrusion detection, and physical security. Operation layer is the last layer of S3 nine-layers where consumer goals to access the application functions to perform its needs. There is no resource or layer after operation layer that the applications in this layer want to access it. Thus, there is no reason to map identities in this layer even if the applications have communication with each other. For instance, the existing application may need to connect to the data server but their relationship is defined based on traditional approach. According to the proposed security framework and security requirements for Service Oriented Reference Model (S3), a new Security Service Oriented Reference Architecture (SSORA) is proposed. In order to get a good grasp of this architecture a 3D architecture as shown in Figure 4.6 is designed. The first six main layers (consumer, business process, service, service component, operational, and ESB layer) are placed in top of this architecture and then the relevant security services for those layers are designed respectively.

107 91 Figure 4.6 The proposed Security Service Oriented Reference Architecture (SSORA) 4.4 Logical Security Deployment Architecture of ESOA This section provides exact location of each entity of the ESOA that relevant with the S3-nine layers and SSORA. Location is a focal point of the design of a SOA security solution for ESOA [1]. Designer of enterprise solution should consider the impact of location in multiple ways: In the public network when users are going to access to the applications over the internet. The solution must take into account the fact that unauthorized users can potentially attack servers that hosting public services. Some of the entities are not fixed into the solution and designer has to break them into several entities. There may be several instances of same logical entity that must be located in different location in order to enhance performance and availability [1].

108 92 When an entity is broken into several entities to be located in several locations, the solution might be complex and needs redundant deployment. For example deploying several credential stores. In the real world, there are four main high level locations [1]: Enterprise Partners Managed service provider Public at large These locations are not atomic. They might be divided into multiple locations for example an enterprise may be divided into several regions and each region includes datacenters, headquarters, branches, and so on. With the intention to increase security the backup of datacenter might be located in other place either inside or outside the enterprise. In order to offer services to the partners and public and invoke services from managed service providers, the appropriate security solution and design is required. Based on the IBM typical logical deployment architecture for SOA [3], in most situations, there is a proxy (HTTP or Web Services gateway) deployed in the demilitarized zone (DMZ) in front of either a Web application server or portal server. The Web application or portal server leverages existing applications/services either directly or through an ESB that can be either internal or external. Service Consumer can be users or service both internal and external. Figure 4.7 shows typical logical deployment architecture for an SOA application presented by IBM. Figure 4.7 IBM Typical logical deployment architecture for an SOA application

109 93 Demilitarized Zone (DMZ) is a neutral computer host or small network environment between the private network and the public network. It provides security against unauthorized users that plan to directly access to the enterprise information or networks. A DMZ is an optional approach to prevent private network and more secure than using firewall lonely [88]. Users of the public and in some situation even internal users only can access the DMZ host. Based on the three scenarios presented by [1] and [2] The DMZ may also have the enterprise Web pages and Web Services that are served to outside world either public users or partners. As Service Oriented Reference Architecture (S3) illustrates, a service can directly access to the existing application or via the intermediaries such as service components. Service can access to the resources via Enterprise Service Bus (ESB). Thus, several connections may need to connect to the resources within the private network. A number of holes are needed for these connections on inner firewall that cause it vulnerable. In order to rectify this problem an appropriate service is needed to propagate requests to proper resources. This service should be placed in the internal zone and may have two connections. Although, almost all services and servers in the internal zone have a connection with ESB, the relationship between ESB and portal/application server is unilateral. Thus, this service may connect with ESB and portal/application server. The behavior of this service is like ESB and is used to exchange message format and security token if they are needed. Figure 4.8 depicts the new logical deployment architecture for an ESOA application that derives from IBM three scenario [3](Service creation, service connectivity, and interaction and collaboration services) [3] and three kinds of services presented by [1] and [2]. In this architecture due to the security policies defined between enterprise and partners, the Web Services provided for partners are placed in separate server. In such case, the information format and structure may be different from the Web Services message format provided for the public.

110 94 Figure 4.8 The Proposed Logical Deployment Architecture of ESOA Figure 4.9 shows the sequence diagram of this architecture where a partner sends a SOAP request to Web Service provided for partners. This service must have a connection to the data server. Figure 4.9 The sequence diagram of ESOA Logical Deployment Architecture The proposed security framework is applied on above logical architecture to provide the appropriate security solution for an ESOA. In the next section more details regarding this architecture which illustrates sequence diagrams and security services architecture is provided.

111 SOA Security Solution Design According to [1], the enterprise private key should be placed in the internal network zone. Once the security service or proxy needs the private key for decryption, it can fetch the key from the key store in the internal network. A more secure option is to depend upon on a decryption service within the internal zone to decrypt an incoming request. This project has aimed to store private key inside the boundary after the inner firewall. In order to protect the enterprise private key a Decryption Service (DCS) implemented within the internal network. Figure 4.10 depicts dynamic aspects of Decryption Service using sequence diagram. In this case a new hole is needed in the inner firewall. Proxy server receives the request (1) from a client and then invokes (2) Decryption Service (DCS) in order to decrypt those parts of message that have been encrypted. DCS fetches private key (3, 4) and then decrypt message (5). Finally, the exposed message is sent (6) to the proxy. Figure 4.10 Decryption Service sequence diagram

112 96 Infrastructure Security Services provide all security features related to communication, network, and systems such as transport layer security (SSL), physical security, firewalls, intrusion detection, Anti virus, and network monitoring. In addition, an IPSEC router is added in front of proxy server for whose want to access to the service from public. Operating System Security Management (OSSM) provides the capability to protect OS against all possibility threats. Indeed, these services must support all environmental security aspects. As the proposed logical deployment architecture for an ESOA shows, other than proxy server there are two more servers which provide services for public and partners. The definition of those services has been published in service registry (UDDI) or described for the partners. The clients can use WSDL and make SOAP to invoke those services. In such case after proxy receipts decrypted message, Access Management Service (AMS) - contains of Authorization Service (AZS) and Authentication Service (ATS) authenticate the request identity. Then, the request is sent to the relevant Web Service server either public or partners. This project uses reference architecture for the authentication presented by Elisa Bertino and Lorenzo D. Martino [83] as Figure 4.11 shows. In this architecture, authentication policies are based on available authentication modules (1), administrator is able to change the policy in Authentication Policy Base repository in order to limit vulnerability of authentication modules (2, 3).

113 97 Figure 4.11 Reference Architecture for the Authentication Service Requester sends an authentication request (4), such system is in charge of evaluating an authentication policy and make an authentication decision. The evaluation is executed by the Authentication Enforcement Point, which first retrieves (5) a proper authentication policy. Policy evaluation may also consider previous authentication events concerning the subject being authenticated (6a and 6b). Figure 4.12 Authentication of browser-based user identity

114 98 Figure 4.12 depicts how authentication can be done when a normal web-base request is sent to the proxy in order to use enterprise portal. Once a client send a SOAP message to use Web Service provided by enterprise for public or partner, the proxy server send the authenticated request to the appropriate Web Service Server as Figure 4.13 shows. Figure 4.13 Authentication of WS-Client request sequence diagram Authorization Service (AZS) is used for authorizing identities through Access Control Lists (ACLs) and role-based authorization model. In a SOA-based system, Attribute based Access Control can be implemented by SAML and XACML as Figure 4.14 shows.

115 99 Figure 4.14 Use of SAML and XACML in Implementing ABAC In this service, identity provider provides authentication assertion before the identity could access the resource. This sequence diagram shows how SAML and XACML can determine whether access should be granted. The requester tries to access the resource by authentication assertion (1). The Policy Enforcement Point (PEP) sends a SAML authorization decision request to the PDP (2). The PDP requests certain attribute assertions that are associated with the requester (3). The AA returns the appropriate attribute assertions (4). The PDP requests the XACML policy from the policy store (5). The PDP receives the XACML policy (6). After querying the XACML policy, the PDP sends an authorization decision assertion to the PEP (7). Based on the authorization decision assertion, the PEP grants the requester access to the resource (8). There is Service Routing Coordinator (SRC) which is responsible to routing requests to the proper resources. Figure 4.15 depicts the Service Routing Coordinator (SRC) architecture that includes several components such as Message Handler, Routing, Policy Repository, and Event repository. The definition of each component is explained as following:

116 100 Figure 4.15 The proposed Service Routing Coordinator (SRC) Architecture Message Handler: This component verifies the format of the messages whether are related to the defined format. It also exchanges the messages format to the standard format that is required. It sends a request to the routing component. Routing: This component decides which message must go to what resource. The decision is performed according to the information inside the message such as sender and receiver address and the policies that are defined in Policy repository. This operation should be recorded in Event Repository in order to further processes. Policy Repository: this component keeps information and policies required for routing a message. The basic information may be used in this component are ESB and Portal/Application Server IP address and their input and output requirements. Event Repository: all operation with their focal information should be recorded in this component. Once Service Routing Coordinator (SRC) exchanges message and routes it, the service address and appropriate information of this request should be placed in this component. This information remains until the Service Routing Coordinator (SRC) receives the respond of the request.

117 101 Figure 4.16 Service Routing Coordinator (SRC) Architecture sequence diagram As Figure 4.16 shows, the Web Service generates a request (1) and sends to the Message Handler of SRC. Message Handler verifies (2) the message and check it, if it needs to change this component changes the message format to standard format defined by the enterprise. The verified message is sent (3) to the Routing. Routing gets the required information and policy (4) from Policy Repository, and then routing (5) can be accomplished. This process should be recorded (6) in Event Repository. Routing component then sends this message to proper destination and gets the respond (7, 8). In order to routing respond, Routing get the information and policy, and then routes respond again (9, 10, 11). Message handler changes the format of message and sends to the Web Service (12, 13). The advantage of Service Routing Coordinator (SRC) is that web service can be implemented independency with any language and message format.

118 102 Due to nature of a SOA-based enterprise, there are several application, data, and service servers that have their own user repositories which contain the identities of registered users of their applications. Thus, a directory server needs to be deployed for integrating those repositories attributes. A Lightweight Directory Access Protocol or LDAP user registry is added to the solution architecture. It stores common identity information for the enterprise. In order to add, delete, or modify individual account information, an identity provisioning solution needs to be implemented. Identity Management Service (IMS) provides a secure, automated, and policy-based user life cycle management solution. Identity Propagation Service deals with token mediation and identity mapping, which can transform the format and content of identities in the solution. This capability is provided by a standard component that called Security Token Service (STS). STS is an implementation of the WS-Trust specification and has the capabilities to validate an inbound token, transform the identity representation, perform other functions such as authorization, and then issue a new token based on policies. The STS handles security tokens that are used to authenticate Web Service requests. The requests are structured according to the WS-Trust specification that defines a standard format for security token. To process the tokens, the STS uses modules, module instances, and trust service chains. For each type of token, the STS have a security token module that handles the trust relationship [82]. In most situations, Web Service Server needs to access the portal, applications, and data within the enterprise. In such case, STS performs mapping and token mediation. For example, when a user submits a service request through a portal to the ESB, a SAML (or any token) security token is created. The trust service chain in IMS is configured to use a LDAP mapping module to replace the user name value with new user before issuing a new SAML token. The Token Exchange Mediation Primitive inside the ESB mediation module extracts the SAML security token from the request and sends it to the STS in a WS-Trust message. If the token is valid, the STS issues a new Username token containing the same identity and returns it to the

119 103 ESB. The Username token issued by the STS is sent to the Application Server, which authenticates the request using the Application directory. As Figure 4.17 shows the Security Token Service (STS) uses Authentication Service (ATS) and LDAP for validating and mapping identities. It also uses Authorization Service (AZS) in order to authorize identities. After the trust established in SOA, trusted client uses right chain of the STS. Figure 4.17 STS Architecture Service authorization is performed in STS as part of the trust chain process. An authorization module instance is added to the trust chain so that authorization can be performed based on the Web service operation being invoked. Each application has its own authorization rules and policy. For example existing application may use role based authorization. Content Security Services can be used in several part of enterprise depends on the policies that have been defined by Privacy Service (PS). For example, the LDAP Server is the enterprise user registry containing user identities and confidential information, such as passwords and other repositories user ID. To secure the communication between any component and the directory, the services have to be configured to use secure LDAP (LDAPS) to encrypt information from and to the directory server.

120 104 Figure 4.18 Security Token Service sequence diagram Figure 4.18 depicts a sequence diagram of Security Token Service (STS). Once STS receives request from requester (1), it sends the request for authenticating to Authentication Service (2, 3). Then, STS sends the authenticated identity information to LDAP Service in order to perform mapping (4, 5). After the mapping was performed, the authorization of this identity is examined by Authorization Service (6, 7). Finally, STS generates new security token for the request (8). Non-Repudiation Service is implemented by Content Security Service and Audit Service. Availability Service (AVS) checks whether the requested service is available. All operations within an ESOA must be recorded in order to perform compliance and future forensics. According to the proposed framework all assets and services must have interaction with Audit Service (ADS). Figure 4.19 illustrates the To-Be Service-Oriented Audit Architecture [84]. That can be used in SOA security architecture design.

121 105 Figure 4.19 Service-Oriented Audit Architecture Security Policy Management Service (PMS) is implemented to manage the policies required for all component and services within the boundary. SOA Governance and Risk management (GRS) is responsible for defining security standards for interaction with services, establishing roles and responsibilities for policy administration, and how the services are made available to partners. Figure 4.20 depict a class diagram of some security services that are implemented in the internal zone.

122 106 Figure 4.20 Security solution class diagram Finally, based on the proposed security framework and the proposed logical deployment architecture a complete security solution design for an ESOA is presented as Figure Figure 4.21 The Complete Proposed ESOA Security Solution Design

123 Conclusion Analyzing all security requirements of the enterprise SOA-based shows there are not still enough technologies and approved standards to support all enterprise SOA-based needs. Indeed, according to [85], SOA systems do not follow their own rules when it comes to security. thus, some traditional security solutions that can affect SOA are required. Proposed Security Framework has been classified to support security requirements in ESOA. This framework can support all three security levels (content, communication, and network) of IT infrastructure. This framework derives from the literature of all security requirements, IBM Security Reference Model [3] and network-based security framework for SOA [62]. In addition, a new typical logical SOA deployment architecture has been presented. This architecture comes from three IBM scenarios and other solutions that were presented by other references. The advantage of this architecture is that the web service is placed in DMZ and has connection only by one line with the enterprise applications. The proposed Service Routing Coordinator (SRC) is responsible to propagate Web Service request to the ESB and Portal/Application Server. The Security Service Oriented Reference Architecture (SSORA) was presented in order to illustrate what security services in the proposed framework are needed for what layers of Service Oriented Reference Architecture (S3) [63]. According to the proposed framework and architectures, a security solution design that encompasses all entities within an enterprise has been designed. In fact, not all security services that mentioned in security solution design might be used in every ESOA. In some solution depend on the enterprise requirements, designers prefer to use just some of those services.

124 5 CASE STUDY: RAZAVI FINANCIAL INSTITUTE CHAPTER 5 CASE STUDY: RAZAVI FINANCIAL INSTITUTE 5.1 Introduction to the case study Razavi Financial Institute (RFI) is a banking based firm of approximately 60,000 customers that provides multiple services for its customers. This institute have been started its business in 1998 by only 2000 customers. Recently, this institute acquired a small insurance company of approximately 5000 customers that is called Mazan Salamat Insurance Company (MSIC). All customers formerly from MSI have a user identity in the RFI portal. RFI wants to be able to reuse the business logic in MSIC applications to offer new products to its customers and it hops that these applications can be reused in other parts of the RFI business. We need to provide the capability for MSIC customers to access to their insurance account via our company account, the Chief of RFI Computer Center said. Currently, RFI has added a link to connect to the MSIC portal for whose have already been the customers of MSIC. The problem is the customers have to memorize two usernames and Passwords for both systems, RFI and MSIC. Recently, the number of RFI customers is growing up to 1000 costumers in month. The team managers decided to achieve new system to provide the capability to add new services in order to entice new and current costumers. In addition, RFI plans to buy more companies related to its business activities in future. Its managers expect that new system be flexible to change and connect to other system applications.

125 109 Furthermore, they wanted use current systems and application in order to achieve this system because of cost limitation. This research has aimed to use this case study in order to describe the proposed security framework concepts and its relationship with Service Oriented Modeling and Architecture (SOMA). 5.2 Business process Figure 5.1 shows the holistic business process to access either RFI system or MSIC system via only one account that is belong RFI system. In this process, customer enters her/his username and account (or any credential) in order to access to her/his insurance and banking account information. The security requirements of user identity are examined. If it is not allowed to access to system the process is finished. If so, the system allows customer chose which services he/she wants to use. Figure 5.1 A holistic business processes for accessing to the relevant system

126 Solution overview According to the proposed logical deployment architecture for an ESOA and requirements of case study the logical deployment can be as Figure 5.2 to meet security needs laid down in the proposed ESOA security framework. Figure 5.2 Logical SOA deployment architecture for this case study There is Enterprise Service Bus (ESB) in order to provide connection between service consumer and service providers. In this case study ESB responsible to make connection between portal and MSIC application. Portal can directly connect to RFI application. 5.4 Service Modeling As mentioned before, SOMA provides an approach to building an SOA that align to business goals and ties the business processes directly to underlying applications through services [78]. SOMA consists of three main steps: Identification Specification

127 111 Realization of services, components and flows Primal study of both companies shows that RFI system can be changed to SOA approach in order to be flexible and easy connectable to other applications and uses their functionality. This project focuses on how customers can access insurance system via RFI identities. The security requirements for this case study are analyzed by SOMA. Then, the security solution for this case study is designed Identification The identification phase is connected to three main construct of SOA: services, component, and flows. It identifies the candidate services and creates the service portfolio for supporting the business process and organization goals. There are three main techniques for identifying candidate services: Goal Service Modeling (GSM), domain decomposition and existing asset analysis. The proposed ESOA security framework highlighted some security aspects and requirements as business security service according to the IBM Security Reference Model. Those components can be used to analyze security needs for this case study in this stage. Compliance and reporting: this service is needed for verifying the compliance of the message flow inside and across enterprise boundaries. Privacy: most of the information within these two systems is important such as customer s financial records, insurance information and personal information. In this case study privacy policies most be enforced. Non-repudiation Services: due to nature of activities inside the financial system the non-repudiation service is required to ensure that customers and RFI application cannot falsely deny about their interactions.

128 112 Identity and Access: RFI is managing the user life cycle by identity management system. The identity management system is responsible to provision to both RFI and MSIC systems. In order to incorporate users from portal into the RFI identity management system, portal uses RFI user repository. The policies ensure that each costumer owns the correct accounts, is a member of the correct groups, and has access to systems required for their roles. User self-care and user account revalidation are also covered by these business requirements. Trust Management: The business aspects of trust management, such as relationship and liability management began to be established during the integration of RFI portal and MSIC IT systems after the companies merged. For this project, it has been decided that a loosely coupled trust relationship model is to be employed. The following tables show Goal-service model for the case study. Table 5.1: Goal-service model for the case study Goal and sub goal KPIs (key performance indicators) Metrics Services 1. Connect to insurance system via RFI identities. To simplify user access 1.1. Enable RFI customer s access to their insurance information. To simplify user access The number of RFI and MSIC customers access to their insurance accounts Compliance Privacy Trust management Non-repudiation Identity management Access management In order to perform existing asset analyzing, the existing security solutions of RFI and MSIC application must be identified: RFI IT infrastructure: The first study of RFI systems shows that its applications implemented in Oracle traditional approach and their components have a tight relationship with each other. It uses Oracle Directory which is a robust and

129 113 scalable LDAP that leverages the high availability capabilities of the Oracle Database platform. MSIC IT infrastructure: This company have been designed and implemented in SOA-based approach and its applications are deployed in WebSphere Application Server. It also uses Tivoli Directory Server. The applications have capability to export their functionality as service with common language such as XML Specification In this stage, the high-level design and significant part of detailed design of service component is complete. This phase is used for designing SOA security solution. During the specification phase, the existing assets are leveraged. This stage selects and specifies the IT Security Services and Infrastructure Security Services. Identity provisioning: there are two user registries that are used in the solution: a directory for RFI and Tivoli Directory Server used by MSIC. A new user registry (LDAP) is required for RFI portal. Identity Management Service (IMS) and Access Management Service are needed for provisioning. Identity propagation: Identity information is required to flow securely from RFI Portal to MSIC Application Server through ESB. The Portal calls the Security Token Service (STS) to perform identity mapping and token mediation. A SAML 2.0 security token is generated, containing the user s identity. ESB calls STS to convert the SAML 2.0 security token passed from the Portal to a Username token. STS provides the capability to transform the format and content of identities in the solution. WS-Trust clients for portal and Enterprise Service Bus are used to initiate the WS-Trust service call to STS.

130 114 Authentication: browser based users is authenticated by Access Management Service. Proxy is the secure Web point of contact in the solution, and LDAP-based user name/password authentication is used in this case study. Authorization: Access Management Service provides authorization of user requests based on ACLs. It can also restrict access based on time-of-week using a protected object policy. ESB is currently accessible to RFI Portal only. MSIC application is a J2EE application running on WebSphere Application Server. Standard role-based J2EE Authorization Services are used. Figure 5.3 depicts how identity provisioning, identity propagation, and access management can be used in this case study. Figure 5.3 Identity and Access management Transport and message level security: Confidentiality Service and Communication Security Service can be used to ensure transport and message level security. In this case study, transport level confidentiality is applied as following communication channels:

131 115 Communication between user browser and Proxy: To secure the communication channel between user browser and RFI Portal, Secure Sockets Layer (SSL) is implemented. Proxy terminates the HTTPS session of the customer request. Communication between Proxy and RFI Portal Server: In this case study, the data flow between the user browser and the MSIC does not use SSL. Communication to STS: RFI Portal and ESB are exchanging WS- Trust messages with STS. Normally, SOAP over HTTPS is considered an appropriate mechanism to secure these channels. SOAP over HTTP is implemented for simplicity. Communication to the Tivoli Directory Server: The Tivoli Directory Server is the enterprise user registry containing user identities including confidential information, such as passwords. Communication between the Access Management Services: Access Management Service (AMS) uses SSL for communication between its components. Audit service: almost all security and entity have communication with this service. Infrastructure Security Service can be added in this stage, for example because of sensitively of banking information IPsec router can be used in network layer security. Network intrusion detection can be used in front of proxy. Operating System Security can be used in all servers in order to protect log files and access to the server. As mentioned before, private key store and Decryption Service can be placed in internal zone.

132 116 Security Policy Management (PMS) and Governance and Risk management (GRS) are focal point of security in this case study. After considering all security service of proposed framework a security solution design for this case study is shown as Figure 5.4. Figure 5.4 Complete security solution design for case study

133 6 IMPLEMENTATION CHAPTER 6 IMPLEMENTATION This chapter aims to explain how a security solution can be implemented. At first stage, the platforms, tools and technologies that are required for implementing a Web Service and Web Service client are explained. Then, the security services that have been considered for case study are implemented. In order to create a Web Service some tools and SOAP processing engine to pars the message are needed. These tools can parse the messages that they received and call the functions and methods that those messages need. There are many vendors that provide these processing and many of them provide other tools that can help developers to write the code needed simply. This project aims to use Apache Software Foundation s Axis product that is an academic product and WSO2 Web Services Framework/PHP (WSO2 WSF/PHP) for implementing RFI case study Security Web Services. 6.1 Apache Axis Apache Axis stands for Apache Extensible Interaction System which is an open-source project of the Apache Software Foundation. It is a SOAP engine framework for clients, servers, gateways, and so on. The current version of Axis has implemented by java but recently, a C++ implementation of the client side is developed. Axis also includes [86]:

134 118 a simple stand-alone server, A server which plugs into servlet engines such as Tomcat, extensive support for the Web Service Description Language (WSDL), emitter tooling that generates Java classes from WSDL, some sample programs, and a tool for monitoring TCP/IP packets Axis Architecture The Apache Axis architecture is relied on the foundation of a SOAP engine. This engine accepts SOAP messages, parses them, and calls the appropriate methods and functions in the Web service. Apache Axis is organized in a fairly unique way. The following sections introduce you to the most important features of this organization. Handlers: A handler is a code that performs a specific function and method. They may perform various jobs such as log the message, decrypt message, call the legacy system, and so on. Currently these handlers are written in Java and C++. Handlers are as method calls and are not called by a main method. They are called by Axis directly. Chains: Axis chain is composite handler [86][87]. It is a special type of handler contains of other handlers. The execution of these contained chains is ordered, so chains represent a type of Axis control language, but without parameter passing. A targeted chain is a special type of chain that contains more than one entry point. Transport handlers are handlers that have both a request side and a response

135 119 side, which enables a single HTTP handler to both receive and send messages. A targeted chain can act in both roles, however. Figure 6.1 shows how handlers can be used to subdivide the tasks associated with the consuming SOAP messages. Figure 6.1 The Axis engine uses chains of handlers to process its messages Thus, the Web service can be defined as the sum of all the handlers defined to process the incoming messages, combined with the legacy system that does the difficult work. Transport: A transport is the communications mechanism to deliver message to or from the Axis engine. There are several protocols such as HTTP, SMTP, FTP, and JMS which are supported by any Web Services engine. All these transports protocol have a way to transfer data from one system to another, but with varying degrees of reliability and speed [87].

136 120 The SOAP Engine: The focal entry point into a Web service is the Axis engine. It parses the messages and calls the relevant handlers and chains according to instructions provided by the deployment engineer [87]. Dispatcher: it is a special type of handler which is used to separate business logic from handler logic. The RPCDispatcher converts SOAP messages to Java objects, and then makes calls to the Web service. This takes off all business logic from the handlers Error! Reference source not found. [87]. Transport Listeners: A transport listener [87] is a servlet that waits for a SOAP message. It is responsible for creating an instance of Axis and passing the SOAP message to it. Transport Senders: When Axis is acting like a client, it needs a way to send the requested SOAP message to a SOAP server. The Axis handlers for doing this are called transport senders Install Apache Axis In order to install Axis, some other installation and configuration are needed to be installed before installing Apache Axis. The following steps show how Apache Axis can be installed: 1. The latest version of Java (JDK) can be downloaded and installed. In order simplify use of java code and create Web Service and Web Service Client an appropriate platform such as Net Beans 6 is recommended. 2. After installing JDK, the latest version of Apache Tomcat should be installed. In order to test installation of Tomcat, it is enough to write The result must be like Tomcat localhost home page as Figure 6.2 shows.

137 121 Figure 6.2 The Tomcat localhost home page 3. Apache Axis is available from the Apache Web site at The downloaded file should be unzipped. Next, Axis must be moved into the Web server s directory. So, Axis directory with all of its contents and subdirectory should be placed into the D:\Apache Tomcat 4.0\webapps directory. Figure 6.3 shows Apache Axis Home page. Figure 6.3 The Apache Axis home page

138 After installation have finished. It should be tested in order to rectify likely errors. The validation hyperlink helps to find possible errors as shown in Figure 6.4. Figure 6.4 The Axis Happiness page Notice that each needed jar file is listed, along with a status that says where that jar was located. Notice that there is a missing jar at the bottom of the figure. This is the activation.jar, which can be found at Downloading, unzipping, and copying this file to the \ webapps\axis\web-inf\lib directory will get rid of this message. Tomcat server must be restarted every time that a jar file in lib directory is added, or Tomcat will not find it. The List hyperlink of axis homepage shows the list of deployed Web services. By clicking on WSDL link of each list, Axis generates WSDL code of each Web Service as shown in Figure 6.5. To run a client, the classpath should be set to point to all the jar files in the Axis download, plus a few others such as axis.jar, jaxrpc.jar, saaj.jar, commonslogging.jar, commons-discovery.jar, wsdl4j.jar, xmlparserapis.jar, xercesimpl.jar, and j2ee.jar.

139 123 Figure 6.5 WSDL list of Web Service 6.2 WSO2 Web Services Framework/PHP (WSO2 WSF/PHP) WSO2 Web Services Framework/PHP (WSO2 WSF/PHP) is a SOAP generation to provide Web Service and Web Service client in PHP. It was provided based on WSO2 WSF/C. it can support SOAP, WSDL, and some WS-* standards such as SOAP MTMOM, WS-Addressing, WS-Security, WS-SecurityPolicy, and WS-ReliableMessaging. WSO2 WSF/PHP has interoperability with Microsoft.NET, Apache Axis2/Java based Web services application server, and other J2EE implementations. This platform can send and receive attachment with SOAP message. The single Web Service can be exposed either SOAP or Rest style.

140 Installing and Running on Microsoft Windows In order to install WSO2 WSF/PHP some primarily installations and software are required. The following files and software are needed to be downloaded: Libxml2 and iconv binary distribution from: pub/libxml/ OpenSSL binary distribution (Use MSI installer) from: PHP 5 or above Source from: Win32build from: Mysql Server 5 from: wso2-wsf-php-bin win32 from: Microsoft Visual Studio. In order to install Mysql and PHP automatically with their configurations, the XAMPP application is recommended. This application installs and configures Apache, Mysql, PHP, SQLite, OpenSSL, ADOdb, Webalizer, and Zend Optimizer. After installing these applications the wso2-wsf-php-src.zip file must be unzipped. It is located as wso2-wsf-php-bin win32 in the source directory and contains of several directory such as src, wsf_c, docs, samples, and scripts. This project assumes all installation is located in drive D. the following steps should be considered in order to install WSO2 WSF/PHP: 1. The wsd.dll must be copied to the d:\php\ext directory. 2. The wso2-wsf-php-bin win32\wsf_c\lib directory must be added to the PATH environment variable. 3. the following entries should be added in php.ini file: a. wsf.home="<path_to_extract_folder>\wsf_c" b. wsf.log_path="<path to extract_folder>\wsf_c\logs" c. wsf.log_level=3

141 125 d. extension=wsf.dll e. Set extension_dir entry to php.ini extensions directory: extension_dir ="./ext" f. The extension = php_xsl.dll must be enabled g. D:\wso2-wsf-php-bin win32\scripts\ should be inserted in include_path 4. The Apache Web server must be configured with PHP. Thus, the php5apache2.dll must be copied to Apache/modules directory and the following entries must be added in httpd.conf file: a. LoadModule php5_module modules/php5apache2.dll b. PHPIniDir "< php.ini file location> " c. AddType application/x-httpd-php.php.phtml d. AddType application/x-httpd-php-source.phps 6.3 Implementing case study In this stage, some Web Services of RFI case study is implemented. As mentioned before on chapter 5, customer first sends the username and password to the RFI Portal via web browser. In first step, the request is examined by proxy service within the DMZ. Proxy is responsible to validate user identity with Authentication Service. If the request is encrypted by requester, the proxy first has to decrypt message and then authenticate the user identity. After authentication, the portal main page is available for customer to choose the relevant service either RFI or MSIC application. Figure 6.6 shows the sequence diagram of this scenario. In order to implement this scenario of case study the following Web Services is required: Proxy Client

142 126 Authentication and Authorization Policy LDAP Portal Main page Figure 6.6 The sequence diagram of case study web browser customer scenario In this project all services are placed in the project2 directory within the Apache Web server's document root. In order to better illustration of this implementation, all zones that have been designed in security solution design are defined as separate directory in project2 directory. The NetBeans 6 is used to coding Web Services. These services are implemented by PHP and are placed in related directory. Each of these directories can be a separated server or location. In the real world according to typical deployment architecture, these services can be located in separate servers to run their functionality. In this project all services located in one server. Figure 6.7 shows how this project locates zones and services.

143 127 Figure 6.7 The view of NetBeans and the location of services Customer Service Customer sends the username and password via web browser; in such case, the transfer security protocol such as SSL/STL can be used to protect the user identity information against unauthorized person. This service is a simple form that is designed with HTML. Further, a Web Service Client is implemented to provide endto-end security with encrypting and signing the message. This file is named as client_web.php and is placed in project2 directory. This service can be run via as Figure 6.8 shows Figure 6.8 The web based client to send username and password

144 Proxy Service Proxy server receives username and password and invokes the authentication service to validate the user identity. This service is implemented in WSO2 WSF/PHP. In the top of this service code, the session_start() is defined in order to manage sessions within the collaboration and transformation. The $reqpayloadstring defines an XML based request, then based on $reqpayloadstring, the proxy service generates new SOAP message for the authentication service. Indeed, in this case the proxy service acts as a client. The following SOAP message is sent from the proxy to the authentication service. <soapenv:envelope xmlns:soapenv=" <soapenv:header/> <soapenv:body> <ns1:authentication xmlns:ns1=" <username>ala</username> <password>ala</password> </ns1:authentication> </soapenv:body> </soapenv:envelope> Authentication Service This service is responsible to authenticate an identity and sends a respond to the proxy whether the identity can access to the portal. The URL Address of this service is In order to see the WSDL code of this Web service it is enough to add?wsdl at the end of the Web Service s URL. This project uses a Mysql database as user identity repository. All required information for authenticating, authorizing, and mapping are kept in this repository. This service sends the following SOAP message as respond of the proxy request. <soapenv:envelope xmlns:soapenv=" <soapenv:header/>

145 129 <soapenv:body> <ns1:result xmlns:ns1=" <text>success</text> </ns1:result> </soapenv:body> </soapenv:envelope> Portal Once the proxy service receives the respond from the authentication service, it should make decision for sending authenticated identity to the portal. The portal provides a web page for costumer to choose a service. Then, portal sends authenticated identity to authorization service in order to examine whether the customer has authority to access the resource. If so, portal generates a SOAP message and sends to the selected service with authenticated identity. In this case the identity information for RFI is equal with the identity for the portal, thus no need to mapping and invoking STS Service. Figure 6.9 shows portal main page that allows the customer choose a service. Figure 6.9 The portal service main page