SOA SECURITY




                            JAMIE FIERE




A THESIS SUBMITTED IN PARTIAL FULLLMENT OF THE REQUIREMENTS F...
Acknowledgements

This thesis is the result of an internship that started in April and ended in November
of 2007 at Zwitse...
Contents

Acknowledgements ..................................................................................................
3.3        SOA Security elements......................................................................... 32
      3.4    ...
Content-2-concerns table ........................................................................................ 78
Viewp...
List of figures

Figure 1 Union security and SOA security ...................................................................
List of tables

Table 1 Alternative naming for elements of SOA ...................................................... 9
Ta...
0BService-Oriented Architectures                                                      1




Introduction

This chapter int...
Introduction                                                                      2


Commission in England estimates loss...
Introduction                                                                           3


One of these implementations is...
Introduction                                                                         4


In addition to research papers, s...
Introduction                                                                      5


Design

The reference model for as s...
Introduction                                                                      6


Research process




               ...
Introduction                                                                      7


Constraints

Security concepts

At t...
0BService-Oriented Architectures                                                    8



Chapter 1


Service-Oriented Arch...
Service-Oriented Architectures                                                          9


Standards (OASIS 5 ). OASIS ha...
Service-Oriented Architectures                                                       10


Service

Services are at the cor...
Service-Oriented Architectures                                                         11


Service registry

A service re...
Service-Oriented Architectures                                                        12


1.4       SOA technical impleme...
Service-Oriented Architectures                                                   13


service through a network is invocat...
Service-Oriented Architectures                                                    14


Enterprise Service Bus

The Enterpr...
Service-Oriented Architectures                                                        15




                             ...
Service-Oriented Architectures                                                    16


common layers. Because there is no ...
Service-Oriented Architectures                                                   17


Standardization in the organization
...
Service-Oriented Architectures                                                     18


requirements is to reuse the funct...
Service-Oriented Architectures                                                       19


developers can just discover ser...
Service-Oriented Architectures                                                   20


compose new service by using existin...
Service-Oriented Architectures                                                   21


3. no externally observable state
Wh...
SOA security                                                                       22



Chapter 2


Security

2.1     Int...
Security                                                                            23


depends on how valuable, and how ...
Security                                                                              24


means that the computer system ...
Security                                                                              25


instance [1] and [27], claim th...
Security                                                                          26


security mechanisms should prevent ...
Security                                                                             27


Parker proposes the principles t...
Security                                                                               28


Authentication

Authentication...
Security                                                                           29


2.7        Conclusion
Security as ...
SOA security                                                                        30



Chapter 3


SOA security
This ch...
SOA security                                                                       31


functionalities. A service can for...
SOA security                                                                     32


that control all traffic from the ex...
SOA security                                                                       33




                             Fig...
SOA security                                                                        34


Services can be built upon (legac...
SOA security                                                                                          35


Table 4 provide...
SOA security                                                                         36


available. In practice, it is ne...
SOA security                                                                       37




     Figure 11 Enveloping signat...
SOA security                                                                    38


   2. Asymmetric key.
   3. Via third...
SOA security                                                                     39


   SAML can define authorization and...
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
SOA security
Upcoming SlideShare
Loading in …5
×

SOA security

1,649 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,649
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
92
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SOA security

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. Content-2-concerns table ........................................................................................ 78 Viewpoints ............................................................................................................. 83 Appendix C ............................................................................................................ 86 Appendix D............................................................................................................ 99 Appendix E .......................................................................................................... 101 Appendix F .......................................................................................................... 102 References ........................................................................................................... 106
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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.
  10. 10. 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.
  11. 11. 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.
  12. 12. 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.
  13. 13. 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.
  14. 14. 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.
  15. 15. 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.
  16. 16. 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/
  17. 17. 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.
  18. 18. 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
  19. 19. 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.
  20. 20. 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.
  21. 21. 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.
  22. 22. 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
  23. 23. 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.
  24. 24. 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
  25. 25. 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
  26. 26. 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.
  27. 27. 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
  28. 28. 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.
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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.
  33. 33. 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,
  34. 34. 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.
  35. 35. 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
  36. 36. 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].
  37. 37. 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
  38. 38. 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
  39. 39. 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.
  40. 40. 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].
  41. 41. 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.
  42. 42. 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
  43. 43. 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).
  44. 44. 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.
  45. 45. 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.
  46. 46. 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

×