SOA security

SOA SECURITY JAMIE FIERE A THESIS SUBMITTED IN PARTIAL FULLLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF INFORMATION SCIENCES FACULTY OF SCIENCE VRIJE UNIVERSITEIT AMSTERDAM NOVEMBER 2007

Acknowledgements This thesis is the result of an internship that started in April and ended in November of 2007 at Zwitserleven. During this time, I have tried to combine the requirements of Zwitserleven with the scientific requirements of a Master thesis, thereby learning that writing a Master thesis is really hard work; I never thought it would take this long and be this difficult to complete. However overall it has been a good learning experience, in a theoretical as well as personal way. This thesis would not be what it is now, without the help of many people. First, I would like to thank Patricia Lago, my supervisor at the VU for the valuable feedback and discussions about my thesis, and Hans van Vliet for acting as the second reader of my thesis. Secondly, I would like to thank my supervisor as Zwitserleven, Laurens van Beurden for discussions and feedback on my thesis. I also like to thank the following persons of Zwitserleven for their cooperation in my thesis, Peter Schaap, Marco Veerkamp (for the distractions), Bob Zondervan, Jeroen Smit, Alex Punt, Rolf Heggie, Ed Magnée and Remco Suiker. I would also like to thank all the other employees at Zwitserleven that made my internship at Zwitserleven fun! Finally yet importantly, I would like to thank my family and my girlfriend for their support. I would especially like to thank my mother. She has provided a warm home, and has always been there for me. Without her, I could not have finished (or even started) my study at all. Thank you very much! Jamie Fiere Almere November 2007

Contents Acknowledgements .................................................................................................. 2 Contents....................................................................................................................I List of figures ......................................................................................................... IV List of tables............................................................................................................ V Introduction ............................................................................................................. 1 Chapter 1 ................................................................................................................. 8 Service-Oriented Architectures.............................................................................. 8 1.1 Introduction........................................................................................... 8 1.2 Definition .............................................................................................. 8 1.3 Elements................................................................................................ 9 1.4 SOA technical implementation............................................................. 12 1.5 SOA layers........................................................................................... 15 1.6 Benefits and drawbacks ....................................................................... 16 1.7 SOA versus Other Concepts ................................................................. 17 1.8 Conclusion........................................................................................... 21 1.9 Further reading.................................................................................... 21 Chapter 2 ............................................................................................................... 22 Security .............................................................................................................. 22 2.1 Introduction......................................................................................... 22 2.2 What is security? ................................................................................. 22 2.3 Security types ...................................................................................... 23 2.4 Security policy ..................................................................................... 24 2.5 Basic security principles ...................................................................... 24 2.6 Additional security principles .............................................................. 27 2.7 Conclusion........................................................................................... 29 2.8 Further reading.................................................................................... 29 Chapter 3 ............................................................................................................... 30 SOA security....................................................................................................... 30 3.1 Why is SOA security different? ............................................................ 30 3.2 SOA security threats ............................................................................ 30 I

3.3 SOA Security elements......................................................................... 32 3.4 WSOA and security.............................................................................. 35 3.5 Conclusion........................................................................................... 42 3.6 Further reading.................................................................................... 43 Chapter 4 ............................................................................................................... 45 Zwitserleven SOA ............................................................................................... 45 4.1 Introduction......................................................................................... 45 4.2 Summary design documentation .......................................................... 45 4.3 Zwitserleven SOA layers ...................................................................... 46 4.4 Technical implementation of the SOA layers........................................ 49 4.5 Security standards used in BEA products ............................................. 53 4.6 Conclusion........................................................................................... 53 Chapter 5 ............................................................................................................... 55 Reference model ................................................................................................. 55 5.1 Introduction......................................................................................... 55 5.2 Reading guide ...................................................................................... 55 5.3 View catalogue .................................................................................... 55 5.4 View template ..................................................................................... 56 5.5 System overview.................................................................................. 57 5.6 Deployment view / Architects’ view .................................................... 58 5.7 Service view / designers’ view ............................................................. 61 5.8 Identity view / Security officer view .................................................... 64 5.9 Conclusion........................................................................................... 65 5.10 Further reading.................................................................................... 65 Chapter 6 ............................................................................................................... 66 Discussion .......................................................................................................... 66 6.1 Views .................................................................................................. 66 6.2 Number of viewpoints / stakeholders ................................................... 66 6.3 Method for viewpoint creation............................................................. 66 6.4 Maturity of scientific research ............................................................. 67 6.5 Commercial literature .......................................................................... 67 6.6 AK-SPAM method................................................................................ 67 Glossary of terms ................................................................................................... 68 Appendix A ............................................................................................................ 70 Appendix B ............................................................................................................ 73

Content-2-concerns table ........................................................................................ 78 Viewpoints ............................................................................................................. 83 Appendix C ............................................................................................................ 86 Appendix D............................................................................................................ 99 Appendix E .......................................................................................................... 101 Appendix F .......................................................................................................... 102 References ........................................................................................................... 106

List of figures Figure 1 Union security and SOA security ................................................................ 3 Figure 2 Research process ........................................................................................ 6 Figure 3 Basic SOA................................................................................................. 11 Figure 4 Common technical implementation SOA................................................... 12 Figure 5 Service orchestration ................................................................................ 15 Figure 6 EAI........................................................................................................... 18 Figure 7 Basic security elements............................................................................. 26 Figure 8 Transport level security ............................................................................ 33 Figure 9 Message level security .............................................................................. 33 Figure 10 Model for secure SOA............................................................................. 35 Figure 11 Enveloping signature .............................................................................. 37 Figure 12 Enveloped signature................................................................................ 37 Figure 13 Detached signature ................................................................................. 37 Figure 14 Identity management structure adapted from [9] ..................................... 40 Figure 15 Zwitserleven SOA layers ......................................................................... 47 Figure 16 Technical implementation of the SOA layers........................................... 49 Figure 17 BEA Aqualogic Service Bus ..................................................................... 51 Figure 18 BEA Weblogic integration ....................................................................... 51 Figure 19 System overview..................................................................................... 57 Figure 20 Elements of system overview.................................................................. 58 Figure 21 Primary presentation deployment view................................................... 59 Figure 22 Software engineer view........................................................................... 61 Figure 23 Web service with SOAP handler. ............................................................ 63 Figure 24 Primary presentation security view......................................................... 64 Figure 25 XML example 1 ...................................................................................... 99 Figure 26 XML example 2 .................................................................................... 100

List of tables Table 1 Alternative naming for elements of SOA ...................................................... 9 Table 2 Comparison of SOA layers ......................................................................... 15 Table 3 Comparison of security views .................................................................... 27 Table 4 Security principles mapped to SOA security elements ................................ 35 Table 5 Standards in Secure SOA model ................................................................. 43 Table 6 Zwitserleven layers compared to SOA layers.............................................. 48 Table 7 Security standards in BEA products ........................................................... 53 Table 8 View reading guide .................................................................................... 55 Table 9 Architect stakeholder profile ...................................................................... 74 Table 10 System developer stakeholder profile ....................................................... 75 Table 11 Security officer stakeholder profile........................................................... 77 Table 12 Content-2-concerns table .......................................................................... 82 Table 13 Service viewpoint..................................................................................... 83 Table 14 Identity viewpoint.................................................................................... 84 Table 15 Deployment viewpoint............................................................................. 85 Table 16 Status field terms ..................................................................................... 86 Table 17 Ranking field terms.................................................................................. 86 Table 18 Authentication providers........................................................................ 102 Table 19 Authorization providers.......................................................................... 103 Table 20 Credential mapping providers ................................................................ 103 Table 21 Role mapping providers ......................................................................... 104

0BService-Oriented Architectures 1 Introduction This chapter introduces this thesis by describing the background, the purpose and the research approach. Background Historically businesses have tried to align the business with information technology (IT) in order to achieve cost reductions, more profit and/or competitive advantage. Changes in the business environment commonly require a business to change. IT systems that support the business should be flexible enough to support business changes and be as cost effective as possible. In order to create flexible IT systems, software engineers have been using several concepts such as object orientation and component based development. Recently more attention is given to the organization and utilizing of distributed capabilities across different ownership domains [89]. Commonly these distributed capabilities are in the form of autonomous reusable services, which can be used in different business processes. In the literature, this is commonly referred to as Service-Oriented Architecture (SOA). Gartner predicts that in 2007, 50 percent, and in 2010, 80 percent of the new mission critical operational applications and business processes will rely on SOA [75]. In the Netherlands, SOA will be the driving force to solve (IT) problems within the Tax and Customs Administration 1 . McKinsey 2 estimates that 80 percent of the companies are investing in Web services, which can play a role in the technical implementation of SOA. Another topic besides SOA that has gotten more attention lately is (information) security. A survey by the CSI/FBI points out that 52 percent of the companies (in the U.S.) detected unauthorised use of their computer systems resulting in a total financial loss for security breaches of roughly $52 million [73]. Similarly, the Audit 1 Computable, accessed 16-11-2006, http://www.computable.nl/nieuws.jsp?id=2220808 2 MckKinsey Quarterly http://www.mckinseyquarterly.com/How_businesses_are_using_Web_20_A_McKinse y_Global_Survey_1913_abstract 1

Introduction 2 Commission in England estimates losses up to $2 billion [6]. One would think that these figures would make security a hot topic in any organization. Nevertheless, it seems that IT executives identify (information) security as important but not critical [40]. Cost reduction within organizations and competition could be one reason for this. Changing the business (processes) demands rapid application (or changing) of IT systems. In this process, security concerns are frequently inadequately planned and understood [6]. Purpose of this thesis Zwitserleven is the Dutch division of the internationally operating Swiss concern Swiss life. The concern has divisions in Switzerland, France, Germany, the Netherlands, Belgium and Luxembourg and belongs to the ten largest pension insurers in Europe. Zwitserleven also provides other financial services such as mortgages and life insurance policies. The company is located in Amstelveen and has approximately 750 employees. Zwitserleven has many legacy and middleware solutions/systems supporting their business processes. Functionalities fulfilling (parts of) business processes are distributed across these systems. One of the effects of this distribution is that employees have to do manual labour in order to perform their tasks. One example is that one system has output in the form of printed documents that are used as input for another system. The world of pension insurers is subject to regular change due to new or changed laws and regulations. A company such as Zwitserleven will have to be able to adjust to changes due to legal issues, or be able to create new products to benefit from new regulations. Zwitserleven sees it as a challenge to increase (or maintain) customer satisfaction in this changing environment. Customer satisfaction can be achieved by providing for customer self-service such as a portal where address changes can be entered or financial statements can be viewed without interference of Zwitserleven personnel. To cope with these (and future) challenges Zwitserleven has chosen to implement SOA. There have been some efforts to implement SOA at Zwitserleven. However, security within a SOA is one issue that needs attention. There are currently no guidelines or reference models available to Zwitserleven that enable a secure SOA implementation. The purpose of this thesis is to create a reference model for secure SOA. This reference model should be able to accommodate different implementations of SOA.

Introduction 3 One of these implementations is (off course) at Zwitserleven. In addition, the reference model will accommodate different stakeholders. Research question What are the security requirements for a service-oriented architecture? Research approach The type of research design of this thesis is exploratory [52]. The field of SOA, security and the application of security in SOA are (more or less) understood. The research has to combine the separate fields into one solution that presents security in SOA. The research approach consists of four main phases: literature review, analysis, design and evaluation. Literature review The first activity is a literature review. The reviewed literature concerns SOA, security (in general) and SOA security in the scientific research field and commercial solutions. The union (see Figure 1) of security and SOA security can be used as general guidelines (for which for instance patterns already exist) for a secure SOA. Figure 1 Union security and SOA security External sources First I performed a literature review of external sources to acquire background knowledge of the domain of service-oriented architecture. After this initial orientation phase, in depth data sources for SOA were researched. Library search such as IEEE and ACM were used as the primary source of data. Next to this scholar.google.com was used to find other related data such as conference papers. In some cases also presentations of acclaimed persons (or experts) and well-established commercial organizations (IBM, Microsoft, BEA) were used.

Introduction 4 In addition to research papers, several books were also used. Some of these books were found by looking at references of research papers and by using the search engine Google. Others were already available at Zwitserleven. After the initial research, it seemed that the amount of data available for both SOA and SOA security was minimal. Some sources suggested that SOA is analogous to for instance implementation elements such as Web Services and Enterprise Service Bus. To prevent misinterpretation a comparison between SOA and several other concepts was made. After the differences were clear I decided to use some of the sources that focused on implementation of SOA, but only to use parts that could be generalized. Internal sources The internal sources were used to obtain primary data. The data was obtained by personal interviews, group discussion and a case study. The personal interviews were conducted with the security officer, architects, a network specialist, managers and software engineers. The purpose of these interviews was to obtain information about current projects that could influence the purpose of this thesis. The group discussion was used to get an understanding about the security policy. More specific the question was how the security policy of the company was structured, what the status of this policy was and to clarify terms used in the policy. The case study is one of the important parts of this research. This case study was used to validate a generalized set of hypotheses that were developed based on both external and internal sources. In this case study Zwitserleven is a specific case that finds itself in the particular situation on which the hypotheses should hold.. Analysis The analysis phase consisted of interviews with Zwitserleven employees and analysis of security and SOA. The interviewees consisted of three architects, one IT security officer, one former IT security officer (currently compliance employee) and one application coordinator / system engineer. All were interviewed to prepare stakeholder profiles. The security officer and two architects were interviewed about the future security requirements of SOA. This will be used as input for the reference model. The analysis of security and SOA has led to a secure SOA model.

Introduction 5 Design The reference model for as secure SOA was created in this phase. A first draft was be used as the basis of a reference model for a secure SOA at Zwitserleven. This reference model consists of a architecture description with views. The views are produced according to [42]. To develop the viewpoints, on which the views are based the method in [16] is used. The four activities that were performed to define viewpoints are: 1. Compile stakeholder profiles. 2. Summarize internal design documentation. 3. Relate summary of internal design documentation to concerns of stakeholders. 4. Define viewpoints. The views also contain the design decisions that were made. The design decisions are modelled according to the architectural knowledge design SPAce Modelling (AK- SPAM) described in [10]. Evaluation During the evaluation phase the draft versions(s) of the reference model were evaluated against a small project within Zwitserleven. The goal of this case study is to test whether the general approach can also be applied to a more specific situation. The validation will be performed by interviewing the stakeholders as mentioned above and observing problem areas with the application of the reference model. Based on the feedback of the draft version(s) of the reference model(s) the final reference model for the Secure SOA was produced.

Introduction 6 Research process Figure 2 Research process Figure 2 models the research process. The four phases (literature review, analysis, design and evaluation) discussed in the previous sections provide input for the research process. Structure of the thesis This thesis is structured as follows: Chapter 1 introduces the general concepts of SOA, the need for SOA and the difference between SOA and other (related) concepts. Chapter 2 introduces the general concepts of security. These include types of security and basic and additional security principles. Chapter 3 combines the first two chapters of the thesis to describe the security in SOA. An analysis is made of the security threats within SOA based on the general SOA concepts of Chapter 1. Using these threats and the security principles of Chapter 2 a model for secure SOA is proposed. This model will be used in a case study performed at Zwitserleven. This case study can be used as an example for other organizations that are implementing a SOA system. Chapter 4 describes the technical implementation of SOA at Zwitserleven. Certain choices made by Zwitserleven impose certain (security) standards. Some of these will have to be used in the reference model Chapter 5 combines the previous four chapters into one reference model for a secure SOA. This chapter also contains the rationale for the reference model.

Introduction 7 Constraints Security concepts At the time of this writing (2007) the area of SOA security is evolving. Standards are in the process of being completed or are under development. Where available (newest) final versions of standards are discussed. Due to the moving area of development, parts of standards can be changed when you read this. Specific details of security protocols are therefore limited. If a detailed approach is necessary, I advise the reader to research the latest versions of these standards.

0BService-Oriented Architectures 8 Chapter 1 Service-Oriented Architectures 1.1 Introduction This chapter introduces the concept of Service-Oriented Architecture (SOA). First, I will provide a definition of SOA that will be used throughout my thesis. The elements that exist in SOA will be introduced in the next section, as well as reported benefits and drawbacks of the SOA approach. To avoid any confusion this chapter will also compare SOA to other concepts among which are object orientation and component based development. Web services and other related technologies are usually mentioned when SOA is concerned. Section 1.4 will introduce these technologies. This chapter finalizes with a description of the abstract layers, which can be used to describe how a SOA is implemented within an organization. 1.2 Definition Before continuing to a definition of SOA it is noteworthy to supply a definition of software architecture of which SOA is a subset. There is no agreement of a definition of software architecture. In fact, the Carnegie Mellon University has collected more than 50 definitions of software architecture 3 . For the purpose of this thesis the following definition is used: “The structure or structures of the system, which comprise elements, the externally visible properties of those elements, and the relationships among them.” [42] Providing a definition for service-oriented architecture that is shared by many sources has proven difficult. For a non-exhaustive list of SOA definitions see Appendix A. The definition that has been approved by a number 4 of (commercial) parties is that by the Organization for the Advancement of Structured Information 3 http://www.sei.cmu.edu/architecture/published_definitions.html 4 Adobe Systems, AmSoft, Axway Software, BEA Systems, Boeing, Booz Allen Hamilton, Capgemini, Fujitsu, General Motors, NEC, Reactivity, Software AG.

Service-Oriented Architectures 9 Standards (OASIS 5 ). OASIS has developed a full reference model for SOA and in this reference model SOA is defined as: “Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.” [89] The definitions in Appendix A often refer to SOA (or SOA services) as being “coarse- grained”. As mentioned in [89] the term is subjective does not have any useful metrics. I agree with this view, and therefore the term is not used in this thesis. In short, SOA is what the name suggest, an architecture that is oriented on services. The architecture provides the organization of these services that can be seen as the distributed capabilities or components. Note that there is no technical element (such as web service or UDDI) in the definition of OASIS. This is important because SOA must make the enterprise independent of a specific technical implementation or infrastructure. Technology should not cause dependencies between components or have impact on the structure of the application landscape [56] [43]. 1.3 Elements Just like the SOA definitions, there also seems to be no conformity as to what elements are available in SOA. However some elements are common in several sources [12][21][29][30][33][35][39][49][89], these elements are; service, service client and service registry. In some cases [29][39] the concepts of service provider is also mentioned. Each of these elements have their own responsibilities. The naming of the elements can vary from source to source but have the same meaning. A comparison of alternative names can be found in Table 1. Table 1 Alternative naming for elements of SOA Element name Alternative name Service client Service requestor Service consumer Application builders Service registry Service registry and broker Service broker 5 http://www.oasis-open.org/who/

Service-Oriented Architectures 10 Service Services are at the core of SOA. It should therefore be clear what a service in SOA is. Just like the definition of SOA, defining the term service is not an easy task [32]. The most simply idea is that a service performs a (reusable) function. This function can be anything from simple retrieval of data to performing a whole business process [29][30]. The services in SOA always have a business aspect to them instead of a more technical aspect. An example of a service is get customer profile, opposed to upload file, which is not a business service [56]. A service is defined by [89] as “the performance of work (a function) by one for another”. This definition is related to the following ideas: The capability to perform work for another The specification of the work offered for another The offer to perform work for another Summarizing requirements for services: All services are loosely coupled. This means that all services are independent and have no knowledge about internal structure of other services or service clients [12][29][30][33][50]. Services must be technology neutral (implementation neutrality). Service must be accessed by the lowest common technology available to IT environments. This implies use of standards [12][29][39][50][56]. Services should support location transparency [30][50]. The location of the service has no influence on the workings of the service. Before a service can be used by other parties it should be clear what the service does and needs to perform the function. Information that the service should contain is service input and output, conditions for using the service, and what is accomplished when the service is invoked [89]. Service client The service client uses the service and interacts with it. The service client can use services to compose applications by combining available services [39]. It interacts with both the service registry and service provider [33]. The service client uses the service registry to find services, and then interacts directly with the service. A service client can be for instance another service or a person.

Service-Oriented Architectures 11 Service registry A service registry contains a repository of available service providers. A service provider can publish information about its available services to the service registry. A (relevant) service client on the other hand can find information about the available services. [21][30][39][33][56]. The service registry either can be implemented as an automated system or could have human involvement (such as an Excel file containing all the services). Examples of information that should be provided by the service registry about services are provided in [56]. This information is for instance the service owner, or information about the quality of service of a specific service. Service provider A service provider is what supplies and develops services. The service provider is usually an organization [29][39]. The service provider defines the service implementations, service descriptions and the technical and business support for a specific service. Basic SOA Figure 3 depicts a basic SOA (adapted from [30][49]). This is just a conceptual model of interaction between participants of SOA. Based on this interaction each SOA application should have its own architectural style. The basic SOA is configured in a so-called hub-and-spoke architecture, where a number of spokes extend outward from a central hub. The service registry in this case has the information that enables interaction between service provider and service client [28]. Service Provider In h is te bl ra Pu ct Service Registry Find Service Client Figure 3 Basic SOA

Service-Oriented Architectures 12 1.4 SOA technical implementation When researching SOA, it is almost impossible not to see Web services mentioned interchangeably with SOA. Web services are one possible approach for implementing SOA concepts. The most know technological standards used in SOA with web services are Web Service Description Language (WSDL), SOAP 6 , Universal Description Discovery and Integration (UDDI). Figure 4 (adapted from [21][49]) shows these standards in a Web services based SOA (WSOA). Each of these Web services will be described in the following sections. Next to this there are two other technologies that I want to address in this section. One is the Enterprise Service Bus (ESB) and the other Web Services Business Process Execution Language. I want to address them since they are also common objects in the SOA environment. Service Provider Ex SO sa ch AP ge S D sh an W bli m L Pu ge es Service Registry Discover and retrieve WSDL Service Client (UDDI) Figure 4 Common technical implementation SOA Web services The W3C defines a web service as follows: “A Web service is a software system designed to support interoperable machine-to- machine interaction over a network. It has an interface described in a machine- processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” [101] This definition allows for loose coupling, which is one of the characteristics of SOA. Web services should use web related standards and describe themselves. Because of this a web service can be accessed trough a network (the term used for accessing a 6 SOAP used to be an acronym and denote Simple Object Access Protocol but since version 1.2 this is no longer the case see http://www.w3.org/2000/xp/Group/1/06/f2f-pminutes for more information.

Service-Oriented Architectures 13 service through a network is invocation [29][45]). In addition, use of standard protocols and the description allow for loose coupling and machine-to-machine interaction. Web services provide access to applications (and/or other Web services). I would like to stress that web services are not obligatory for SOA, but seem to be the technology that has the capabilities to implement SOA [49]. Web Services Description Language Web Services Description Language (WSDL) [103] described the service interface. The description contains two aspects of the service. Firstly, its signature and secondly information about binding and deployment details. This information is described with XML. Examples of information are data types used by the servic or the address (URI) of the service [55]. SOAP W3C maintains the SOAP protocol [104]. SOAP provides a definition of XML-based information that can be used to exchange information between entities in a decentralized distributed environment. A SOAP message provides a one-way message transmission between SOAP senders and SOAP receivers. Another element called the SOAP node takes care of the transmission, receiving, processing and relaying of a SOAP message. The SOAP message (also called the envelope) contains an optional SOAP header and the mandatory SOAP body. The SOAP header can provide information that is not part of the information that has to be exchanged. For example, contextual information related to the processing of the message. The SOAP body contains the real information that has to be exchanged. Universal Description Discovery and Integration Universal Description Discovery and Integration (UDDI) is an open standard sponsored by OASIS [85]. The aim of UDDI is to provide information about services that can be used by potential users to access web services. UDDI acts as a directory service that contains service publications. The idea is that services can dynamically locate other services without human intervention. To achieve this, UDDI relies heavily on the WDSL published by the service provider. [55] claims that UDDI is not used that much in practice, since it is too difficult to maintain.

Service-Oriented Architectures 14 Enterprise Service Bus The Enterprise Service Bus (ESB) provides a standard-based infrastructure to enable communications between services. The idea with ESB is to provide the means to loosely couple the services and to separate the integration logic from specific application into one manageable place. The ESB would allow services that reside on different platforms and are written with different programming languages to communicate. To do so the ESB not only provides the means to transport messages from one service to another but can also transform these messages. The ESB can be seen as the backbone of any SOA. This means that it also is a logical place to apply for instance security, policy, accounting and reliability in SOA [30]. Web Services Business Process Execution Language Web Services Business Process Execution Language (WS-BPEL or BPEL4WS) is maintained by OASIS [88]. Business processes can be composed of different calls to specific Web services. With WS-BPEL the order in which specific services are called can be controlled. This is referred to as (service) orchestration. WS-BPEL supports two types of business processes: 1. Executable processes Executable processes specify the exact details of business processes and are executed by a BPEL engine. 2. Abstract business process An abstract business process specifies the public message exchange between the client and the service (the interaction protocol). The benefit of WS-BPEL is that it allows business processes to be changed just by adjusting the WS-BPEL file. Figure 5 (from [21]) shows an example of a WS-BPEL process. Service A wants to consume a service B in the other enterprise. Data send between A and B is in the form of a SOAP document. Service B is a business process and uses service C and D. Service A does not care what happened behind service B just as long as it does what is should do. If service B wants to adjust the process by replacing service B with service E (not displayed), they can do by changing the WS- BPEL file. Service A will not notice any change.

Service-Oriented Architectures 15 Figure 5 Service orchestration 1.5 SOA layers The purpose of SOA layers is to provide a level of abstraction, to understand SOA. In other words, it shows the conceptual structure of services in SOA. Each layer in SOA contains different services. The description of SOA usually some description of the abstract layers in which SOA is divided. Table 2shows different layers that can be found in the literature. This table is not exhaustive, I merely noted the layers from articles and books that I used for this thesis. Table 2 Comparison of SOA layers Krafzig [56] IBM [79] Erl [49] Newcomer [59] Enterprise Presentation Business process Business process layer Process Business Process Service Interface Services layer Choreography Intermediary Services Application Application layer Basic Enterprise Technology layer components Operational systems Explanation of SOA layers The layers of SOA Table 2, contains several layers. I have chosen not to summarize how each of the different sources describes the layers but summarize the layers into

Service-Oriented Architectures 16 common layers. Because there is no agreed upon set of names for the layers I have called these presentation layer, business process layer, service layer and application layer. Presentation Layer The presentation layer contains the application front-ends and services. These provide access to the SOA, and provide communication between end users and the SOA. Note that access is provided for business-to-business situation, next to the users within an organization. Business Process Layer The business process layer contains services that contain a full business process. These services are composed with WS-BPEL and the services of the services layer. Services Layer The services layer contains the services that provide access to internal applications and data. The services layer also contains proxies that can access services that other companies have in the presentation layer. Different stakeholders use the services in this layer; therefore, they should be as generic as possible, without being redundant. Application Layer The application layer contains the applications of an organization. Some sources also include the data stores in this layer. The applications provide the organization with some sort of functionality (e.g. keep all financial data in a database). 1.6 Benefits and drawbacks Reuse of applications / systems SOA provides means to integrate the divers set of applications and systems by allowing access through services. Normally applications and systems had to be adapted so only these two applications could work together. With the use of SOA this should be prevented. Another possible benefit of this reuse is that some of the applications have been tested for several years and know to be working. That being said, traditional system could require an interface that enables for instance access to the system through web services.

Service-Oriented Architectures 17 Standardization in the organization To improve reuse of services, an organization has to standardize information that is used by the service clients (either organizational or inter-organizational). The information used should be semantically identical, so miscommunication is reduced [60]. Because of this, SOA can has a large factor to drive standardization in the organization. SOA also implies the use of standards for the implementation of SOA. This should create a wide platform for interoperability between different systems and between departments and organizations. Technological standardization Several standards (such as SAML, XACML, XML, and HTTP) can be used in a SOA. By using these standards, it becomes possible to exchange services (or business processes) within the organization and between organizations [42]. On the other hand, as Tanenbaum put it: “the nice thing about standards is that there are so many of them to choose from” [69]. This is also the case for Web services standards. Therefore, the use of standards can possibly go very wrong when these standards do not interoperate. In addition, version changes between standards could pose interoperability problems. 1.7 SOA versus Other Concepts During talks with architects and other people in the research field, SOA is sometimes compared to other technologies or architectural styles. This can be confusing. Therefore, this section will provide a comparison between SOA and other concepts. The choice of concepts is made arbitrarily by me and is by no means an exhaustive. Enterprise Application Integration A typical (large) enterprise has tens, if not hundreds of (legacy) applications that support the business processes [4][50][56]. Maintaining these applications can be expensive, and updating these applications for new requirements (due to changes in business environment) can prove to be difficult [11]. Also providing services or information to customers based on different applications (or sources) can be difficult [28]. When for instance the enterprises sales system cannot communicate with the production-scheduling system, manufacturing and customer responsiveness suffer [4]. To fulfil these new requirements an enterprise can opt for developing new applications, which can be very expensive. Another solution to meet the new

Service-Oriented Architectures 18 requirements is to reuse the functionality of the existing applications. To do this, applications needed to be integrated manually, which lead to dedicated point-to-point (P2P) connections between applications. Besides being time-consuming and expensive, this also meant that only the integrated applications could communicate [28]. If the source or target systems changed, the integration would no longer be correct and code adjustments had to take place [20]. During the 1990s a solution to application integration was proposed in the form of Enterprise Application Integration which Lee et al., [20] define as: “a business computing term for plans, methods, and tools aimed at modernizing, consolidating, and coordinating the overall computer functionality in an enterprise”. In practice, this meant that an EAI solution used special middleware to consolidate, modernize and coordinate the overall computer functionality. The middleware solution serves as sort of a bridge between the two applications, and thus preventing P2P connections between two applications. Figure 6 shows an example of a basic EAI architecture [20]. Here the middleware solution provides a common interface for applications to communicate. When a new application is deployed it just has to be adjusted to work with the middleware, instead of directly with the other applications. Application services EAI Middleware solution Web applications Database services Figure 6 EAI The middleware solution used in EAI can (just like SOA), use Web services [11] to provide integration between other standard based applications [28]. EAI as a concept is pull-oriented, which means that the existing applications and business processes are used as the basis for future functionalities of the enterprise [20]. The same approach is used in SOA. Existing applications can be made accessible as services, to allow new functionality or development of business processes. So what is the difference between SOA and EAI? The difference is that the services that are created in SOA can be reused by other services or in business processes without any additional adjustments (recoding), which will be necessary with EAI. In SOA

Service-Oriented Architectures 19 developers can just discover services and incorporate these in a new business process [28]. EAI on the other hand is more concerned with integration of applications and in effect about integration of data. Enterprise Resource Planning Enterprise Resource Planning (ERP) is an enterprise wide software system that is designed to streamline data flow between different functions (human resource management, material management, finance) [24] in an organization [20]. It supports the business processes of an organization through strategic planning of applications, instead of providing for IT solutions alone [56]. ERP requires companies to reengineer their business processes to fit the best practise processes that the ERP defines. These best practises can be a serious limitation for some organizations that have unique business processes [4]. Adjusting the business processes for changes in the business environment requires flexibility in ERP solution, which is something that is not supported well [20]. Reengineering of business processes in ERP requires a substantial amount of time and financial commitment [4][20]. On the other hand implementing an ERP in an organization helps the company to think about the business processes. When implementing an ERP solution a company can get into vendor lock-in 7 with an ERP provider. If the implementation of SOA is based on standards, an enterprise can change vendors as long as the new vendor also supports these standards. Enterprise Service Bus The enterprise service bus (ESB) provides service consumers and service providers the means to communicate. It does this by providing a generic interface to services just like the middleware layer that is used in EAI. In fact, the ESB can be the middleware layer of EAI. The difference between other middleware solutions is that the ESB uses (if possible) standards in order to provide the integration [46] between applications. The ESB however treats these applications as services [29]. Some of these standards are XML, SOAP, WSDL, and WS-Policy. Next to this, the ESB can also provide a service that helps to find services (service registry), communication service and an orchestration service. The communication service provides communication between services and the orchestration service can 7 Some open source ERP systems could potentially prevent vendor lock-in such as Compiere and ERP5.

Service-Oriented Architectures 20 compose new service by using existing services. This is usually achieved by using a Business Process Execution Language (BPEL) [29]. SOA and ESB thus are completely different concepts. SOA defines characteristics and concepts for the software architecture while an ESB is a technical solution that provides features to implement SOA in the organization. Object Oriented Programming This section gives a quick overview of the main concepts of the object-oriented paradigm. Object Oriented Programming (OOP) has its roots in the Simula language, which was proposed in the 1960s [26][44]. Smalltalk, which was developed in the 1970s by Xerox Parc in Paolo Alto, was the first programming language that was fully object oriented [42]. In object-oriented programming, the flow of a program is based on message exchange between objects. A message can be either data or an event that has occurred [68]. Objects represent abstract concepts of a specific problem domain. The object contains data (the state of the object) and operations that are available on a specific object. The encapsulation of both data and operations (should) allow for code reuse, tolerance to change and decrease in errors because of data hiding and encapsulation It is also claimed that OOP provides a more natural way in which a problem domain can be modelled [17][68]. OOP and SOA use concepts that are interrelated. Both an object and a service are fundamental building blocks that are part of a specific problem domain. Both service and object hide information from the external entities, and implementation of both object and service can be changed without affecting the external entities. OOP however focuses on the implementation (programming) of individual software components, SOA on the other hand is about integration and assembly of these software components [89]. OOP encapsulates both data and operations on a specific object while SOA often assumes data and operations (or functionalities) are separated [56]. Component based development In component-based development (CBD) a component can be seen as “a non-trivial, nearly independent and replaceable part of a system that fulfils a clear function in the context of a well defined architecture” [17]. Another source [68] defines the properties of a component as the following: 1. a unit of independent deployment 2. a unit of third party composition

Service-Oriented Architectures 21 3. no externally observable state When comparing the above list to the properties of a service in SOA, it is hard to separate SBD and SOA from each other. Components in CBD can be composed of other components just as services in SOA can be combined from other services. The only difference is that CBD is concerned with software components where SOA is more concerned with business services [25]. This also means that reuse is working on a different level of abstraction. 1.8 Conclusion The basic SOA contains the service client, the service registry and the service provider. Beneath these concepts is the notion of a service. This basic SOA will be used in Chapter 2 to create a model for secure SOA. Web services form the basis of the technical implementation of SOA, and take the role of both service consumer and service provider. WSDL describes a particular web services, as such that it can be found in the UDDI. Messages between Web services use the SOAP standard. The comparisons that were made in section 1.7 are just a small set of possible comparisons that can be made. These concepts where chosen because in my opinion they can cause confusion with SOA. This is because there are similarities between SOA and OO and CBD. All aim at reuse and at strictly separated elements that can be replaced or adjusted without affecting other elements. SOA, EAI and ERP hope to integrate applications throughout an organization. ESB is a method to achieve such application integration. 1.9 Further reading In [21] an explanation provided why a service is not another term for component, interface or business process. A service can be viewed from a consumer, business, technical and provider viewpoint [32]. The business view of service can also be found in [77]. In this view a client will consume a service when the “cost” of the service is lower than the cost of executing the service. For a service provider the total cost of providing the service should be lower than the number of times the service is used times the reward from a client in a specified timeframe.

SOA security 22 Chapter 2 Security 2.1 Introduction This chapter introduces the concept of security, and the security principles that will be used in this thesis. This chapter provides (together with Chapter 1) the foundation for SOA security. The first section describes what security is in this thesis, followed by the different types of security that exist, and which ones will be used in this thesis. This is followed by a description of the basic security principles and additional principles that supplement these basic principles. 2.2 What is security? According to [106] security can be defined as: se·cu·ri·ty 1 : the quality or state of being secure : as a : freedom from danger : SAFETY b : freedom from fear or anxiety c : freedom from the prospect of being laid off <job security> 2 a : something given, deposited, or pledged to make certain the fulfilment of an obligation b : SURETY 3 : an instrument of investment in the form of a document (as a stock certificate or bond) providing evidence of its ownership 4 a : something that secures : PROTECTION b (1) : measures taken to guard against espionage or sabotage, crime, attack, or escape (2) : an organization or department whose task is security The security that is important in this thesis is that of “quality or state of being secure”. Security thus involves being secure, which according to [107] is defined as: se·cure Etymology: Latin securus safe, secure, from se without + cura care -- more at SUICIDE 1 a archaic : unwisely free from fear or distrust : OVERCONFIDENT b : easy in mind : CONFIDENT c : assured in opinion or expectation : having no doubt 2 a : free from danger b : free from risk of loss c : affording safety <a secure hideaway> d : TRUSTWORTHY, DEPENDABLE <a secure foundation> 3 : ASSURED 1 <a secure victory> Based on the above definitions, the term “security” is still relative. It will be clear when it is interpreted as an attribute of something that is considered valuable, for instance security of credit card data. The credit card data in this case, is a valuable resource that is at some sort of risk and needs to be secured. The level of security

Security 23 depends on how valuable, and how much at risk the resource is [65]. Security on a practical level revolves around protection of valuable resources against various attacks. 2.3 Security types According to [27] security can be divided into three different types: 1) hardware security, 2) information security and 3) administration security. Hardware security involves physical security of hardware. Information security involves computer security and communication security. Administration security involves personnel and operation security. This thesis revolves around the issue of information security. Sometimes computer security is also addressed as information security. This thesis adopts the views of [18][27]. Therein, information security covers all possible forms of information processing and storage, and in effect is about computer and communication security. By limiting the scope to information security, this thesis will address technical aspects only. However, security is not just a technical problem. The human element in security makes it both a social and organizational problem [6]. However, the scope of the thesis only requires a technical orientation. The word security will be analogous to information security for the rest of this thesis. The following two sections describing computer security and communications security deal with confidentiality, integrity and availability. These are described in section 2.5. Computer Security Computer security is an issue that can be defined in several ways. The definition chosen in this thesis is: The protection afforded to an automated information system in order to attain the applicable objectives of preserving the integrity, availability and confidentiality of information system resources (includes hardware, software, firmware, information/data, and telecommunications)[53]. Computer security should protect against attacks that exploit vulnerabilities in the security architecture [27]. For this thesis, computer security is synonymous to computer system security [57]. Computer security should provide for at least the basic security principles. Confidentiality in this case means that data in the computer system is only available for authorized entities. Integrity means that data within the computer system is not altered or destroyed by unauthorized entities. Availability

Security 24 means that the computer system can respond to authorized access request within a predefined timeframe. Communications security Communications security protects a resource against a possible adversary during transportation. This transportation is not only between two systems but also within one system. Among other things, an adversary can modify, retransmit, reorder or destroy information [27]. Therefore, communication security also deals with confidentiality, integrity. Integrity in communication security means that information is delivered exactly as it was intended to be delivered, and confidentiality means that the contents of the communication can only be seen by authorized entities [58]. 2.4 Security policy Security is established by creating a security policy. This contains written guidelines, which outline what steps to take and what procedures to follow in the pursuit of security [27][51][57][54]. A policy is typically a document that outlines specific requirements or rules that must be met. In the information/network security realm, policies are usually point-specific, covering a single area. For example, an access control policy would cover the restrictions on what operations can perform on objects [34]. Two different types of security policies are defined [51]: 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. In this thesis the system security policy is the main aspect. After a security policy is defined a specific security mechanism can be implemented that prevent a violation of the security policy. A potential violation of the security policy (and in effect security) is called a threat [27]. 2.5 Basic security principles There are some different view of security. This section will describe the most known security principles that can be found in CIA triad, Parkerian Hexad and RITE. Security in this context is seen as a property of computer and communication systems. There are also other sources that have a different view on security. For

Security 25 instance [1] and [27], claim that availability is not a property of security but of dependability. CIA triad The traditional view of security is based on the principles 8 of confidentiality, and integrity and availability [19][43][54][57][50][62][65][67]. These three principles combined are referred to as the CIA triad. One of the most important references, which also use the CIA triad, is the ISO 17799 Standard [54] 9 . This standard consists of recommended information security practices for information security management. Because this thesis is used in a business setting, I will adhere to the ISO standard, since this provides companies with a framework by which (information) security can be managed. As said before, security used in this thesis concerns information security. Therefore, in this thesis security is the preservation of confidentiality, integrity and availability of information (also see Figure 7 adapted from [62]). Confidentiality Confidentiality addresses the issue of preventing unauthorized use of access to system resources. This also means that resources should be hidden from unauthorized entities [43][49][62]. Availability Availability means that resources are accessible to authorized entities within a reasonable time [43][57][62]. Resources should also be accessible in a convenient format [57]. The opposite of availability, denial of service (DOS), is also a common concept in security, since DOS attacks can cripple the availability of a computer system [43]. Integrity Integrity ensures that a resource can be modified only by authorized entities [27][43][49][57][62]. Unauthorized entities might be able to access a resource but 8 A principle in this case is a basic truth, or assumption. http://wordnet.princeton.edu/perl/webwn?s=principle 9 The newest version of the ISO standard is ISO/IEC 27002, which is a revision of the ISO standard described here.

Security 26 security mechanisms should prevent modification of that resource. Modification is the act of making something different. If the resource is a data item for instance modification can include deleting and deleting (part of) the data item. Figure 7 Basic security elements. Figure 7 contains the three basic security elements RITE Dhillon et al., [6] proposes to expand the CIA triad with the security principles of Responsibility, Integrity, Trust and Ethicality (RITE). Responsibility means that there should be roles in an organization, and employees will take responsibility for that role (not only take the blame when something goes wrong). Integrity should also be seen as a requirement of membership. Members can breach security without even revealing that they have done so, for instance by sharing business sensitive information with relatives. Trust is needed in organizations where external control and supervision has been reduced. Members of the organization need to be trusted act in accordance with company norms. Ethicality refers to members of the organization handling in accordance with ethical practices. Regulations do not always apply, since they only work in situations that are foreseen and/or predictable. When this is not the case, ethical morals should take over. Parkerian Hexad Parker [61] proposes to replace the CIA triad with the Parkerian Hexad. The Parkerian Hexad is a framework consisting of the following security elements: availability, utility, integrity, authenticity, confidentiality and possession. Parker argues that the CIA principles are only enough to protect computer and network systems, instead of the application of these systems. People are the ones that misuse or abuse information potentially using computer and networks systems. Therefore,

Security 27 Parker proposes the principles to prevent people from doing so. One key point of the Parkerian Hexad is that the six principles do not have any overlap. If one of the security principles is not taken into account, the information losses attributed with this security principle could manifest. I will not go into great detail about the different security principles but the bullet list below contains a short description [61] 1. Availability Usability of information for a purpose. 2. Utility Usefulness of information for a purpose. 3. Integrity Completeness, wholeness, and readability of information and quality being unchanged from a previous state. 4. Authenticity Validity, conformance, and genuineness of information. 5. Confidentiality Limited observation and disclosure of knowledge. 6. Possession Holding, controlling, and having the ability to use information. Table 3 Comparison of security views CIA triad RITE Parkerian Hexad Confidentiality Confidentiality Confidentiality Integrity Integrity Integrity Availability Availability Availability Responsibility Authenticity Integrity Utility Trust Possession Ethicality 2.6 Additional security principles Next to the basic security principles of confidentiality, integrity and availability, additional security elements can be identified [18]. These principles supplement the security principles of the CIA triad in section 2.5. The need for additional security principles can arise if an organization is exposed to an environment that is not under direct control [56]. Among the additional security elements are authentication, authorization and non-repudiation.

Security 28 Authentication Authentication is the act of proofing that a claimed identity is true. Therefore, authentication also involves identification. Identification involves the act of claiming an identity. Identification is usually the first step in the authentication and authorization process [49]. Without authentication the basic security elements could not be implemented, since there is no way to determine if a resource has been altered by, or disclosed to, an authorized user. There are three ways to authenticate an identity [57][62][64]: 1. Knowledge based authentication Knowledge based revolves around the fact that there is some sort of knowledge that only the entity knows. This knowledge mostly has the form of a password. A password is a secret word or phrase known only to a restricted group 10 . The idea is that is an entity knows the password it must be member of the group (a single user can also be a group). 2. Token based authentication Something the entity has. An example of something that a person can have is a security badge, smartcard or a token. The idea is that if the entity has for instance a token, it must also have the claimed identity. 3. Biometric authentication Something the entity “is”. This can be applied to biometric (usually the entity is a person), examples include fingerprints, iris scans and hand print. Authorization Authorization is the process of granting an entity access to a specific resource. In other words, authorization determines to what extend authentication applies [49][56]. The result of an authorization process is either to allow or disallow access to a specific resource. Non-repudiation Communication security also has to make sure that an entity sending or receiving information cannot later deny having sent or received the information [65][27][42][57]. This also means that a neutral third entity can be convinced that the sender sent information and the receiver received the information [18]. 10 http://wordnet.princeton.edu/perl/webwn?s=password

Security 29 2.7 Conclusion Security as a concept can have different views. The basic security principles in this thesis concern confidentiality, availability and integrity. Next to this, the additional security principles of authentication, authorization and integrity are also described. This chapter also describes the different forms of security. In this thesis, the choice is made to only incorporate information security, which includes computer security and communication security. The security principles, which are described in this chapter, will be applied to basic SOA (Chapter 1) to create a model for secure SOA (Chapter 3). 2.8 Further reading Some sources, such as [1][27], introduce the notion of dependability. In this notion, security is closely related to the concept of dependability. Dependability is defined as the trustworthiness of a system and can be seen as the quality of the service a system offers [27]. In other words, the ability of the system to deliver a service that can justifiably be trusted [1]. Other concepts contained in dependability are reliability, safety, integrity, maintainability. Information about hardware security and administration security is described in [27].

SOA security 30 Chapter 3 SOA security This chapter will describe the security elements of SOA. First, a short description why SOA security is different will be provided. This will be followed by an overview of SOA security threats, and the security elements that can be used to prevent these threats. The last to sections will be used to describe the security elements that can be used in a WSOA. This chapter forms the basis of the security requirements for SOA reference model in chapter 5. Most of the sections are based on literature review. In some cases I have combined multiple sources into one section, thereby leaving out some parts of literature. 3.1 Why is SOA security different? IT professionals have always viewed security as a network perimeter issue [55]. Protecting the company network consisted of deploying firewalls and access control mechanisms. However, with SOA systems are integrated with those of with customers and business partners. This means that the edge of the company network is not where the company’s security ends. Another major problem is how to implement access control for a large number of different identities, who are outside the company’s security realm [41]. In the traditional security realm users are know before hand, and this is not always possible in SOA. In addition, since applications and application logic can be addressed through services, more data is exposed. This increase in data exposure can increase potential damage since very single service can be seen as a potential attacking point [91]. 3.2 SOA security threats This section provides an overview of threats of SOA security that can be found in the literature. This list is not exhaustive and these security threats are not exclusive to SOA. Threats to services Services will provide the means to interact with (legacy) applications and/or systems. Each service can in fact be seen as an possible point of attack. Security requirements of these systems can be different from the service client, it can also provide more

SOA security 31 functionalities. A service can for instance give access to desktop applications and custom applications that would normally not be accessible to a client. Providing authorization for standalone applications can be hard to manage [92]. If authorization is not managed correctly, access could be granted (or denied) to service clients that should not have access, thereby possibly accessing sensitive information. Differently from an application inside an organization, SOA (services) can also extend beyond the perimeters of the organization. Traditionally authorization is performed on the front-end of a system / application. In a basic SOA, a loosely coupled service does not have a coordinating service that provides security features. Moreover, the loose coupling predicts that none of the services is aware of its context. A resource that a service provides could require authentication/authorization. The service client must then provide the required information to authorize for that specific service. Because of the loose coupling of services, securing the confidentiality and integrity of the message could pose a problem. Traditionally transport level protocols (such as SSL/TLS) were used between two endpoints to maintain confidentiality and integrity. Since services are also location transparent, it is not possible to predict where the endpoints are and if they can be trusted. Therefore, instead of using transport-level security, message-level security should be employed [49]. Service registration / deregistration The service repository (which can be either within the organization security domain or outside) can be susceptible to replay attacks. An adversary could capture the registration or deregistration of a service and perform a replay attack. This replay attack could result in some sort of denial of service attack or registration of an (insecure) older service. An adversary could also perform an enumeration attack which allows the adversary to create an inventory of available services [2][35]. To prevent these attacks authentication, authorization, integrity and confidentiality must be maintained during registration and deregistration [2]. Use of standards Since SOA relies on standards, it is imperative that standards have an emphasize security. Standards used in SOA (mostly web services standards such as XML, SOAP, UDDI) do not emphasize security [55]. Some protocols enable security within these standards, such as SSL for HTTP and encryption for XML. An example where usage of standards can lead to problems is with firewalls. Most companies use firewalls

SOA security 32 that control all traffic from the external organization to the internal organization. When SOA is implemented using web services, HTTP and SSL are normally used. These protocols use TCP ports 80 and 443 that usually can pass-through the firewall [63][91]. Therefore, additional security features have to be implemented to prevent possible threats. Services require a description language to describe what the service offers and what it requires. (One of these description languages commonly used in SOA is the Web services description language WSDL). Description languages should use open standards to have full compatibility with potential service consumers. The open standards also allow a possible adversary to scan for vulnerabilities in the service. Using standards alone does not provide a secure SOA [80][92]. 3.3 SOA Security elements In order to have a secure SOA if have assumes that the basic security principles, confidentiality, integrity, availability (CIA) should hold. In addition, security principles such as authentication, authorization, auditing and non-repudiation can be needed. I have tried to create a set of elements from the literature that will satisfy these principles. Secure interaction Interaction between a service client and service provider should be secure to prevent threats. Secure in this case means confidentiality, integrity, non-repudiation and authentication of messages between a service provider and service consumer [84]. One way to have secure interaction is to set up a private connection between service client and service provider. Commonly this process is known as transport level security (TLS). However, using TLS is SOA will not be a viable option when there are intermediaries (such as ESB, or service providers) involved. TLS encrypts everything, not just the data that is important, that way it can increase the load on systems that need to encrypt messages. Also important is that it cannot be routed easily [33][84]. If there is some sort of intermediary, the security context only from service consumer to intermediary and from intermediary to service provider, not from service consumer to service provider (Figure 8). A message is therefore encrypted at the service consumer, send to the intermediary who decrypts and encrypts the message again, before it finally arrives at the service provider (or vice versa). This means that the intermediary can read all the data, which is not always allowed or preferred.

SOA security 33 Figure 8 Transport level security Message-level security can be solution. Message level security ensures a message is protected throughout communication of the message [91][95]. This means that confidentiality and integrity of the message is protected all the way from message sender to message receiver. Security context Service Service Intermediary Consumer provider Figure 9 Message level security Another interaction that should be secure is that of registration and deregistration of a service provider in a service registry. Only authorized services should be able to register with the service repository. During registration, the integrity of the service and confidentiality of the service repository should be maintained. Responses of a service provider to a service client should always be confidential, to prevent an adversary from building a list of services and their responses. The interaction between a service and a service client should have mutual authentication. Another important part of secure interaction is to maintain the integrity of the service provider and service registry. If the service client interacts with either of these, it has to be sure that the service has not been compromised, and is the service that the client was expecting. Distributed identities The basis of both authentication and authorization are (distributed) identities. Access to resources can differ greatly from identity to identity. For instance, discovery of services published in the service registry should be limited to specific service clients (this can be both an issue of Quality of service and security). For instance some services should not be accessible to the marketing department, and should not be discovered [31][33].

SOA security 34 Services can be built upon (legacy) applications. These applications can have their own authentication and authorization processes. Managing identities across all the applications can be a difficult task. Therefore, the SOA security model should have distributed identities that can be used across all of the services and applications. Federated Identity Management (FIM) is a solution for the management for identities [91]. Achieving single sign-on is the goal that distributed identities hopes 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 it identity again. Distributed identities are not only assigned to the service client, but also to the service registry and service provider. This identity can be used to maintain the integrity of the service registry and service provider. There can be a difference between identity of a service and service client. The service itself is not required to have an identity because it can impersonate (propagate) the identity of a client. The service client must always have an identity (presuming anonymous access is never allowed). Distributed policies These policies define the rules that authorize a service client to access a service provider. These policies should be able to take into account a specific context and the identity of a service client [92]. The policy defines what an authenticated identity is authorized to do. In addition, policies can be created that define when a service provider can no longer handle any more service clients. This aids in maintaining the availability of the service provider. Other policies that can be created are trust polices. Trust policies help manage the security in SOA. A service client can be from any specific domain. A domain can for instance be an organization or a department of the organization. Incorporating “all” domains is unmanageable. Therefore, a service provider could use trust relationships with other service providers to trust other service clients. For instance service provider A has a trust relationship with service provider B. Service B trusts service client C. Service A can therefore choose to also trust C. Trust policies can however be hard to implement since trust relationships between interdepartmental and inter- organizational can differ. Distributed policies can only authorize a service client if it provides an (distributed) identity.

SOA security 35 Table 4 provides an overview of what the different SOA security elements provide in terms of security principles. Table 4 Security principles mapped to SOA security elements Secure Interaction Distributed identities Distributed policies Confidentiality x Integrity x x Availability Authentication x x Authorization x x Non-repudiation x x Model for the secure SOA If we look at Figure 1: Basic SOA we can now add the security elements of the previous sections to it. This produces the model in Figure 10 (adapted from [73][94]) for a secure SOA. This is not a model for an implementation of a SOA. When implementing SOA, one should implement a security system that takes care of all the policies, manages the identities and provides secure interaction. Secure interaction Service Provider Interact Publish Distributed identies Distributed policies Service Registry Find Service Client Distributed identities Distributed identities Distributed policies Distrbuted Policies Figure 10 Model for secure SOA 3.4 WSOA and security As described in section 1.4, the common implementation of SOA is with web services. So what holds for the security of SOA in general should also hold for WSOA. This section will show how security of WSOA can be achieved with the standards that are available at this time. Although availability is mentioned as a security principle, there are no specific standards that can help keeping services

SOA security 36 available. In practice, it is nearly impossible to protect against for instance denial of service attacks. Authentication can play a role, by not allowing unauthenticated access. However, this still cannot protect against DOS attacks. Because the lack of standards, availability will not be addressed throughout the rest of this section. Secure Interaction Secure interaction in the case of WSOA is about security of SOAP messages. SOAP(1.2) does not contain any means for authentication (such as context or passing of credentials). There are three common ways to secure messages between services. 1. HTTP with TLS (HTTPS) [97] 2. XML encryption and XML signature [99] 3. WS-Security [86] These three will be described in the following sections. HTTP with TLS (HTTPS) TLS is maintained by the IETF [97]. HTTPS is the common name for a secure HTTP connection. HTTPS is not a separate protocol from HTTP but it is HTTP run over a TLS connection (TLS used to be SSL, hence the name HTTPS). There is a different protocol called S-HTTP that is in fact a modified version of the HTTP protocol. This section will only concern the TLS protocol. TLS creates sort of tunnel between a client and a server. Data send through this tunnel is encrypted. Thereby also the server side is authenticated. In some cases two-way TLS is used, whereby both the server and client are authenticated. Since TLS is a transport level protocol, it does not protect individual messages, but only the transportation of these messages. Messages (such as XML documents) are not secure after they leave the TLS tunnel [15]. XML Digital Signature and XML Encryption XML signature (XML-SIG) is a W3C recommended standard for creating XML-based digital signatures for any type of data (including XML). The data (or just part of the data) is signed by using the sender’s digital signature. The digital signed data can be located within the same document as the signature (enveloping signature Figure 11), the signature and signed data can be part of the data document (enveloped signature Figure 12), or it can be located on a remote URI (detached signature Figure 13).

SOA security 37 Figure 11 Enveloping signature Figure 12 Enveloped signature Figure 13 Detached signature The digital signature can use any available signature algorithm. The signature itself is in the form of a digest that in turn can also be encrypted with the receiver’s public key. XML Signatures provide integrity, message authentication, and/or signer authentication. With message authentication both the sender and receiver of the message share a secret key to create a message authentication code (MAC). Both sender and receiver can validate this MAC, thus providing message integrity and authentication. Signer authentication can be achieved by using digital signatures, which also introduces message integrity and non-reputability [65][99]. XML Encryption (XML-ENC) is a W3C recommended standard that defines the process and format to encrypt data and represent the result in XML. XML-ENC supports the encryption of an entire XML document or just a part of it. There are three different ways to encrypt the XML data: 1. Symmetric key.

SOA security 38 2. Asymmetric key. 3. Via third party certificate (such as X.509). When data is send (encrypted), confidentiality of data is preserved. WS-Security WS-Security is a set of SOAP extensions that can be used to secure SOAP messages and is maintained by OASIS [86]. It has three mechanisms to achieve SOAP message security: 1. Security tokens in the header of SOAP messages that are used for identification and authentication. 2. XML Digital Signature (XML-SIG) to provide SOAP message integrity and authenticity 3. XML-Encryption (XML-ENC) to keep SOAP message confidentiality. A description of XML-SIG and XML-ENC can be found in the section XML Digital Signature and XML Encryption. Security Tokens A Web service can require an entity to provide proof of claims that it makes. A claim is a statement that is made by an entity itself or by another entity concerning a specific entity. Security tokens are a collection of claims [2]. WS-Security defines how to use these tokens in the header of a SOAP message. The WS-Security header defines three different types of security tokens; username, binary, and XML security tokens. 1. Username token The username token is the most basic security token in WS-Security. The username is represented in an unsigned XML description. Because it is just in plain text, this is not the most safe security token available [92]. 2. Binary security tokens X5.09 digital certificates and Kerberos are binary security tokens that are encoded as binary and represented in XML. This type of security token can be integrated with existing solutions that manage identities (such as PKI, LDAP and Active Directory). This allows for a flexible infrastructure because it allows propagation of identity credentials through several systems [92]. 3. XML security tokens WS-Security provides an XML based security token. This security token is SAML. WS-Security provides the framework to bind SAML tokens to SOAP messages.

SOA security 39 SAML can define authorization and authentication statements, and signed messaging of XML [56]. When SAML is used it presumes that some third party service will assert the correctness of the claims made within the SAML. To be able to do so SAML includes the notion of three different types of assertions, which are issued by assertion providers. The three assertions are; authentication, authorization and attributes. An entity can request a security assertion from an assertion provider. The assertion provider will provide the entity with an assertion that contains a timestamp, an assertion ID, and the subject of the assertion. For example, an authentication assertion is a representation by a third party that a specific entity has been authenticated. WS-SecureConversation Security standards like WS-Security and WS-Trust can make the IT systems more complex. Since both standards increase the computational effort, it can cripple the whole SOA. Then a trade-off between security and business performance has to be made. This is where WS-SecureConversation [87] comes in. WS-SecureConversation adds multiple messages to be exchanged between web services using the same context, which is better from a resource usage stance. This also means that not every message has its own full security context. In a way, WS-SecureConversation tries to mimic TLS by providing “secure tunnel” between two services. The WS- SecureConversation uses WS-Trust to create a Security Context Token (SCT). This SCT is passed with every message instead of a normal security token that has to be checked every single time. SCT become invalid after a number of messages, a specific amount of time and can be renewed. Distributed identities and distributed polices Distributed identities can be used to authenticate different service consumers from different security domains. Some authorization infrastructure is needed to achieve this. There are several solution to this, for instance RBAC and ABAC. The process that an authorization infrastructure supports is called access control. Access control is based on two prerequisites. First, an authentication process has to validate claims made by an entity and second an authorization process has to validate if an entity is authorized to invoke a Web service [9]. According to [56] authentication in SOA is performed on three different levels. The first is against specific applications / databases (front-end). This type of authentication usually revolves around a user entering a username and password and

SOA security 40 aims to protect the application itself. The second type is authentication against services. Access to services is often required and authentication can also provide auditing. Authenticating an entity on every access of a Web service can reduce quality of service and increased difficulty in administration. The third type concerns authentication against the SOA framework. This type of authentication should solve the administrative problems of authentication against services. In this case the user will be authenticated against the infrastructure and not against individual services. If the authentication mechanism changes, it has no effect on any of the services. The aim is to separate the service implementation from the changes in the authentication mechanism. Like authentication, authorization can be performed at different levels, the application front-end, the services and the SOA framework. Authorisation at the application poses a problem because it will provide no means to authorize at the services. Also administration of policies (what entity has access to what en possibly when) becomes difficult because it has to be propagated (mirrored) to all the applications. To achieve this kind of access control [9] proposes an Identity Management (IdM) architecture, which can be used in WSOA setting. This IdM will be described in the following section. Identity Management architecture WSDL/SOAP Authorization Authentication Administration Policy Security User / Service / Decision Token Policy Point Service Administration User Token Policy Service Directory Repository Store Registry Figure 14 Identity management structure adapted from [9] Figure 14 displays the WSOA aware IdM architecture. This infrastructure uses an access control model called Attribute Based Access Control. In this model there are

SOA security 41 Attribute Authorities (AA), which are responsible for creating and managing the attributed for subjects, resources and the environment. For instance, the subject resources can be extracted from an LDAP directory [41]. See also the section about Attribute Based Access Control. The policy decision point (PDP) evaluates policies and makes authorization decision. An entity can be authorized to use a service in a more general way or in a specific way where an entity is only allowed to receive a part of the for instance the data that a service can provide. The authorization decision uses several parameters on which it will base the authorization decision. The PDP uses XACML policies, which are stored in the policy store as XML files. For more information, see section eXtensible Access Control Markup Language. The authorization follows the secure service agent (SSA) security pattern. This pattern is a combination and enhancement of the Secure Service Proxy (SSP) and the Intercepting Web Agent [7]. SSA enforces the authorization request. It does so by introducing an Policy Enforcement Point. What the policy enforcement point basically does is intercept the request to a specific service and ask the PDP if a specific service consumer can access the requested Web service. The security token service validates the claimed identity of the service consumer [8][33]. It does this by checking the claimed identity in a user directory. After a user is authenticated, this token is stored in a token repository. The user directory can be any LDAP based directory (such as Microsoft Active Directory), the token repository is best implemented with a relational database (e.g. MySQL, SQL). The service registry can be implemented with UDDI. eXtensible Access Control Markup Language eXtensible Access Control Markup Language (XACML) is a standard approved by OASIS [90]. Its aim is to provide exchange of access control policy information in an XML format. XACML can describe attribute based authorisation rules and policies. Furthermore, it specifies rules to process and combine these authorisation rules and policies. XAMCL entities comprise of a Policy Enforcement Point (PEP), a Policy Decision Point (PDP), a Policy Information Point (PIP) and a Policy Administration Point (PAP). XACML is combined with SAML, which can describe security information that is communicated between entities and domains [36]. XACML supports authorization and can be used in Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC). XACML can define attributes

SOA security 42 that can be used in combination with LDAP-1 and LDAP-2 [90]. In this case, it is not the claimed identity that is used for the authorisation, but the role that the entity has. Another option is to authorize on resource instead of on the identity. Role Based Access Control The RBAC model uses the role of an entity to restrict access to a specific resource. Entities are grouped in specific with specific permissions. RBAC reduces the overhead that would otherwise be needed to assign permissions to a single entity [41]. A common RBAC solution is Microsoft’s Active Directory. With RBAC, each entity will have a role (or even more that one role). This poses a problem in SOA, because it is not know which entity will consume a (web) service. Attribute Based Access Control Attribute Based Access Control (ABAC) is designed to define permissions to attributes. ABAC consist of two aspects 1) the policy model and 2) the architecture model. The former defines the ABAC policies while the latter applies these policies to web services access control. The policy model concerns three types of attributes [36][41]. 1. Subject attributes These attributes define the identity and characteristics of the subject. These attributes can be static like the entity’s role in the organization or dynamic such as the age of the entity. 2. Resource attributes These attributes make it possible for access control decisions to be performed. These attributes can be seen as metadata (such as title or author of a document). 3. Environment attributes. These attributes describe the operational, technical, and even situational environment or context in which the access occurs. 3.5 Conclusion The security threats of SOA include threats to services in general. Services can provide functionalities to users that were not available before the service was in place. In addition, services can exist beyond the organization’s security perimeter. Since services use standards, a possible adversary can use flaws in these standards to attack the service. These threats prevented by introducing security principles into the SOA model. These principles include secure interaction, distributed identities

SOA security 43 and distributed policies. Secure interaction provides confidentiality and integrity of messages between service providers, service registry and the service client. Distributed identities are used as the basis to provide authentication, authorization, integrity and non-repudiation. Distributed policies are used for authorization and availability. A service client can be authorized to access a service provider, or can be authorized access the service registry. This model for SOA security forms the basis of the technical implementation of SOA that is described in Chapter 4. For authentication and authorization, you usually need an identity claim (which can be user ID and password or certificated etc.). Encryption and digital signatures on the other hand are used for confidentiality and integrity. Table 5 shows which security principles can be addressed with a specific security standard. Table 5 Standards in Secure SOA model SOA security element Security principle Security standards Secure interaction Confidentiality HTTP with TLS Integrity WS-Security Non-repudiation XML signature and XML Encryption XML Signature Distributed identities Integrity XACML Authentication WS-Security tokens Authorization RBAC / ABAC / LDAP HTTP with TLS X5.09 Distributed policies Authorization SAML 3.6 Further reading A list containing thirteen SOA security snares can be found in [23]. XML signature has some inherent flaws, a description of some flaws is described in [76][78] and in Appendix D. Another authorization architecture for web services can be found in [13], next to supporting web services authorization, it also supports the use of legacy applications. Currently this architecture is being implemented within the .NET framework.

SOA security 44 A description of common Web services threats can be found in Appendix E. Eric Yuan et al., [41] provide more information about access control mechanisms (such as RBAC, IBAC and MAC) and also introduce a more detailed ABAC policy formulation. Kleiner et al., [15] show how WS-Security protocols can be analysed by using Casper and FDR. Schlager et al., [36] have an in-depth description of the pros and cons of different AAI infrastructures. Several patterns for Service-Oriented information exchange requirements are described in [22].

Zwitserleven SOA 45 Chapter 4 Zwitserleven SOA 4.1 Introduction This chapter introduces the concepts behind the SOA that Zwitserleven wants to deploy. This chapter describes the design decisions of Zwitserleven and a description of the SOA layers within Zwitserleven. A description of the specific software solutions that are currently used, or will be used within Zwitserleven is provided in section 4.4. This section is used to create an overview of the security standards and protocols that are currently available to Zwitserleven. Part of the information in this chapter comes from discussions with Zwitserleven employees, which I then wrote done and approved with them. 4.2 Summary design documentation The following bullet list contains a short summary of the internal design documentation, with a short description (if necessary). Architects of Zwitserleven composed this list as the basis for the (new) SOA. The list is also used as input for the method to create viewpoints as described in [16]. Solutions / products should incorporate industry standards (such as SOAP, WSDL). Maximize reuse of (current and future) application functionality and business rules. Flexibility of business processes. Business processes should be flexible, this means that when a business process has to be adjusted it can be done without much effort. The idea is that changes in the market can easily be followed by changing existing business processes or introducing new business processes. Computerize manual labour. Zwitserleven has a lot of manual labour. In practice, documents are printed and serve as input other processes. In order to achieve cost reduction and efficiency more manual labour has to be computerized. Divide business into separate functional areas in order to achieve specialization and better management of departments. Zwitserleven want to create specific functional areas in the company that are

Zwitserleven SOA 46 highly specialized and can do certain jobs very well. Nowadays, different company divisions can do the same jobs and/or have the same responsibilities, which is not efficient. No migration of legacy applications. Legacy applications used by Zwitserleven should not be migrated into newer versions. These applications need to be taken out of production and their functionalities should be provided by (preferably) applications that can be invoked through a Web service. Reduce redundancy (or increase reuse) of data by integrating applications. This decision has a relation with not migrating legacy applications. Within Zwitserleven (legacy) applications more than one application contains the same data. In some situations this is due to compliance and auditing reasons. In other situations two applications are not integrated. These applications should be integrated in order to reduce redundancy en improve efficiency, maintainability and security. Integration of applications should be technology and supplier independent. There will always be some dependence on technology and on a specific supplier. However, this dependency can be decreased by using standard based integration techniques. By using standards, another supplier that uses these standards can also be used. 4.3 Zwitserleven SOA layers Figure 15 shows the layers that are defined in the Zwitserleven SOA. This section will describe each of these layers. Zwitserleven has chosen to implement SOA by means of a five-layer architecture with BEA as accompanying software product supplier.

Zwitserleven SOA 47 Presentation layer Process layer Integration layer Application layer Data layer Figure 15 Zwitserleven SOA layers Presentation layer The presentation layer interacts with the services in the process layer. It can for instance display the effects that a process has. The effects can take any form of representation, such as documents or web pages and use any data carrier that is available. Process layer The process layer models the business process. Orchestration of services will be performed by a specific application (also see section 4.4). The process layer directly supports the business process by providing process services. A process service can be composed of integration services or other process services. Next to this process services can also create some presentation for the user of the service. Integration layer The integration layer contains integration services. The aim of these integration services is to provide generalized services that can be consumed by process services. Each integration service can either be composed of application services, integration services or be connected to applications directly. Application layer This layer contains the applications and application services. Application services are built upon the applications. This means that (part of) the functionalities that an

Zwitserleven SOA 48 application has are available through the use of (web) services. The data of the applications is positioned in the data layer. Data layer This layer contains the data of Zwitserleven. Data is for the most part stored in databases. Opposed to the process, integration and application layer this layer does not contain any services. The application layer thus cannot consume data services. Therefore, there should always be a connection between data sources in the data layer and applications. Table 6 Zwitserleven layers compared to SOA layers SOA layers section 1.5 Zwitserleven layers Presentation Layer Presentation layer Process layer Business Process Layer Process layer Services Layer Integration layer Application layer Application layer Data layer As can be seen in Table 6 some layers within Zwitserleven provide functionality that in section 1.5 is addressed by a singe layer. Although officially the data layer is part of the Zwitserleven SOA, it is usually mentioned in one breadth with the application layer. Users of the Zwitserleven SOA Zwitserleven has envisioned three possible users of the Zwitserleven SOA. These need to be taken into account: 1. A user consumes a service within Zwitserleven through a web application or portal. This user will interact with services through the portal. 2. Another business accesses or is accessed by Zwitserleven (external service provider). If another business accesses Zwitserleven it will interact with the presentation layer. When an external service is accessed from Zwitserleven, it accesses this service from the integration layer. 3. An internal user uses ALBPM. An internal user should be able to directly interact with ALBPM. Zwitserleven has chosen to allow access to ALBPM through the presentation layer and through the process layer directly.

Zwitserleven SOA 49 4.4 Technical implementation of the SOA layers The layers described in section 4.3 are just conceptual. The technical solutions or products used to implement the layers are presented in Figure 16. The product used will be described (in short) in this section. All of the BEA products run on top of a specialized server product called Weblogic Server. There is no specific product on the data layer. Data is stored in a different databases. I did not mention these databases by name since it is outside the scope of this thesis to address them all. One important note however, at the time of this writing (2007) the area of SOA security is evolving. Standards are in the process of being completed or under development. Due to the moving area of development, parts of standards can be changed when you read this. Where possible final versions of standards are discussed, but not in detail. Specific details of security protocols are therefore limited. If a detailed approach is necessary, I advise the reader to research the latest versions. Figure 16 Technical implementation of the SOA layers BEA WebLogic Portal BEA Weblogic Portal (WLP) can be used to create portals. They idea behind WLP is that the information displayed in the portal is independent from the application logic of the specific service that is provided. By using tools available in WLP, portals can be created that are aimed at specific stakeholders. WLP uses specific components

Zwitserleven SOA 50 that can change how a webpage looks, or change the information that is displayed on the webpage. WLP supports two standards, Java Community Process’s JSR 168 and OASIS's Web Services for Remote Portlets (WSRP) 11 . JSR 168. BEA Aqualogic Business Process Management The process layer within Zwitserleven is where the business processes are created / composed. BEA Aqualogic Business Process Management (ALBPM) 12 is the software solution that Zwitserleven has chosen to perform the BPM. WS-BPEL is used to decompose Business Process Management (BPM) models into their (business) services. ALBPM is a Business Process Management System (BPMS). A BPMS is the technical platform for realizing BPM management. ALBPM includes the Business Process Execution Language for Web Services (BPEL4WS) and Business Process Modelling Language (BPML). BEA Aqualogic Service Bus 13 The BEA Aqualogic Service Bus (ALSB) is an ESB. It is designed for connecting, mediating, and managing interactions between services. These services can use different technologies such as Web services, Java, .Net. Next to services it can also be used to provide access to legacy application with for instance. An overview of the parts that exist within the ESB can be seen in Figure 17. This thesis will mainly concern the Security layer of ALSB. Transport security and WS-Security is addressed in 3.4. Console security is about managing which users can access the management console of the ALSB. Managing access to an instance of the software products is very important, but not an issue in this thesis. Access to the runtime resources of the product however is. Policy denotes the specific polices used to authorize users that are trying to access services that ALSB can provide access to. 11 http://www.bea.com/content/news_events/white_papers/BEA_Portal_Standards_ds.pdf 12 http://www.bea.com/content/news_events/white_papers/BEA_AquaLogic_BPM_Suite_ds.pdf 13 http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/aqualogic/servic e_bus/

Zwitserleven SOA 51 Figure 17 BEA Aqualogic Service Bus BEA Weblogic Integration The BEA Weblogic Integration (WLI) 14 product is aimed at integration of applications, processes and users. It does this through the use of specific components (which are standard based). By using these integration components interaction between for instance ERP systems, databases and applications can use messages to interact with each other. Figure 18 BEA Weblogic integration 14 http://www.bea.com/content/news_events/white_papers/BEA_WL_Integration92_ds.pdf

Zwitserleven SOA 52 BEA Aqualogic Enterprise Security 15 Aqualogic Enterprise Security (ALES) is a product of BEA currently not used by Zwitserleven, but efforts are underway for it to be used. ALES is the security suite of BEA. The goal of ALES is to provide a centralized security structure. By having centralized standard based (see Appendix F) security, management should be easier. ALES can also be used to separate the security from application logic. ALES has the following components: Administrative application o A browser based administrative console o An administrative server that manages storage and distribution of policies A set of policy decision points (PDPs) that can be deployed as either o A central entitlements server o Distributed decision points embedded in the applications Entitlement Storage o PDP can consume entitlements that are stored and managed by ALES or by a 3rd party 16 ALES can be linked in with the default security framework of Weblogic Server software. BEA introduces the notion of a Secure Service Module (SSM). This can be seen as a specialized form of PDP. There are some standard specialized SSM’s available. There are specialized SSM available for specific (Weblogic Server based) applications, a description of these can be found in Appendix F. ALES does not specifically need Weblogic server based application but can also be used with non- Weblogic based applications. For instance, ALES Java SSM can be installed on a Tomcat 5.x container and/or in a WebSphere Container 17 . The SSM contains the following components [70]: Authentication providers Authentication providers allow an entity to be authenticated. Authorization providers Authorization providers authorize authenticated entities for a specific resource. 15 http://www.bea.com/ales/ 16 http://eudownload.bea.com/de/events/arch2archsummit/2-Dave_Garrison_Security.pdf 17 http://dev2dev.bea.com/alenterprisesecurity/ssm/

Zwitserleven SOA 53 Credential mapping providers Credential mapping providers can transform one credential into another. For instance, create a SAML token for an already authenticated entity. Role mapping providers Role mapping providers supply the authorization provides with the specific role that an entity has for a specific resource. 4.5 Security standards used in BEA products To provide an overview of standards implemented in BEA products would be too broad for this thesis. It is however important to show which security standards the BEA products have implemented. The aim is to provide all the security standards that are described in section 3.5 Table 5. As can be seen in Table 7, ALES together with ALSB support the standards that are needed to secure SOA. I think it is important to mention that the level of implementation of the standards cannot be objectively determined by me. The information in Table 7 is determined by either reading background material, or representatives of BEA. Table 7 Security standards in BEA products BEA product Security standard ALES SAML 1.1 XACML 2.0 X.509 LDAP v3 TLS v1 and SSL ALSB WS-Security 1.0 XML-Signature XML-Encryption WS-Policy WS-Security: Username Token Profile 1.0 WS-Security: X.509 Token Profile 1.0 WS-Security: SAML Token Profile 1.0 4.6 Conclusion The layers described in the Zwitserleven SOA resemble the ones that are described in Chapter 1. Therefore, the Zwitserleven SOA should also be protected with the

Zwitserleven SOA 54 same security standards as WSOA. ALES and ALSB can provide all these security standards. I will use these products in Chapter 5 to secure the Zwitserleven SOA.

Reference model 55 Chapter 5 Reference model 5.1 Introduction As stated before, the aim of this thesis is to create a reference model for a secure SOA. This reference model contains an architecture description (AD) for the future IT architecture. In this case, it is aimed at providing insight into the security of the architecture. The AD documents the architecture. It documents the stakeholders, and addresses all of the stakeholders concerns for the new architecture. The AD is comprised of view(s), which represent the whole systems from a particular set of concerns. The viewpoint contains the structure of the view, and is declared beforehand, each viewpoint is the basis of one view. The views and viewpoints are influenced by the views put forward in [65]. A method for defining viewpoints according to IEEE standard 1471 can be found in [16]. This method will be used as the basic guideline for the viewpoint creation. 5.2 Reading guide This chapter contains multiple views, each aimed at different stakeholders. Table 8 shows which views are relevant for the different stakeholders. Table 8 View reading guide Deployment view Identity view Service view Architects d o s Security officer s d x System developers s o d Key: d = detailed information, s = some details, o = overview information, x = minimal information 5.3 View catalogue This section we will provide descriptions for the views. All views are aimed at showing security elements and/or principles next to the high-level overview of the system. The views have two names. I have done so because this made it more clearly for stakeholders at Zwitserleven.

Reference model 56 Deployment view / Architect’s view The architect’s view shows the high-level security elements. Most of these elements are displayed as functional elements, which can be reused in other situation. Next to the functional elements the specific software products is also mentioned. Identity view / Security officer’s view The identity view shows the security elements, and the global process of protecting the service consumer in terms of security principles. It also shows (on a conceptual level) where data should be stored, and where information security standards and/or guidelines will be effective or where they will be located and should be managed. Service view / Designer’s view The designer in this thesis is the one who translates the components of the architect’s view into real system objects. Security is represented with the logical security services and software solutions that are used. Technical details of how services should be implemented and different ways to do so are outside the scope of this thesis and that of the application coordinator and will not be shown. 5.4 View template The views are created based on the template put forward in [42], which contains seven elements that should be used when documenting a view. This thesis will use three of these elements to document the view. The variability guide is integrated with the rationale and contain references to architectural decisions. These decisions are described with the AK-SPAM method. These decisions contain alternatives and a rationale of the decision made. The three elements used in this thesis are, primary presentation, element catalogue 18 and variability guide / rationale. Primary presentation of the view. Shows the elements and the relationships among them that are presented in the view. It contains the primary elements and relations of the view, but under some circumstances it might not include all of them. The primary presentation is a graphical presentation that should help to get a quick overview. Element catalogue The element catalogue shows the elements that are depicted in the primary 18 Bas et al., uses the US English spelling, catalog, I will adhere to the UK English spelling, catalogue.

Reference model 57 presentation, and maybe others that should also be mentioned. It explains the purpose and role of each element that is given in the primary presentation. It also explains why these elements are they way they are (rationale). Architecture background Because I used the AK-SPAM method, the architectural background also contains the variability guide. The variability guide (or alternatives in AK-SPAM) shows variation points that could be available in the current view. The rationale is included in the rationale field of the AK-SPAM method. Sometimes the architecture background contains information that cannot be found in a specific decision. This is the case when some concern of stakeholder cannot be visualized in a primary presentation. 5.5 System overview The system overview provides an overview of the system as a whole. In this case it concerns the security elements that should be introduced within SOA. This system overview only describes several higher-level concepts that contribute to a secure SOA. Figure 19 shows these high-level elements (based on the security model in [91]). Service Enforcement Service consumer point provider Token Attribute Decision point authority Authority Policy Logging Authority (log files) Security elements Figure 19 System overview

Reference model 58 Elements Figure 20 Elements of system overview The service consumer (which can be another service, or for instance a user) consumes a service provided by a service provider (service provider). However not all service consumers are allowed to access a service provider. A specialized service acts as an enforcement point. The enforcement point enforces the service consumer to provide specific data (or information) which can enable the decision point to make a decision whether the service consumer may consume a service. The decision point is a specialized service designed to make decisions. To make the decision, the decision point is depending on other services to provide information. These elements are the attribute authority, policy authority and token authority. The policy authority contains policies that state whether a service client can access a specific service. The attribute authority can get more attributes for a specific service client in order for the decision point to be able to make a decision. The token authority maintains the identification information and can issue security tokens (or transform one token into another). The logging service can log actions that are performed at each of the authorities or the PDP/PEP. 5.6 Deployment view / Architects’ view Primary presentation The primary presentation is found in Figure 21.

Reference model 59 Figure 21 Primary presentation deployment view

Reference model 60 Element catalogue Symbol Name Explanation Functionality The functionality describes some sort of functionality that has a role in the security. Service This symbol identifies a specific service. In the case of Zwitserleven these services can be process services, integration services application services and business services. Communication The communication shows what elements of the Zwitserleven SOA are integrated together. Logical link The logical link described a logical link between elements. In this case it concerns the security module of Aqualogic Enterprise Security (ALES). User The user can be either a service consumer or a person. The user has some kind of interaction with the Zwitserleven SOA. Decision The decision symbol refers to a specific decision in Appendix C. Trusted zone Objects within the dotted lines are thought to be trusted. In this case trusted means that therein, no specific access control is available. Firewall Only allow access that is in accordance with firewall policy Architecture background Access to the internal network is only allowed through firewalls. The Demilitarized Zone (DMZ) is a special network area located between two firewalls. Within the DMZ is an implementation of ALSB. ALSB can be configured both as a reverse and forward proxy. It is a forward proxy when ALSB connects to a business service outside the DMZ, and a reverse proxy when a message from external service travels into the DMZ [71]. There are two implementations of ALSB available. The internal

Reference model 61 ALSB has both services for internal use and for external use. The ALSB in the DMZ has only a subset of the services, but can invoke services on the service bus. The internal ALSB decides which information to send to the ALSB in the DMZ. A user (person) can access Zwitserleven from the outside through a web server, and the user should manage users and policies in both ALES and Weblogic Security Service belonging to ALBPM. Glossary of terms Firewall A firewall separates to network domains from each other (usually internet and intranet). The firewall has the role to regulate network traffic flow between the two domains. The firewall should also have a specific firewall policy. This would specify what traffic is blocked and what can pass-through [65]. Demilitarized zone (DMZ) A demilitarized zone is a network area that sits between an organization’s internal network and an external network. 5.7 Service view / designers’ view Primary presentation The primary presentation of the service view can be found in Figure 22 3 5 ALSB 6 SOAP 5 SOAP client SAML SOAP Proxy Service Busines service SOAP SAML 7 SAML Web UN&PW Server 16 over SSL 5 Web client (IIS / apache) SAML 16 ALES 15 Security Administration Internal Service client Module 9 Authentication Authorization Credential Role mapping providers providers mapping providers providers Figure 22 Software engineer view

Reference model 62 Element catalogue Symbol Name Role/ function Service This symbol identifies a specific service. Service client The service client invokes some service that is available in the service bus. Software The software solution performs a specific solution role in the organization. Communication The communication shows what elements of the Zwitserleven SOA communicate. User The user communication shows where a communication user communicates with Zwitserleven SOA. Functionality A specific functionality of a software solution. Decision The decision symbol refers to a specific decision in Appendix C. Architecture background Each web service has a SOAP handler (Figure 23). The SOAP handler is a generic component in a web service. The SOAP handler intercepts SOAP messages from both the request and response of the Web Service. SOAP handlers can be created in both the Web Service itself and the client applications that invoke the Web Service. Before the SOAP handler of the proxy service invokes the real service implementation it first invokes a specific SSM of ALES.

Reference model 63 Figure 23 Web service with SOAP handler. One important thing to note is that ALES only protects the runtime components of ALSB, and for instance, not the ALSB console 19 . The proxy service located within the ALSB is one of the Web services with a SOAP handler. Business services can only be accessed through a proxy service. The internal client does not specifically need a secured messaging platform since it only uses the internal network and internal ALSB (see 5.6). Because security is managed through an ALES Security service module (SSM) the efficiency of (part of) the test- bug-fix cycle can be improved. This is because it is no longer necessary to test the security of a service in depth. However security of the interface from service to application and / or database still needs to be tested. 19 http://edocs.bea.com/ales/docs26/integrateappenviron/servicebus.html

Reference model 64 5.8 Identity view / Security officer view Primary presentation Portal 20 Authentication 15 Administration Business Logging Service 18 Process ESB Management Authorization Service 19 ISO 17799 Guidelines Baselines Cobit Version 0.01 Figure 24 Primary presentation security view Element catalogue Symbol Name Explanation Functionality The functionality describes a specific type of functionality used within Zwitserleven. Service This symbol identifies a high level security principle Communication The communication shows what elements of the Zwitserleven SOA interact. User The user can be either a service consumer or a person. The user interacts with the Zwitserleven SOA. Decision The decision symbol refers to a specific

Reference model 65 decision in Appendix C. Security link Dotted lines shows a link to a specific security Conceptual This icon shows some sort of conceptual element. element. This element does not have any direct physical links. Architectural background Each of the elements depicted are standard based. The specific standards are omitted but can be found in the technical documentation of BEA products and (part) in Chapter 4. New applications or software solutions will have to incorporate these standards. By doing so, it will be possible to cope with changing technology. The security infrastructure should protect Zwitserleven from possible unpredictability of people. Where access control is needed it will be enforced by ALSB. Policies, which are based on Zwitserleven guidelines and baselines, should show when access control is needed and apply the appropriate security level. When guidelines change policies can be changed and enforced almost immediately. Auditing depends on the type of service used and on who is using the service. The security system logs at least the authentication and authorization process. Every other service and or applications can have its own logging service. 5.9 Conclusion This chapter describes the secure SOA architecture for three different stakeholders. The views described are deployment view, service view and the identity view. For Zwitserleven there will be one infrastructure that takes care of all the security related issues. ALSB plays a major role in maintaining the security of the Zwitserleven SOA since it will act as an enforcer for security. The way security is handled by the new architecture allows for changes in both technology and business processes, without spending much effort on security. 5.10 Further reading The views do not contain any formal modelling technique such as UML. I have found two methods to model security requirements in UML, UMLSec [14] and SecureUML [18]. These modelling methods could be if a formal approach is needed.

Glossary security concepts 66 Chapter 6 Discussion 6.1 Views Before conduction the interviews of the stakeholders, I had some presumptions about what should be contained in the views, and in effect about the concerns of the stakeholders. I tried not to direct the stakeholders in one direction, but could maybe have done so. For example, I assumed the security personnel would be interested into how the ISO17799 would map to guidelines of Zwitserleven and how this would be represented. 6.2 Number of viewpoints / stakeholders The three viewpoints can be too limited for most organizations. Next to the stakeholder profiles in this thesis organizations should always research what other viewpoints are necessary. It is also important to note that testing of the method for creating viewpoints is not the goal of this thesis. The goal of this thesis is to create understandable documentation of secure SOA (communication of the architecture). 6.3 Method for viewpoint creation I have used the method for creating IEEE standard 1471 viewpoints [16] one time before in a university setting. This is probably not sufficient to be fully aware of all the pitfalls. For instance, the stakeholders were presented with the method, which was also explained before the interview. The goal of this interview was to create the stakeholder profile. The stakeholders had no previous experience with the method. This became apparent when the first version of the reference model was presented to one of the architects. The architect questioned the view, and as I described it, also questioned the method that was used. In this case it seemed that the summary of the design documentation, the concern that the stakeholder had, and the concerns that I thought to be relevant for the viewpoint were not adequate for the stakeholder. Next to this, some of the concerns were not explicit enough or maybe too explicit. For instance the concern “How can we cope with (rapidly) changing technology?” of

Reference model 67 the security officer is not very clear. Technology can be anything from protocols to software products. This left a lot to my own interpretation. I had some trouble with the terms used in the method. For example, the term design documentation is not clear. With the term design documentation, the architects had another concept in mind. The preferred term for the architects was business requirement. The transition from content-2-concerns table to viewpoint was made by using the concerns that could be mapped on the architectural decisions as described by the stakeholders. 6.4 Maturity of scientific research Research in the field of SOA security has not matured yet. Most of the papers, proceedings and articles used in this thesis are published in the same year (2007) or are just one or two years old. Especially in the security field, this is not a long time. This means that for instance, protocols can be rendered insecure, improved security protocols can be introduced and or best practices can be introduced. 6.5 Commercial literature I have not used any of the (commercial) solutions that I have described in this thesis. I only have some experience with Web services build with PHP and XML parsing. This is important because all the information of commercial solutions are from either commercial websites, blogs, BEA personnel or presentations by commercial companies. The workings of a specific product therefore are only my opinion about the workings of the product. 6.6 AK-SPAM method The AK-SPAM method can represent alternatives. It does not mention whether to mention in what situation another alternative should be used. In addition, the AK- SPAM method talks about concerns, which is the same term used in the viewpoint creation method. I got the remark from stakeholder that representing decisions in the views made them less clear.

Glossary security concepts 68 Glossary of terms Reference model A reference model is an abstract framework for understanding significant relationships among the entities of some environment [89]. In other words, the reference model shows the functionality and the data flow between pieces of the architecture [42]. System The term system is used as a computer based information system. An Information System is a set of interrelated components that collect or retrieve, process, store and distribute information to support decision-making and control in an organization [57]. This information depends on computer hardware and software to support processing and distribution of information. Organization Within this thesis the word organization can mean two things. First, it is used to denote a group of people working together 20 ; second, it denotes an arrangement of elements. Entity Throughout this thesis the word entity (plural entities) is used to denote something that is perceived or known or inferred to have its own distinct existence (living or nonliving) 21 . Examples of entities are a person, a process and a service. Business Process A business process is a real-world activity consisting of a set of logically related tasks that, when performed in the appropriate sequence, and according to the correct business rules produces a business outcome. Business processes range from short- lived (taking minutes or hours) to long-lived (taking weeks, months, or even years) [59]. 20 http://wordnet.princeton.edu/perl/webwn?s=organization 21 http://wordnet.princeton.edu/perl/webwn?s=entity

Reference model 69 Denial of Service (DOS) attack. A denial of service floods web services with a large set of additional request for a specific service. This can cause the service to stop functioning or function slower than is required. Security tokens Security tokens contain one or multiple claims about some entity. Web Portal In this thesis a portal is an infrastructure providing secure, customizable, personalizable, integrated access to dynamic content from a variety of sources, in a variety of source formats [38]. Entitlements These are the rights an entity has, based on who the entity is, or what role it has. Digital signature A digital signature is just like a normal signature. A signature tells a receiver who the original signer of the message is. In practice it is string containing a value generated by a public-key algorithm based on the content of a block of data and on a private key. This creates a checksum by which the receiver of a message can check whether the message was signed by a sender. Digest The digest of a message is a function of the message with the following useful properties: (1) it is practically infeasible to compute the original message from its digest and (2) the chance of ﬁnding another message that will produce the same digest is extremely small. In practice, a digest is a hash function that hashes text of any length to a small (typically 128-bit) number [65].

Appendix A 70 Appendix A SOA definitions Below are just a few of the definitions that can be found on websites and in literature about Service Oriented Architecture. These are just displayed to show the variety between points of view of SOA. Before a company starts an implementation of SOA, it would be wise to decide what SOA means for the company. “In Service-Oriented Architecture autonomous, loosely-coupled and coarse-grained services with well-defined interfaces provide business functionality and can be discovered and accessed through a supportive infrastructure. This allows internal and external system integration as well as the flexible reuse of application logic through the composition of services”. Malte Poppensieker http://the-soa-weblog.blogspot.com/2005/11/definition-of-service- oriented.html In Service-Oriented Architecture autonomous, loosely-coupled and coarse-grained services with well-defined interfaces provide business functionality and can be discovered and accessed through a supportive infrastructure. This allows internal and external system integration as well as the flexible reuse of application logic through the composition of services to support an end-to-end business process. Joe McKendrick http://blogs.zdnet.com/service-oriented/?p=490 A service-oriented architecture is a software architecture that is based on the key concepts of an application front-end, service, service repository, and service bus. Krafzig In short, SOA is about loosely coupled systems, message based communication and business process orchestration. As an abstract architectural model, it acts as an indirection between the business and the technology model. Web Services are the preferred implementation technology for loosely coupled and inter-operable systems. Beat Schwegler http://blogs.msdn.com/beatsch/archive/2005/02/22/377948.aspx

Appendix A 71 The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface. CBD http://msdn.microsoft.com/architecture/soa/default.aspx?pull=/library/en- us/dnmaj/html/aj1soa.asp Service-Oriented Architecture (SOA) is a component model that inter-relates an application’s different functional units, called services, through well-defined interfaces and contracts between these services. The interface is defined in a neutral manner that should be independent of the hardware platform, the operating system, and the programming language in which the service is implemented. This allows services, built on a variety of such systems, to interact with each other in a uniform and universal manner. IBM http://www-128.ibm.com/developerworks/webservices/newto/ A service-oriented architecture is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components (services) that can be reused and combined to address changing business priorities. Service Oriented Architecture Compass http://www.ibmpressbooks.com/bookstore/product.asp?isbn=0131870025 &rl=1 SOA is an approach to build distributed systems that deliver application functionality as services to end-user applications or to build other services. IBM, http://www-128.ibm.com/developerworks/library/ws-soaintro.html Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectation. OASIS reference model for Service Oriented Architecture 1.0 http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf A software architecture of services, policies, practices and frameworks in which components can be reused and repurposed rapidly in order to achieve shared and new functionality. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Appendix A 72 SOA-RM TC, draft 11 http://www.oasis-open.org/committees/download.php/15966/wd-soa-rm- 11.pdf SOA is an architectural paradigm whose goal is to achieve loose coupling among interacting software applications. Applications invoke a series of discrete services in order to perform a certain task. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Amir Shevat http://www.oreillynet.com/pub/wlg/8951 (Service-Oriented Architecture) Formerly called a “distributed objects” architecture, the SOA term was coined at the turn of the century as Web services were evolving. CORBA and DCOM are examples of earlier SOAs. See CORBA, DCOM and Web services. Answers.com http://www.answers.com/topic/service-oriented-architecture?method=6 The SOA abstracts and exposes business functions as services that connect multiple business applications in homogeneous or heterogeneous environments. Oracle Magazine http://www.oracle.com/technology/oramag/oracle/06-jan/o16field.html SOA is a logical way of designing a software system to provide services to either end- user applications or other services distributed in an network through published and discoverable services Mike P. Papazoglou, Service-Oriented Computing: Concepts, Characteristics and Directions. Proceedings of the Fourth international conference on Web Information Systems Engineering (WISE ’03). A Service Oriented Architecture provides patterns for design, development, deployment and management of a loosely coupled business application infrastructure. In this framework, business functionality is published, discovered, and consumed as part of a business ecosystem of network-aware and reusable technical and business services. Skyware Software, http://www.skywaysoftware.com/resources_terminology.htm

Appendix B 73 Appendix B Stakeholder profiles The stakeholder profiles will be described according to the description in [16]. Attribute Content Title Architect Goals Align Zwitserleven architecture with the business goals. Create flexible, stabile future proof IT environment. Structure IT as such that business goals can be realized with minimal effort (time and money). Optimization of information systems and the processes they support within constraints set by the company goals and resources. Tasks Create overviews. Translate business matters to concrete solutions. Rationalize, spread, decide the technical architecture decisions Create and maintain standards and guidelines for architectural concepts. Draw up advice the architecture and create (start) architectures. Test solutions to architecture standards. Keep overview of the interaction between applications and between Zwitserleven and partners. Maintain application portfolio. Advise when selecting architectural concepts. Creating overall vision of information systems supporting the company strategy. Reviewing designs and plans of information systems. In other words check for compliance to (Zwitserleven) standards and (Zwitserleven) vision. Formulating design and use policies of these systems (creating standards). Enforcing policies and decide on exceptions on these policies (enforcing standards) Explaining and defending policies.

74 Concepts IT infrastructure. Application landscape. IT systems. Processes. (Web) services. Standards. Guidelines. Reports on change and application portfolio and objects used with the IT environment. Viewpoints on architecture (customer, IT, business). Long term vision and tactical road for change. Information system designs in different stakeholder views. Rules, regulations and policies. Best practises. Stakeholder concerns (business, security officer/ compliance officer, IT management). Concerns Does the architecture use standard based (security) protocols, used in industry today? Is tooling used for the purpose it was built for? Are solutions aligned with the chosen direction of Zwitserleven (on strategic, operational, and tactical levels)? Will change in business goals severely affect the architecture and IT solutions? Is the architecture description understandable for all the stakeholders involved? Can the IT infrastructure that is implemented from the architecture be used by different stakeholders (e.g., user-friendly?). Can the IT systems that are conceived within the architecture be implemented within budget? Stakeholder support and understanding. Quality of service of information systems. Table 9 Architect stakeholder profile Attribute Content Title Application coordinator / Software engineer

75 Goals Deliver and maintain working (web) services. Tasks Build and test new services (process, integration and application services) Fix problems in production Manage projects: intake, planning, control, execution and evaluation. Concepts Technical documentation of services Process services Integration services Application services. Computer systems. Applications. Functional design reports. Planning. Concerns Does the architecture use the standard features of the chosen software solution? How do I get good design documents? Do we have the skills and time to do all the work (planning)? Can I finish projects in time (manage day-by-day issues)? How can I manage test-bug-fix-cycles? Is the functional design of a service technically feasible? What industry standards are available for the technical implementation of services How is security implemented in (web) services? Table 10 System developer stakeholder profile Attribute Content Title Security officer Goals Design, develop and manage the IT Security program of Swiss Life Tasks Provide a general framework to aid with the development and implementation of effective measures, practices and procedures for the security of IT systems and resources. Promote confidence and trust in the security of IT systems, their implementation and operational use. Create a measurable security strategy based on benchmarking and

76 maturity models. Initiate, facilitate and promote activities to raise IT security awareness throughout the company. Leadership and management of specific security-related projects. Create, maintain and monitor the security plans that supports the implementation of the Swiss Life’s IT security program. Develop clear security policies and directives, supported by an assertive communications method that reaches all members and staff. Develop guidelines and procedures to ensure business processes properly address IT security risks and define appropriate safeguards. Develop technical guidelines and procedures to ensure adequate security of all components of the IT infrastructure Develop and implement processes for detecting identifying and analysing security-related events or weaknesses. Promote accountability through clear definition of roles and responsibility in managing IT security. Ensure the IT security program complies to data privacy, copyright and other data-related legislative requirements in co-operation with the group Compliance Officer. Ensure that the rules of use of IT systems and resources comply with the approved security policies and directives. Act as an advising and approving authority in the design and implementation of new security models, concepts or solutions. Analyse and manage new security threats resulting from IT technology changes. Advise IT management with up-to-date information relating to IT security. Concepts Policy descriptions. Security audit (trail) reports. Test reports. Risk analyses. Authorization model. Log files on both system level and application level.

77 Guidelines Baselines Standards Concerns Do new technologies have best practices and/or standards incorporated? How can we cope with (rapidly) changing technology? How can we stay compliant to our own guidelines and laws/regulations? How to handle unpredictable behaviour of people? How can we authorize access to Zwitserleven resources? How can we be sure that the security measures are really working? Table 11 Security officer stakeholder profile

Appendix B 78 Content-2-concerns table Table 12 is the content-2-concerns table. This table links concerns of the stakeholders to architectural statements. Some concerns are not displayed in this table Architectural statements Architect Security officer Software developer Will change in business goals Do new technologies have best Does the architecture use the severely affect the architecture and practices and/or standards standard features of the chosen IT solutions? incorporated? software solution? Does the architecture use standard How can we cope with (rapidly) How is security implemented in based (security) protocols, used in changing technology? (web) services? industry today? What industry standards are available for the technical implementation of services? Solutions / products should Changing the requirements of When (new) technology is Solutions or products that rely on incorporate industry new IT solutions can be selected or needed Zwitserleven industry standards should be

79 standards (such as SOAP, simplified when these solutions has to incorporate industry used. Security should also rely WSDL). use industry standards. The standards. As long as the on industry standards. impact on the architecture standards are available coping should therefore not be severely with new technology should be impacted. possible. Does the architecture use standard How can we cope with (rapidly) How can I manage test-bug-fix- based (security) protocols, used in changing technology? cycles? industry today? Will change in business goals severely affect the architecture and IT solutions? Maximize reuse of (current Reuse of application By reusing parts of applications and future) application functionality means that some which are already thoroughly functionality and business functionality is generalized. tested. rules. When business goals change some of this functionality can be reused in the new business goals. Will change in business goals severely affect the architecture and IT solutions? Flexibility of business The architecture should be

80 processes. developed to create flexible business processes that can be changed without changing the whole business. How to handle unpredictability of people? How can we authorize access to Zwitserleven resources? Computerize manual labour By computerizing manual labour (introduce STP). it could prevent unpredictable such as wrong data-entry by people. In addition, authorization should be possible by computerizing entering of user accounts and passwords. One solution could be to introduce a federated identity manager which automatically develops How can we stay compliant to our

81 own guidelines and laws/regulations? No migration of legacy applications. Reduce redundancy (or increase reuse) of data by integrating applications. How can we authorize access to Zwitserleven resources? How can we cope with (rapidly) changing technology? Integration of applications By making all integration of should be technology applications technology independent. independent. How can we be sure that the security measures are really working? How to handle unpredictability of people? Divide business into separate By separating the business into

82 functional areas in order to separate functional areas people specialize and manage. become more specialized on their interest. Since know-how on their expertise increases, potential unpredictable behaviour should be limited. Table 12 Content-2-concerns table

Appendix B 83 Viewpoints The following viewpoint were derived from the content-2-concerns table and the stakeholders’ profiles. The viewpoints are aimed at providing the necessary elements in a security context. The tables below are almost identical to those found in [16] however I have not used the field stakeholder oriented graphics. Service viewpoint Attribute Content Title Service view Stakeholders Application coordinator / Software engineers. Concerns Does the architecture use the standard features of the chosen software solution? What industry standards are available for the technical implementation of services? How is security implemented in (web) services? How can I manage test-bug-fix-cycles? Type of information Specific security elements used in services. As well as an overview of services. Presentation Drawings on paper, including textual explanation. Analysis techniques Interview stakeholders. Stakeholder oriented Process services terms Integration services Application services. Computer systems. Applications. Table 13 Service viewpoint Security viewpoint Attribute Content Title Identity view

84 Stakeholders Security officers Concerns Do new technologies have best practices and/or standards incorporated? How can we cope with (rapidly) changing technology? How to handle unpredictability of people? How can we stay compliant to our own guidelines and laws/regulations? How can we authorize access to Zwitserleven resources? How can we cope with (rapidly) changing technology? How can we be sure that the security measures are really working? Type of information High level security elements used in the IT infrastructure (such as identity management, auditing). Presentation Drawings and textual explanation Analysis techniques Interview stakeholders. Stakeholder oriented Security audit (trail) reports. terms Authorization model. Log files on both system level and application level. Guidelines Baselines Standards Table 14 Identity viewpoint Architecture viewpoint Attribute Content Title Deployment view Stakeholders Architects Concerns Will change in business goals severely impact the architecture and IT solutions? Does the architecture use standard based (security) protocols, used in industry today?

85 Type of information Visual impression of the architecture containing standards based protocols and/or elements available in the software solutions. Elements that can be reused by different business processes or services. Presentation Drawings, textual explanation Analysis techniques Interviews with stakeholders. Scenario testing. Stakeholder oriented IT infrastructure. terms Application landscape. IT systems. Processes. (Web) services. Standards. Table 15 Deployment viewpoint

Appendix C 86 Appendix C Architectural Knowledge Design Space Introduction This appendix hold the architectural decisions that are made in this thesis. They are used in Chapter 5. In the status field and ranking criteria field I have used terms that I have predefined. The status field has three possible values: proposed, discussed and approved. Table 16 Status field terms Status field term Description Proposed Decision is put forward as a reasonable alternative. Discussed Decision is discussed but no clear approval. Approved Decision is agreed upon by Zwitserleven Proposed means that I this decision has only been proposed by me, and not been directly discussed or approved with Zwitserleven. Discussed means that I have discussed the decision with Zwitserleven but did not get (clear) approval. This is usually because Zwitserleven is not fully aware of the SOA security issues and concepts. Approved means that someone at Zwitserleven has agreed with the solution and it is suitable for Zwitserleven according to that specific person. The ranking criteria are according to quality requirements of ISO 9126 [81]. Table 17 Ranking field terms Quality Description requirement Functionality A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs. Functionality is composed of Suitability, Accuracy, Interoperability, Compliance and Security Reliability A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a

Appendix C 87 stated period of time. Reliability contains Maturity, Recoverability and Fault Tolerance Usability A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users. Usability contains Learnability, Understandability and Operability Efficiency A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions. Efficiency contains Time Behaviour and Resource Behaviour Maintainability A set of attributes that bear on the effort needed to make specified modifications. Maintainability contains Stability, Analyzability, Changeability and Testability Portability A set of attributes that bear on the ability of software to be transferred from one environment to another. Portability contains Installability, Replaceability and Adaptability Decisions Decision 1 Concern How should the claimed identities of service consumers be authenticated? Alternative(s) 1. Local RBAC (LDAP) 2. Local ABAC Ranking Criteria Maintainability Architectural Identifier #1 decision Status Discussed Description A local RBAC solution (LDAP windows 2003) will be used. As software solution SUN Identity and Access Management is chosen to manage identities and roles throughout the organization. Relationship(s) Rationale Zwitserleven does not have to incorporate other identities outside of the local security domain,

Appendix C 88 therefore specific roles can be created within a standard RBAC solution. Decision 2 Concern Alternative(s) 1. A completely centralised architecture 2. A completely distributed architecture 3. A user centred architecture 4. A provider centred architecture. Ranking Criteria Security Outsource ability Architectural Identifier #2 decision Status Discussed Description The AAI infrastructure best suited for Zwitserleven is the provider centred architecture. Relationship(s) Rationale The provider centred architecture enables fine grained access control and trusted decisions. This is important for Zwitserleven because there should be separation of duties. In addition, there should be possibilities to outsource part of the security to 3rd party providers. Such as Internet Service Providers (ISP), or GBA. In addition, service consumers would like to have SSO, which is available in the provider centred architecture. Decision 3 Concern How can service consumers be authorized to access a service provider? Alternative(s) 1. Secure Service Proxy (SSP) 2. Intercepting Web Agent (IWA) 3. Secure Service Agent (SSA) Ranking Criteria Security

Appendix C 89 Architectural Identifier #3 decision Status Discussed Description To authorize service consumers the SSA design pattern should be used. Relationship(s) Rationale For an in depth discussion see [7] Decision 4 Concern How can we maintain the integrity of messages between service provider and service consumer? Alternative(s) 1. Shared key cryptography 2. Symmetric key cryptography Ranking Criteria Usability Architectural Identifier #4 decision Status Proposed Description Symmetric key cryptography will be used. Relationship(s) Rationale Because Zwitserleven know with which services it will have contact, it is wise to use a symmetric public key infrastructure. Decision 5 Concern How can the identity of a service client be propagated from a proxy service on the ESB to the business service? Alternative(s) 1. Propagate the username and password by using credential mapping (transport and message level security). 2. Propagate the username and password using pass-through credential mapping. 3. Propagate the identity as a SAML token. 4. If the proxy service has an authentication policy at transport and message level. The message level identity is propagated [47].

Appendix C 90 Ranking Criteria Usability, Security Architectural Identifier #5 decision Status Approved Description The identity will be propagated as a SAML token. Relationship(s) Rationale SAML provides high operability and is completely standards based. When other solutions using Web services are introduced within the Zwitserleven SOA, they be able to understand the SAML token. Decision 6 Concern Where should security policy be enforced? Alternative(s) 1. In the ALSB 2. At he business services outside the ALSB Ranking Criteria Maintainability and security Architectural Identifier #6 decision Status Discussed Description The ALSB will enforce the security policy of Zwitserleven. It does so by introducing proxy services, which address business services. Relationship(s) Rationale The ALSB is the central point of the SOA architecture. Therefore it seems logical for the ALSB to be the main point to enforce security. There are two implementations of ALSB necessary. The first one is inside the DMZ and the other is inside the internal network. The ALSB in the DMZ can link to proxy services in the internal ALSB. The ALSB in the DMZ only contains services that are available for external users. Decision 7

Appendix C 91 Concern How to secure interaction between ALS and service consumers outside Zwitserleven Alternative(s) 1. WS-Security and WS-Policy 2. SSL (HTTPS) Ranking Criteria Usability Architectural Identifier #7 decision Status Discussed Description Interaction between service consumers and services outside Zwitserleven will be secured with SSL. Relationship(s) Rationale WS-Security and WS-policy provide a broad spectrum of possible service consumer access to the ALSB (in effect to a service). However Zwitserleven knows with whom it exchanges services. WS-Security imposes a lot of overhead, therefore SSL is chosen. Decision 8 Concern How can interaction between with ALSB and ALBPM be secured? Alternative(s) 1. None 2. WS-Security UserNameToken Ranking Criteria Suitability Architectural Identifier #8 decision Status Proposed Description The WS-Security UsernameToken will be used to provide secure interaction between ALBPM and ALSB Relationship(s) Rationale The WS-Security UserNameToken is now the only method to provide authentication from ALBPM to ALSB. A representative of BEA thinks

Appendix C 92 that the next release of ALES will also incorporate the ALBPM suite. Decision 9 Concern How can access control be managed? Alternative(s) 1. Use the default Weblogic Security Framework of Weblogic Server 2. Use Aqualogic Enterprise Security Ranking Criteria Usability, Security Architectural Identifier #9 decision Status Approved Description ALES will be used for access control.’ Relationship(s) Rationale By using ALES for access control security logic is removes from the web services. Access policies can be defined consistently across multiple applications. It provides a standard set of security services including authentication, authorization, role mapping, auditing, and credential mapping. Decision 10 Concern How can authentication information be propagated between services? Alternative(s) 1. Propagate the username/password pair using credential mapping for transport and message-level security on the outbound message. 2. Propagate the username/password pair to the outbound request using pass-through credential mapping when inbound security is configured to be transport-level or message- level for legacy cases. The ALSB may or may not handle authentication. 3. When the business service requires an SAML

Appendix C 93 security token, ALSB can act as an active intermediary to propagate identity by generating a SAML token based on any inbound authentication security policy. Ranking Criteria Usability, interoperability Architectural Identifier #10 decision Status Proposed Description Each of the above alternatives can be used Relationship(s) Rationale There are several situations where the different ways of propagation can be used. A decision has to be made for different situations. Decision 11 Concern Should ALES be located in the DMZ or in the internal network? Alternative(s) 1. DMZ 2. Internal network Ranking Criteria Security Architectural Identifier #11 decision Status Approved Description ALES should be located in the DMZ Relationship(s) Rationale ALES uses SSM’s which can connect to ALES. It is therefore not necessary to have an instance of ALES in the DMZ. Decision 12 Concern Should the portal be directly connected with the ALBPM or go through ALSB? Alternative(s) 1. Use the ALSB to invoke a business process (service), which creates a presentation. 2. Use ALBPM to create a presentation directly in the ALSB.

Appendix C 94 Ranking Criteria Security Architectural Identifier #12 decision Status Approved Description A process within ALBPM should be addressed through the ALSB Relationship(s) Rationale ALSB should be the central point for all communication between services. By doing so, one can be sure that security measures are in place. Decision 13 Concern What standard should be used for identity propagation? Alternative(s) 1. - SAML Ranking Criteria Interoperability Architectural Identifier #13 decision Status Approved Description Identities need to be propagated to support the authentication process. Relationship(s) Rationale SAML should be used for identity propagation. SAML is the most common standard. Additionally BEA products are also well equipped to work with SAML. Decision 14 Concern Should parts of the architecture be deemed trusted? Trusted in this case means that there is no longer any access control or communication security (identity of an entity can still be propagated). Alternative(s) 1. Everything behind the internal firewall is trusted

Appendix C 95 2. Everything after the integration layer is trusted. Ranking Criteria Manageability Architectural Identifier #14 decision Status Approved Description Everything behind the integration layer is trusted. Relationship(s) #15 Rationale By trusting everything behind the integration layer the architecture is more manageable. The integration layer is trusted to supply the right identity and only allow access to authorized users. Decision 15 Concern What kind of AAI approach should be used? Alternative(s) 1. A centralized AAI approach 2. A distributed AAI approach. Ranking Criteria Manageability Architectural Identifier #15 decision Status Discussed Description For the Zwitserleven SOA, a centralized AAI approach will be used. Relationship(s) Rationale A centralized AAI approach provides one point where all authorisation and authentication decisions will be made. The drawback of a centralized approach is that it can be a single point of failure, and a performance bottle-neck, storing all entity information into one single point can also have privacy issues. Since this AAI is only used at Zwitserleven this should not be a major issue.

Appendix C 96 Decision 16 Concern How can access to services from outside of Zwitserleven be managed? Alternative(s) 1. Web service gateway 2. Reverse proxy Ranking Criteria Security and Interoperability Architectural Identifier #16 decision Status Discussed Description Both the web service gateway and the reverse proxy will be used. The web service gateway is an implementation of ALSB. It contains a subset of the internal ALSB. Relationship(s) Rationale The users should be able to interact with the services directly, which requires the web services gateway. However, Zwitserleven also has some web applications that run on top of Web services. To allow access to these web applications a reverse proxy is used. Decision 17 Concern How to regulate network flow from and to the Zwitserleven network domain? Alternative(s) 1. Don’t allow access to and from other network domains 2. Firewall Ranking Criteria Security Architectural Identifier #17 decision Status Approved Description Use a firewall. Relationship(s) Rationale A firewall is a security gateway between to different network domains.

Appendix C 97 Decision 18 Concern Logging can be done at different levels of the architecture, and on different events. Where should logs of what entity has accessed which specific service or application? Alternative(s) 1. Application level logging 2. ALSB logging. 3. Auditing provider in Weblogic. Ranking Criteria Operability Architectural Identifier #18 decision Status Discussed Description Application level logging Relationship(s) Rationale Although the ALSB is the central place for storing access information, it will only be able to store who accessed a service that is published in the ALSB. Therefore one should use application level logging. Decision 19 Concern How is the security policy maintained? Alternative(s) 1. In the application level (business logic) 2. In a specific part of the security system Ranking Criteria Usability, Security, Maintainability Architectural Identifier #19 decision Status Discussed Description The security policy will be maintained in a specific security system Relationship(s) Rationale From both a usability and security stance it seems logical to have one single point that maintains policies. From a security stance, it will not be wise to let software developers be

Appendix C 98 responsible for security policies. From a usability view creating redundant policy stores can create mismatches between the stores and possible security threats. Decision 20 Concern In what way can Zwitserleven resources be accessed? Alternative(s) 1. Trough a portal 2. Through the ESB 3. Through BPM Ranking Criteria Security, usability Architectural Identifier #20 decision Status Approved Description Access is allowed through a portal, ESB and Business Process Management. Relationship(s) Rationale Each of the access points is necessary. All three can be used for internal use and for external use. This will allow Zwitserleven, to provide the full set of features to users. For more information, please see the architect of software engineering view.

Appendix C 99 Appendix D XML-SIG Security flaws This appendix contains some flaws that can be found in literature about XML-SIG. These flaws are not exhaustive. Surreptitious forwarding. Imagine Alice wants to send a digitally signed XML document that only Bob can read. The Alice signs the XML document and encrypts it using Bob’s public key. Consequently, Alice can be sure that Bob knows that Alice has sent the message and that only Bob can read the message (provided he only knows his private key). On the other hand, Bob only knows that Alice send the message but he cannot be sure that Alice also encrypted the message. Trudy could for instance be the original recipient of Alice’s document. The document was encrypted using the public key of Trudy, who decrypted it using her private key. Trudy then encrypts and sends the message to Bob using his public key. Bob can then decrypt the message and verify that Alice has sent him the message, where in effect it was send by Trudy. To summarize in security principles, the integrity of the message holds for Bob he cannot be sure confidentiality of the message is maintained [5]. WS-Addressing [102] is one solution to prevent surreptitious forwarding. It does so by supplying the intended receiver of the message within the XML (SOAP) document. Canonicalization XML-SIG calculates a digest from the original data. When the data is in the form of an XML document this can pose some problems. Take for instance the following two representations of a small part of a XML file. <foo purpose =‘not useful’ meaning=’nothing’> <bar></bar> </foo> Figure 25 XML example 1

Appendix C 100 <foo meaning =‘nothing’ purpose=’not useful’> <bar /> </foo> Figure 26 XML example 2 The information contained in Figure 25 and Figure 26 is the same, however the representation of the information is different. The digest that XML-SIG will create will definitely be different. More information about XML canonicalization can be found in [100].

Appendix C 101 Appendix E Web services threats There are several threats to web services. These threats are also regular security threats; the following list is from [101]. Message alteration. An attacker inserts, removes or modifies information within a message to deceive the receiver. Loss of confidentiality. Information within a message is disclosed to an unauthorized individual Falsified messages. Fictitious messages that an attacker intends the receiver to believe are sent from a valid sender Man in the middle. A third party sits between the sender and provider and forwards messages such that the two participants are unaware, allowing the attacker to view and modify all messages Principal spoofing. An attacker constructs and sends a message with credentials such that it appears to be from a different, authorized principal Forged claims. An attacker constructs a message with false credentials that appear valid to the receiver Replay of message. An attacker resends a previously sent message Replay of message parts. An attacker includes portions of one or more previously sent messages in a new message Denial of service. An attacker causes the system to expend resources disproportionately such that valid requests cannot be met.

Appendix C 102 Appendix F BEA product information This appendix contains more information about certain BEA products. It is not meant to be read as a stand-alone chapter but more as an expansion to Chapter 4. SSM ALES SSM for Java ALES Web Services SSM ALES SSM for Apache Web Server (including Web Services SSM) ALES SSM for Microsoft IIS (including Web Services SSM) ALES SSM for WebLogic Server 8.1 22 ALES SSM for WebLogic Server 9.x Authentication providers Table 18 Authentication providers Provider Description Weblogic Authenticator Authenticate users with WebLogic’s embedded LDAP directory. ALES Identity Asserter Supports web server authentication and single sign-on between web server SSMs. Use this provider in conjunction with the ALES Credential Mapper. Database Authenticator Authenticates users using the ALES relational database provider. Single Pass Negotiate Identity Supports identity assertion using HTTP Asserter authentication tokens from the SPNEGO protocol. For more information, see Chapter 6, “Enabling 22 http://edocs.bea.com/ales/docs26/installssms/overview.html

Appendix C 103 SPNEGO-based Single Sign-on.” SAML Identity Asserter Accepts SAML assertions sent using the Browser POST Profile and returns the corresponding user. For more information, see Chapter 5, “Enabling SAML-based Single Sign-On.” LDAPAuthenticator Authenticates users using an Open LDAP directory. Active Directory Authenticator Authenticates users using Active Directory. Open NTAuthenticator Authenticates users using Windows NT authentication. iPlanet Authenticator Authenticates users using an iPlanet LDAP directory. Novell Authenticator Authenticates users using a Novell LDAP directory. X509 Identity Asserter Supports identity assertion through an X.509 digital certificate, supporting ASN.1 encoding and decoding. Authorization providers Table 19 Authorization providers Provider Description Weblogic Authorizer. Authorizes access to resources based on WebLogic security policy ASI Authorization Provider Authorizes access to resources based on ALES security policy. Credential mapping providers Table 20 Credential mapping providers Provider Description Database Credential Mapper Returns authentication credentials for a user (username and password) from a database.

Appendix C 104 SAML Credential Mapper Returns a SAML assertion for an authenticated user. ALES Identity Credential Mapper Supports web server authentication and single sign-on between web server SSMs. Returns a ALES assertion for an authenticated user. Weblogic Credential Mapper Returns authentication credentials for a user (username and password) from the Weblogic LDAP directory. Role Mapping Providers Table 21 Role mapping providers Provider Description ASI Role Mapper Returns a set or roles granted to a user on a protected resource based on ALES security policies. Weblogic Role Mapper Returns a set or roles granted to a user on a protected resource based on WebLogic security policies. ALES Security standards SAML Participate in SAML-based single sign-on (SSO) environment. WSDL 1.1 The Web Services Description Language (WSDL) is an XML-based specification that describes a web service. A WSDL document describes web service operations, input and output parameters, and how a client application connects to the web service. Java Standards CertPath Retrieve X.509 digital certificates associated with infrastructure protection; available for customer direct use. KeyStore Retrieve RSA private keys associated with X.509 digital certificates associated with infrastructure protection; available for customer direct use. JSSE Protect infrastructure network connections for establishment of mutual trust. JCE Integrate cryptographic libraries. JAAS Provide authentication service implementations.

Appendix C 105 XACML 2.0 XACML, the eXtensible Access Control Markup Language, is an OASIS standard. XACML is a standard language for expressing access control, or authorization, policy, and a standard format for expressing queries over these policies. X.509 Validate the identity of infrastructure components through digital certificates; supported as proof of identity for customer use. LDAP v3 Retrieve configuration information from the Service Control Manager, and user identity and user attributes from an LDAP v3 directory server. ISAPI Support compliant runtimes for authentication, SAML single sign-on, and protection of hosted web pages. FIPS 140 Support certification of the embedded cryptographic libraries used for cryptographic protection and TLS protocol. SSL (TLS) Protect network communication between infrastructure components. JDBC Provide access to database stores using the database provider.

Appendix C 106 References Articles [1] Avizienis, A., and Laprie, J., and Randell,B., Landwehr,C. (2004), Basic Concepts and Taxonomy of Dependable and Secure Computing, Technical Report 2004-47, Institute for systems research. [2] Beznosov, K. and Flinn, D.J. and Kawamoto, S. and Hartman, B. (2005), Introduction to Web services and their security. Information Security Technical Report 10, 2-14, Elsevier Ltd. [3] Cotroneo, D. and Graziano, A. and Russo,(2004) S., Security Requirements in Service Oriented Architectures for ubiquitous computing, ACM 1-58113-951-9, 2nd workshop on Middleware for pervasive and ad-hoc computing. [4] Davenport T.H.(1998), Putting the enterprise into the enterprise system. Harvard Business Review [5] Davis, D. (2001), Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP and XML. Proceedings of the General Track: 2002 USENIX Annual Technical Conference. [6] Dhillon, G. and Backhouse, J. (2000), Information System Security Management in the New millenium, Communications of the ACM Vol 43.No. 7 [7] Emig, C. and Schandua, H. and Abeck, S.(2006), SOA-aware Authorization Control, International Conference on Software Engineering Advances (ICSEA 2007) p. 57 [8] Emig, C. and Brandt, F. and Abeck, S. and Biermann, J. and Klarl, H.(2007), An Access Control Metamodel for Web Service-Oriented Architecture. Software Engineering Advances, 2007. ICSEA 2007. , Issue , 25-31 Aug. 2007 Page(s):v - xiii [9] Emig, C. and Brandt, F. and Kreuzer, S. and Abeck, S. (2007), Identity as a Service – Towards a Service-Oriented Identity Management Architecture. Springer- Verlag. Volume 4606/2007 [10] Farenhorst, R. and Lago, P. (2007), Architectural Knowledge design SPAce Modeling (AK-SPAM). [11] Gudivada, N. and Nandigam, J. (2005), Enterprise application integration using extensible web services. ICWS 2005. Proceedings. Volume , Issue , 11-15 July 2005 Page(s): 41 - 48 vol.1

Appendix C 107 [12] Huhns, N. and Singh, M. and Munindar, P. (2005), Service-Oriented Computing: Key concepts and Principles, IEEE Internet Computing, vol. 09, no. 1, pp. 75-81, Jan/Feb, 2005. [13] Indrakanti, S. and Varadharajan, V. (2005), An Authorization Architecture for Web Services. Data and Applications Security, LNCS 3654, pp. 222-236. [14] Jürjens, J.(2002), UMLSec: Extending UML for secure systems development. UML 2002 - The Unified Modeling Language : 5th International Conference, Dresden, Germany, September 30 - October 4, 2002. Proceedings [15] Kleiner, E. and Roscoe, A.W. (2006), On the Relationship Between Web Services Security and Traditional Protocols, Electronic Notes in Theoretical Computer Science Volume 155, 12 May 2006, Pages 583-603. [16] Koning, H and van Vliet, H. (2005), A method for defining IEEE std 1471 viewpoints, Journal of Systems and Software Volume 79, Issue 1, January 2006, Pages 120-131. [17] Koskela, M. and Rahikainen, M. and Wan, T., Software development methods: SOA vs. CBD, OO and AOP. [18] Lodderstedt, T. and Basin, D. and Doser, J.(2002), SecureUML: A UML-Based Modeling Language for Model-Driven Security. UML 2002 - The Unified Modeling Language : 5th International Conference, Dresden, Germany, September 30 - October 4, 2002. Proceedings [19] Landwehr, C.E. (2001), Computer Security. International Journal of Information Security Volume 1, Number 1 / August, 2001. [20] Lee, J. and Siau, K. and Hong, S. (2003), Enterprise Integration ERP and EAI. In: Communications of the ACM vol. 46. No. 2. [21] Liegl, P. (2007), The strategic impact of service oriented architectures. 14th Annual IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS'07) pp. 475-484. [22] Mahfouz, A. and Barroca, L. and Laney, R. and Nuseibeh, B. (2006) Patterns for Service-Oriented Information Exchange Requirements. Pattern Languages of Programming Conference. [23] McGraw, G. (2006), Software Security and SOA: Danger Will Robinson!. IEEE Security and Privacy, vol. 04, no. 1, pp. 80-83, Jan/Feb, 2006 [24] Nah, F.F. et al.(2001), Critical factors for successful implementation of enterprise systems. Business Process Management Journal, Vol. 7 No. 3. [25] Neubauer, B.J. (2007), Introducing SOA and Workflow modelling to non-technical students, Journal of Computing Sciences in Colleges archive Volume 22 , Issue 4 (April 2007) [26] Nierstrasz, O. (1989), A survey of Object-Oriented Concepts. In: Object-Oriented Concepts, Databases and Applications, pp. 3-21, ACM Press and Addison-Wesley, 1989

Appendix C 108 [27] Olovsson, T. (1992), A structured Approach to Computer Security, Technical Report No 122, Department of Computer Engineering, Chalmers University of Technology. [28] Ortiz, S. (2007), Getting onboard the Enterprise Service Bus, Computer Volume: 40, Issue: 4 page(s): 15-17 [29] Papazoglou, P, M. (2003), Service-oriented computing: Concepts, Characteristics and Directions. In: Proceedings of the Fourth International Conference on Web Information Systems Engineering. [30] Papazoglou, P.M. and van den Heuvel, W. (2007) Service Oriented Architectures: Approaches, Technologies and research Issues. The VLDB Journal. [31] Papazoglou, P.M. and Traverso, P. and Dustbar, S. and Leymann, F. (2006) Service-Oriented Computing Research Roadmap [32] Perrey, R. and Lycett, M. (2003), Service-Oriented Architecture. Symposium on Applications and the Internet Workshops, 2003. Proceedings. page(s): 116- 119 [33] Rahaman, M.A. and Schaad, A. and Rits, M. (2006), Towards Secure SOAP Message Exchange in a SOA, Proceedings of the 3rd ACM Workshop on Secure Web Services. [34] Schneider, F.B. (2000), Enforceable Security Policies, ACM Transactions on Information and System Security, Vol. 3, No. 1, Pages 30–50. [35] Schuschel H. and Weske M. (2004), Automated Planning in a Service-Oriented Architecture. Enabling Technologies: Infrastructure for Collaborative Enterprises, WET ICE 2004 page(s): 75- 80. [36] Schläger, C. and Ganslmayer, M. (2007), Effects of Architectural Decisions in Authentication and Authorisation Infrastructures, Proceedings of the 2nd International conference on Availability, Reliability and Security (ARES’07), IEEE. [37] Seduhkin, I. (2003), End to End security for web services and services oriented architecture, Office of the CTO, Computer Associates. [38] Smith, M.A. (2004), Portals: toward an application framework for interoperability, Communications of the ACM October 2004/Vol. 47, No. 10. [39] Tsai, W.T. and Fan, C. and Chen, Y. and Paul, R. and Chung, J. (2006), Architecture classification for SOA-Based Applications. Object and Component- Oriented Real-Time Distributed Computing, 2006. ISORC 2006. Ninth IEEE International Symposium on Volume , Issue , 2006 Page(s):8 pp. [40] Whitman, M.E. (2003), Enemy at the gate: threats to information security, Communications of the ACM vol46.No.8 [41] Yuan, E. and Tong, J. (2005), Attribute Based Access Control (ABAC) for Web Services, Proceeding of the IEEE International Conference on Web Services (ICWS’05).

Appendix C 109 Books [42] Bass,L. and Clements, P. and Kazman, R.(2003), Software architecture in practice second edition, Addison Wesley, ISBN 0-321-15495-9 [43] Bishop, M. (2003), Computer Security: Art and Science, Addison-Wesley Professional, ISBN 0-201-44099-7 [44] Bruce, K.B. (2002), Foundations of object-oriented languages: types and semantics, MIT Press. ISBN 0-262-02523-X. [45] Chatterjee, S. and Webber, J. (2003), Developing Enterprise Web Services: An Architect's Guide Prentice Hall PTR ISBN : 0-13-140160-2. [46] Chappell, A.D.(2004), Enterprise Service Bus. O'Reilly Media, Incorporated, ISBN 0596008147 [47] Davies, J. and Krishna A. and Schorow, D. (2007), The Definitive Guide to SOA: BEA AquaLogic® Service Bus, ISBN-13: 978-1-59059-797-2 [48] Elmasri, R. and Shamkant N.B. (2004), Fundamentals of Database systems, 4th edition, Pearson Education. ISBN 81-297-0228-2. [49] Erl, T. (2005), Service-Oriented Architecture Prentice Hall PTR ISBN 0-13- 185858-0 [50] Es van, R. and Gerwen, N. and Ligthart, A. and Rooij, R. and Graave, J. (2005), Service-Oriented Architecture, Academic Service, ISBN: 90-395-2431-9 [51] Ford, W. (1994), Computer Communications Security, Prentice Hall. ISBN 0-13- 799453-2 [52] Ghauri, P. and Grønhaug, K. (2005), Research methods in Business Studies, 3rd edition, Pearson education Limited, ISBN 0273681567 [53] Guttman, B. (1995), An Introduction to Computer Security: The Nist Handbook, ISBN 0788128302. [54] ISO/IEC, (2000) Information technology Code of practice for information security management 17799:2000. [55] Josuttis, N.M. (2007) SOA in Practice, 1st edition, O’Reilly Media Inc. [56] Krafzig, Dirk, Banke, Karl, Slama, Durk, Enterprise SOA, Service Oriented Architecture Best practices. Prentice Hall, November 2004. ISBN 0-13-146575-9. [57] Laudon, K.C. and Laudon, J.P. (2002), Bedrijfsinformatiesystemen, 7th edition, Pearson education. ISBN 90-430-0516-9. [58] Lehtinen, R. (2006), Computer Security Basics, 2nd Edition, O'Reilly. ISBN-13: 978-0-59-600669-3

Appendix C 110 [59] Newcomer, E. and Lomow, G.(2004) Understanding SOA with Web Services, Addison Wesley Professional, ISBN : 0-321-18086-0 [60] Noordzij, M. and Vegt, J. (2006), Een SOA is prettig, De route naar servicegericht denken en doen, ISBN 90-78375-01-9. [61] Parker, D.B. (2002) Toward a New Framework for Information Security,” The Computer Security Handbook, 4th ed., Seymour Bosworth and M. E. Kabay [62] Pfleeger, C.P. and Pfleeger S.L. (2006), Security in Computing, Fourth Edition, Prentice Hall, ISBN-10: 0-13-239077-9 [63] Pulier, E. and Taylor, H. (2006), Understanding Enterprise SOA, Manning Publications, ISBN 1-932394-59-1 [64] Russel, D, Gangemi, G.T.(2001), Computer security basics, O’reilly Media 1991. ISBN 0-93-7175-714-X [65] Salomon, D. (2006), Foundations of Computer Security, Springer-Verlag London Limited, ISBN 1-84628-193-8 [66] Sherwood, J., Clark, A., Lynas, D. Enterprise Security Architecture, CMP Books 2005. ISBN 1-57820-318-X [67] Stamp, M.,(2006), Information Secruity, Principles and practice. ISBN-13 978-0- 471-73848-0 [68] Szyperski, C.(2002), Component Software, Addison-Wesley 2nd edition 2002. ISBN 0-201-74572-0 [69] Tanenbaum, A.(2002) Computer Networks. Prentice Hall, 4th edition, ISBN 0130661023 Web sources [70] BEA AquaLogic Enterprise Security™®, Integrating ALES with Application Environments, version 2.1, http://e- docs.bea.com/ales/docs21/pdf/integrateappenviron.pdf [71] BEA, BEA AquaLogic Service Bus behind the Firewall in Service-Oriented Architecture, http://dev2dev.bea.com/2006/10/aqualogic-service-bus-firewall.pdf [72] Computer Security, http://www.wikipedia.org/wiki/computer_security, accessed 26-07-2007 [73] CSI/FBI computer crime and security survey 2006, http://www.cse.msu.edu/~cse429/readings/FBI2006.pdf [74] French, B. (2006), Implementing SOA security, IBM Corporation. ftp://ftp.software.ibm.com/software/tivoli/whitepapers/ImplementingSOAsecuri tyG507-1918-00.pdf.pdf [75] Gartner Inc, (2007), Press Release, http://www.gartner.com/it/page.jsp?id=503864

Appendix C 111 [76] Gutman, P. (2004), Why XML Security is broken, http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt [77] He, Hao, SOA without WebServices http://softtouchit.com/xpe/bams?name=SOAWithoutWS.pdf [78] Hill, B. (2007), Attacking XML Security. http://www.isecpartners.com/files/iSEC_HILL_AttackingXMLSecurity_bh07.pdf [79] IBM, Service oriented modeling and architecture, http://www.ibm.com/developerworks/library/ws-soa-design1/ [80] IBM, Uwe Kissmann, SOA Security, http://www.ibm.com/ru/events/presentations/bf2006/soa_security.pdf [81] ISO 9126, http://en.wikipedia.org/wiki/ISO_9126, accessed 18-11-2007 [82] JavaWorld, (2002), Yes, you can secure your Web services documents, http://www.javaworld.com/javaworld/jw-10-2002/jw-1011- securexml.html?page=2 [83] New Rowley group, The challenge of securing SOA, December 2006 v1.0 ftp://ftp.software.ibm.com/software/tivoli/whitepapers/nrg_soa_sec_best_practic es_v1_0.pdf [84] Nezhad, H.R.M and Skogsrud, H. and Benatallah, B. and Casati F. Securing Service-Based Interactions: Issues and Directions. http://info.computer.org/portal/site/dsonline/index.jsp?pageID=dso_level1&pat h=dsonline/topics/was/papers&file=motahari.xml&xsl=article.xsl [85] OASIS (2004), UDDI version 3.0.2, http://www.oasis-open.org/committees/uddi- spec/doc/spec/v3/uddi-v3.0.2-20041019.htm [86] OASIS, WS-Security version 1.1 http://www.oasis- open.org/committees/download.php/16790/wss-v1.1-spec-os- SOAPMessageSecurity.pdf [87] OASIS,(2007) WS-SecureConversation version 1.3, http://docs.oasis-open.org/ws- sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.html [88] OASIS. (2007), Web Services Business Process Execution Language Version 2.0, http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html [89] OASIS, Reference Model for service oriented architecture 1.0, Committee specification 1, 2 august 2006. http://www.oasis- open.org/committees/tc_home.php?wg_abbrev=soa-rm [90] OASIS, eXtensible Access Control Markup Language (XACML) version 2.0. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml [91] Pajevski, M. J.(2004), A Security Model for Service Oriented Architectures, http://www.oasis-open.org/committees/download.php/17573/06-04- 00008.000.pdf

Appendix C 112 [92] Peterson, G., Lipson,H. (2006), Security Concepts, Challenges, and Design Considerations for Web Services Integration. https://buildsecurityin.us- cert.gov/daisy/bsi/articles/best-practices/assembly/639.html, Carnegie Mellon University. [93] Security and management for SOA environments, IBM Whitepaper 2006. ftp://ftp.software.ibm.com/software/tivoli/whitepapers/GC28-8455-00.pdf [94] Seduhkin, I.,(2003), End-to-End Security for Web Services and Service Oriented Architectures, Computer Associates. http://www.webservices.org/companies/ca/end_to_end_security_for_web_servi ces_and_services_oriented_architectures [95] SOA Software, Whitepaper Security issues in the SOA. http://www.soasoftpressroom.com/SOASoft_Security_Issues_in_SOA_Whitepap er.pdf [96] The Internet Engineering Task Force, RFC 2119, http://www.ietf.org/rfc/rfc2119.txt [97] The Internet Engineering Task Force, RFC 3546 http://www.ietf.org/rfc/rfc3546.txt [98] W3C. (2007), SOAP version 1.2 http://www.w3.org/TR/2007/REC-soap12-part0- 20070427/ [99] W3C. (2002), XML-Signature Syntax and Processing Recommendation http://www.w3.org/TR/xmldsig-core/ [100] W3C. (2001), Canonical XML version 1.0, http://www.w3.org/TR/xml-c14n [101] W3C. (2004), Web Services Architecture, http://www.w3.org/TR/ws-arch/ [102] W3C. (2004), Web Services Addressing, http://www.w3.org/Submission/ws- addressing/ [103] W3C. (2001), Web Service Description Language version 1.1, http://www.w3.org/TR/wsdl [104] W3C. (2007), SOAP version 1.2, http://www.w3.org/TR/soap12-part1/ [105] Web Services Interoperability Organization. (2005), Security Challenges, Threats and Countermeasures Version 1.0, http://www.ws- i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf [106] Webster, Security. http://www.merriam-webster.com/dictionary/Security accessed 11-07-2007 [107] Webster, Secure, http://www.merriam-webster.com/dictionary/Secure accessed 11-07-2007

SOA security

by Zubin67

Accessibility

Upload Details

Usage Rights

Statistics

SOA security Document Transcript