A complete software development process of a general report publication service implemented using Web Services

Transcription

1 A complete software development process of a general report publication service implemented using Web Services Anders Nilsson & Klas Fahlberg February 1, 2008 Master s Thesis in Computing Science, 2*30 ECTS credits Supervisor at CS-UmU: Jerry Eriksson Examiner: Per Lindström Umeå University Department of Computing Science SE UMEÅ SWEDEN

2

3 Abstract Currently the reports from the business conducted in the Web portal LISA are generated and distributed manually. The people at GE Capital Solutions had a vision where this process is automated and reports can be requested and distributed in LISA. This thesis is about the software process surrounding the design and implementation of a system for publishing, generating, and distributing reports. Software architecture and Internet security were explored in the in-depth studies in order to obtain the knowledge required to create a solid design. The result of the thesis work is a fully automatic infrastructure for publishing reports designed using a service oriented architecture (SOA). The system is divided into two parts; the service that publishes and generates the reports and a front end that acts as the interface for the user. Our tests show that the system is both easy to use and general enough to support all currently available report types.

4 ii

5 Contents 1 Introduction 1 2 Problem Description Problem statement Requirements Scope Goals and purpose Software development focusing on Software Architecture and SOA SOA Web Services Software development processes The Waterfall process Iterative processes Development processes suitable for SOA projects Discussion Software Architecture Stakeholders Software Architectural Document Views and viewpoints Perspectives Discussion Internet security focusing on Web services and J2EE Basics of security Security requirements and goals Cryptography Critical application security flaws and exploits Threat modeling Strategies for building robust security The four W s iii

6 iv CONTENTS Unified Process for security design Risk analysis Trade-off analysis Security patterns Best practices Reality checks Security testing J2EE security architecture J2EE architecture and its logical tiers J2EE security architecture and mechanisms Web service security - standards and technologies Web service architecture Core security issues Web service security standards Accomplishment Planning Requirements gathering Mockup Use case System design The Web Service The front end in LISA The tool for creating report types Techniques, softwares and frameworks used Web Services WSDL SOAP UDDI Java EE Frameworks Spring XFire Logging Application servers Queue management Other technologies Java Servlet JSP JavaBeans

7 CONTENTS v 7 Results Screen shots Documentation Conclusions Restrictions/Limitations Future work Acknowledgements 87 References 89 A Use case 93 A.1 Use Case UC1: List available reports A.2 Use Case UC2: Request report A.3 Use Case UC3: List report request A.4 Use Case UC4: Delete report A.5 Use Case UC5: Assign report access to users A.6 Use Case UC6: Assign data IDs to user

8 vi CONTENTS

9 List of Figures 3.1 The different phases in the waterfall model Illustration of the different phases in the waterfall model, taken from [23] The project triangle, taken from [28] Illustration of how perspectives can be applied to views Example of an attack tree Secure UP: Security disciplines, taken from [18] Protection domains Web services operational model An overview of the system An overview of the elements in the request process Listing of the report types that are available An automatically generated input form The status page for requested reports The download page for a report The page for administrating which users has access to a report The page for administrating which Data IDs a user has access to The tool for publishing new reports The view for adding a parameter vii

10 viii LIST OF FIGURES

11 Chapter 1 Introduction General Electric - Capital Solutions (referred to as GE from here on) has got a Web portal called LISA where vendors can do business with each other. The vendors regularly request reports on how their businesses are going. At the moment these reports has to be requested, generated and distributed manually. GE wants a system where this process is automated so that a vendor can place an order for a report and make a report request directly in LISA. This thesis is about the software process surrounding the design and implementation of a general report publication and generation system. The work has been done in close collaboration with the staff working at the IT department at GE s office in Stockholm. The thesis includes two in-depth studies. One about software development focusing on software architecture and SOA, and one about Internet security focusing on J2EE and Web services. The following listing contains the outline for this report: Chapter 2 describes the problem. Chapter 3 contains the in-depth study about Software architecture. Chapter 4 contains the in-depth study about Internet security. Chapter 5 explains the accomplishment describing how and why the system was designed and implemented. Chapter 6 describes the techniques and softwares used for the implementation. Chapter 7 contains a discussion of the result and what future work can be. done Chapter 8 show acknowledgements. 1

12 2 Chapter 1. Introduction

13 Chapter 2 Problem Description This chapter describes the problem in detail together with goals and purposes. 2.1 Problem statement As mentioned in the introduction GE wants a more automated way of handling the reports related to the business conducted in the LISA Web portal. The reports are currently generated upon a request via phone or . The report is created by running a stored database procedure and the resulting file(s) (usually in Excel format) are sent via back to the vendor. GE had a vision where an administrator publishes a report in a database. The service would then automatically make the report available to the vendors in LISA. The report is represented in the database by the input parameters and other information related to the report so that it can be requested by the user. Since each vendor has different kinds of reports and come from different countries, the service has to be general and support multiple languages. The security of the service is crucial since the reports can contain sensitive business data Requirements GE only had a few initial requirements. The rest of the requirements were acquired in the software development process. The initial requirements were: The system must be general enough to be able to handle all kinds of reports. The system must support internationalization, making it available in several languages. The access to the reports must be limited in order to protect them from users that are not allowed to see the reports. 2.2 Scope The scope of the thesis is to design and implement the following prototypes: A report generation service that publish and generate the reports. 3

14 4 Chapter 2. Problem Description A Web portal where the vendors can discover and request reports. A tool for publishing new reports to the report generation service. The tool will be used by the local administrators. What falls out of the scope for the thesis is to write the database procedures that generates the actual report files. Some of these procedures already exist and those procedures have been reused to develop the prototype. 2.3 Goals and purpose The goal of the thesis is to produce an automated system where an administrator can publish new reports that the vendors then can request in an easy-to-use interface. Another goal is to treat the thesis as a real software development process to utilize the knowledge from the in-depth study about software development. The knowledge gained in the in-depth study about Internet security will be utilized through out the whole development process to make the system secure. The purpose of the system is to eliminate the manual labor of running database procedures and ing report files.

15 Chapter 3 Software development focusing on Software Architecture and SOA This chapter will describe some of the most commonly used software development processes and investigate how these processes will affect the success rate of a project and which are suitable for SOA development. The chapter also contains a section about Software Architecture and how views and perspectives can be applied in order to achieve a well documented architecture and a clear overview of the system. Since it is important to know about SOA in order to compare the different processes that are suitable in SOA projects the chapter will begin with a short description of that architecture. 3.1 SOA SOA stands for Service Oriented Architecture and is a structure for the communication between services. A service is a small distinct unit of functionality and SOA represents a model where services can be distributed over a network and reused to create business applications. The interaction between the services is defined using a description language and each interaction is independent. The services are loosely coupled meaning that the service interface is independent of the implementation [19, 30]. In [10] the author writes about the following key characteristics of SOA: It contains self describing interfaces in XML, which is platform independent. An example is WSDL (Web Service Definition Language), which is a language for describing Web services. WSDL will be covered more thoroughly in chapter 6. The communication between services is defined using XML-schemas. The environment in which the services communicate is often heterogeneous and often there is no information about the provider. To keep track of the services a registry where the services are published is used. When an application needs to communicate with a service, the service can be discovered using the registry and the application can invoke its operations. UDDI, 5

16 6 Chapter 3. Software development focusing on Software Architecture and SOA which stands for Universal Description, Definition, and Integration is the standard for communicating with a service registry. The fourth characteristic of SOA is that each service has a quality of service associated with it. Some examples are elements of security, such as authorization and authentication Web Services One common way to implement SOA is to use Web services. The distinction between service oriented architecture and Web services is that Web services are about technology while SOA is a software design principle. Web services are services that are built upon a set of standards [10]. By making it possible to implement functional building blocks that can communicate independently from platform and programming language it has become an increasingly popular technique to use [10]. 3.2 Software development processes According to [17] a software project is a set of activities that leads to the production of a software product. It exists many different software processes but they all have four things in common: 1. They contain a software specification where the functionality of the software and constraints on its operations are defined. 2. The software is designed and implemented to meet the specification. 3. The software must be validated to ensure that it has the correct behavior. 4. Evolution of the software where it evolves to meet changing requirements. A software model is an abstract representation of a software process. Each model describes approaches to different tasks or activities that take place during that process [17]. There are many software development processes available and the following sections will describe some of them in order to see how suitable they are for SOA projects The Waterfall process The waterfall model is a sequential process in which the development is progressed downwards like a waterfall. The model consists of five phases and each of them must be completely finished before the project can progress to the next one [33]. The different phases are illustrated in figure 3.1 on page 7 and described further below. Requirements The first step is to gather the requirements that the system must fulfill. This is done by doing consultation with the users of the system. The constraints and goals are defined in detail and serve as a system specification [17].

17 3.2. Software development processes 7 Figure 3.1: The different phases in the waterfall model. Design The system is thereafter designed, which will partition the requirements into hardware and software systems. The architecture is established by identifying the fundamental software system abstractions and their relationships [17]. Implementation After the system is designed a set of programs are implemented and tested. Each unit is tested individually in order to verify that it meets its specification [17]. Verification The different program units are integrated and tested together to ensure that the system has fulfilled the software requirements. The system is delivered to the customer when all tests have been successfully performed [17]. Maintenance The last step includes operation and maintenance of the system. This is normally the longest phase. The system must be adopted to new requirements that have been discovered and errors that were not discovered in earlier stages must be corrected [17] Iterative processes The requirements often change when dealing with large software projects. This affects the design and the implementation. Iterative processes address this issue by regularly repeat tasks in iterations, where the specification is developed in conjunction with the software. Three of the most common and interesting iterative processes will be described in the following sections [17].

18 8 Chapter 3. Software development focusing on Software Architecture and SOA RUP The Rational Unified Process is a well documented process that is characterized by three things [11]: 1. Use cases Use cases are used to discover and record the requirements in the system. They consist of text stories describing how some actor is using the system in order to achieve one or several goals. An actor can be a person, computer system or organization. The characteristic of an actor is that it is something that has a behavior. It can for example be a person or a computer system. A use case is a collection of related success and failure scenarios that describe the actor using the system with the aim to reach goals. A scenario is a sequence of actions and interactions between actors and the system. A use case can be written in three different levels of formality; brief, casual and fully dressed. Brief use cases are one-paragraph summaries containing the main success scenario. The casual format consists of multiple paragraphs that cover various scenarios. When the use cases are fully dressed every step and variation is documented in detail containing supporting sections such as preconditions and success guaranties. 2. Architecture-Centric The architecture is a function of the needs of the users, which is captured in the use cases. Since the architecture is central in the unified process it will shape the system. 3. Iterative and Incremental The rational unified process is an iterative software development process. The development is organized into short iterations of fixed length. At the end of each iteration a result is achieved, which is a tested, integrated, and executable part of the system. Each iteration contains a requirement analysis, design, implementation and testing activity. The system will grow incrementally after each iteration and become more and more refined. The iteration process is divided in four major phases: inception, elaboration, construction and transition. Figure 3.2 on page 9 illustrates these phases and in which order they are performed. A more detailed description of the phases follow below: Inception The first step is to establish a common vision and basic scope for the project. This is done in the inception phase, which is the smallest of the four iterations. It will include analysis of about 10% of the use cases, creation of a business case, preparation of the development environment, and analysis of the critical non-functional requirements. The purpose is to establish the objectives of the project and determine if it is feasible. Elaboration In the elaboration phase the majority of the use cases are defined in detail and the system architecture is specified. The core architecture that has the highest risk of failure is implemented and tested. The high-risk elements are resolved and an estimate of the overall schedule and resources is created.

19 3.2. Software development processes 9 Figure 3.2: Illustration of the different phases in the waterfall model, taken from [23]. Construction During the construction phase the remaining low-risk and easy elements are implemented. This is the largest phase and is built on the foundation laid in the elaboration phase. Features are developed in short time-boxed iterations where the result of each iteration is an executable release of the software. The end date is set in stone and may not be changed. Transition Transition is the fourth and final step and the goal in this phase is to ensure that the requirements have been met to the satisfaction of the stakeholders. Beta releases are often made available in this step and the feedback from the initial release may further refine the system. The transition phase also includes site preparation, manual completion, and error identification and correction. During the iterations a number of core workflows are identified and these are; business modeling, requirements, analysis, design, implementation, and test and deployment. These workflows are not sequential and will most likely be worked on during all of the four phases. Figure 3.2 shows during what phases they will be performed. Iterations within RUP are supported in two ways. Each of the four phases may be enacted in an iterative way where the results are developed incrementally. In addition the whole set of phases may also be performed iteratively which can be described as iterations of oterations [17][23]. UML UML stands for Unified Modeling Language and it was developed in conjunction with the unified process. It is a visual language for specifying, constructing and

20 Chapter 3. Software development focusing on Software Architecture and 10 SOA documenting the artifacts of the system. UML can be applied in three ways: As a sketch with informal and incomplete diagrams which are created to explore the difficult parts of the problem. As a blueprint which contains relatively detailed design diagrams used for either reverse engineering to visualize existing code, or for forward engineering where classes and interfaces are generated from UML. The final way is as a programming language where executable code automatically is generated from the specification in UML [11]. Agile models Agile models are a family of development processes which all promote iterative development throughout the project. A group of people interested in iterative and agile methods met in 2001 and the outcome from that meeting was the Agile Alliance. A manifesto and statement of principles to capture the spirit of agile methods were created by the alliance. The main difference between the waterfall model and agile models is that waterfall features distinct phases with deliverables at each phase, while agile methods have iterations rather than phases. The result of each iteration is working code that can be used to evaluate and respond to changing requirements. Small teams work together with stakeholders in order to develop prototypes in a fast way that can be used as proof of concept or to visually describe the problem. The work that the teams must perform during the iterations is to define the requirements, develop the code, test the code, and verify the code. This results in earlier verification compared to the waterfall model, which will result in much more fine-tuned requirements [20]. Two of the most common agile software development processes are Extreme Programming and Scrum. Both of them are described in the next two sections. XP XP or Extreme Programming concentrates on the development rather than the management of a project. The process was developed due to the many projects that were running over budget, could not meet the project plan and were terminated prematurely [21]. XP projects starts with a release planning phase. This phase is followed by a number of iterations, each of which concludes with user acceptance testing. When the users are satisfied with the features, the software is released [22]. XP is based on five values [22]: Communication Continuous communication between the customer and the developers is important. This is achieved by having the customer close to the developers where it is possible to quickly decide the requirements and how they should be prioritized. Simplicity The simplicity is achieved by constantly refactoring the code and keeping the number of documents as low as possible. The developers should always start with the simplest solution first and add more functionality later in the project. Feedback By writing unit tests the developers get feedback from the system after implementing changes. The acceptance tests, which are written by the customers gives the testers feedback on the current state of the system. Courage The developers must have courage to remove source code that is obsolete despite

21 3.2. Software development processes 11 of how much effort it took to implement. Courage also means persistence. By working on a problem persistently it is more likely to be solved. Respect The team members should respect each other by never committing changes that break the compilation or make existing unit tests fail. Members respect their work by trying to produce as high quality results as possible. Scrum The name scrum comes from a rugby term for a mass of players engaged with each other to get the job done. In the software development process the job is to develop software that can be released to the production environment. The focus in scrum is not purely on development like in XP, but also on management. The development and management in Scrum are described below [29]: Management Each scrum project has a backlog of work to be done that is produced during the planning phase. The product backlog contains prioritized items describing what will be implemented during the project. When the product backlog is complete the process is divided into a series of short iterations, called sprints. A sprint has its own backlog with the part of the product backlog that the team will implement during the sprint. The two backlogs are however two different things. The sprint backlog is the team s interpretation of the product backlog and it contains concrete tasks, while the product backlog contains high level requirements. During a sprint the team has daily meetings, called scrums, where each team member describes what work was done during the previous day and what work will be done during the coming day. When the implementation is done, which happens when enough of the backlog items have been implemented, management closes the development. The team thereafter performs integration testing, training, and documentation before the product can be released. Development The development is concentrated to the sprints. Before each sprint it is decided what the team will work on during the sprint. Since the product backlog is prioritized the tasks at the top of the list is chosen for the sprint. Teams develop, wrap, review, and adjust each of the backlog items that were chosen. The first task that must be done during each sprint is to determine the changes that are necessary to implement the backlog items. The team then writes the code, tests it, and documents the changes. In the wrap stage the team creates the executable that is needed in order to demonstrate the changes. The features are demonstrated and new items are added to the backlog together with a risk assessment. After each sprint a sprint review is performed where the entire team demonstrates the progress from the sprint. The remaining items in the backlog are also reviewed and new items are added, removed or reprioritized based on the information gained during the last sprint.

22 Chapter 3. Software development focusing on Software Architecture and 12 SOA Development processes suitable for SOA projects By looking at the software development processes that have been covered in this section it is hard to directly state which is the most suitable for SOA projects. None of them have all the desirable properties for a service oriented developing process. This section will compare the waterfall model, RUP and agile processes aginst each other in order to see what advantages and disadvantages they have in a SOA project. Waterfall model The waterfall model requires that the requirements are well understood and unlikely to change during the system development. A study performed by Bohem and Papaccio showed that a typical software project experience a 25% change in requirements. Other studies shows even higher change rates [11]. A SOA project is not different in this aspect and the waterfall model will not be suitable for this kind of project. RUP RUP provides a methodology that is focused on initial requirements, modeling and documentation together with the method principles of agile software development. SOA projects will benefit from these factors since requirements tend to change. RUP also addresses some of the key elements of SOA: re-usability, abstraction of business processes, flexibility, and code that is loosely coupled and finely grained. The reason for that is due to the practice to encourage component based architectures, which are the building blocks for services [3]. A drawback of using RUP in the creation of SOA-type application is that RUP is mostly object-oriented. Services however include many other factors that objectoriented design leaves out. For example, it ignores the underlying infrastructure such as protocols, location and technologies, and management [3]. When RUP is used the focus is often on large projects that in some cases can take several years to complete. In SOA projects however the system can be divided into smaller services that can be developed separately or become separate small projects. Another problem is that RUP only supports traditional reuse of system components where access to the source code is necessary. In service oriented projects the reuse of components are at another level where entire services can be reused and exchanged [14]. Another drawback that RUP suffers from is that it focuses on top-down development where systems are developed from scratch. Nowadays a combination of top-down and bottom-up is necessary where both new and existing work is to be combined and understood [14]. When a system that is using a number of services is to be developed much of the initial work is focused on specifying which services to use. Implementation and reuse of the services and how to put them together to a complete system are also important activities. The work is completely different when traditional analysis, design and implementation is performed. Agile Agile processes considers changes after every iteration which is a benefit for SOA projects since they consists in a highly uncertain environment where changes to business, code and so on is common. Another advantage is its instant communication with the customer. This is important since business rules and processes will change during the

23 3.3. Software Architecture 13 project. By having a direct communication with the customer an accurate description of the requirements and business needs can be achieved [3]. The communication between the developers is also high which will increase the productivity in SOA projects. Small teams and pair programming are example of factors that contribute to this [3]. There are however some drawbacks that must be mentioned. One is the lack of upfront design of the system and of its requirements. When services are used as building blocks a good design must exist. The reason for that is because the services must support changes in the business environment, together with an increasing amount of variables and at the same time work correctly in any situation. The design must therefore be thought through and incorporate all variables [3]. The lack of documentation can be problematic even if it is replaced by constant testing, pair programming and the availability of an on site customer. If a failure in the design exists it may take a long time to discover. It is also arguable if the customer can be available at all time and give a complete picture of the business situation. A good documentation is also important for billing purposes, since it explains the amount of work performed [3] Discussion When comparing the different developing processes against each other it becomes clear that there is no process that can be used without some kind of adaption. The waterfall model was excluded due to the high failure rate associated with it. SOA is relatively new and the waterfall model has been around for decades. Although it is possible to change the model to suit SOA in a better way by for example not having the strict boundaries between the different phases, we think it is a bad idea to begin the development process with the waterfall model. Iterative processes are clearly more suitable for modern projects where there are changes to the requirements during the development. By looking at the development processes described in previous sections we think that RUP is most suitable to fit SOA projects due to factors mentioned earlier. Parts from other methodologies can however be borrowed in order to develop a process that is suitable for the project. Depending on the size and amount of reuse that can be made, different approaches can be applied. Scrum meetings and fast iterations sounds interesting and could increase the productivity in a SOA project, especially for smaller projects. 3.3 Software Architecture Software architecture is defined as: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationship among them [15]. There are a lot of different aspects and concerns that must be addressed during a software-development process. A good software architecture can help to manage some of the problems that can occur. Every computer system has an architecture that is constructed from one or several architectural elements. The elements are linked together in some way with different complexity depending on the system. It is also possible that the elements will be interacting with elements from other systems. Each element or module possesses a defined set of responsibilities, a defined boundary and a set of defined interfaces which will be

24 Chapter 3. Software development focusing on Software Architecture and 14 SOA Figure 3.3: The project triangle, taken from [28]. used in the interaction with other modules [16]. Due to this fact it is important to achieve a well defined architecture that is understood by all the people that are involved in the project in some way. The next section will begin with a short description of the stakeholders of a system, followed by sections describing views and perspectives Stakeholders The purpose of a software project is often to develop software that fulfills the requirements established by interaction with the users. The users are however not the only people that will be affected by the system. There are also developers, administrators, testers and all others that have interest in the realization of the architecture. All these people are referred to as the stakeholders of the system. The stakeholders have different concerns about the architecture, which in many cases conflict with each other. It is often impossible to develop an architecture that satisfies all the important attributes. The project triangle, also called the quality triangle that can be seen in figure 3.3 on page 14, illustrates the fact that it is impossible to achieve a product that has low cost, high quality and a short time to market. Compromises between these attributes must be done and it is often only possible to choose two of the three corners in the triangle [16, 28] Software Architectural Document It is important to document the architecture in such a way that it can be effectively communicated to the different stakeholders. This is done in a software architectural document. The document will contain a comprehensive architectural overview of the system and covers the significant architectural decisions [16] Views and viewpoints Views and viewpoints are important concepts in software architecture because they introduce a separation of concerns into the architectural description. A view is defined as: A representation of one or more structural aspects of an architecture that illustrates how the architecture addresses one or more concerns held by one

25 3.3. Software Architecture 15 or more stakeholders [16]. The content of the view should depend on which stakeholders the view is aimed at. Different stakeholders have different areas of expertise and the views should be designed with that in mind. A viewpoint is defined as: A collection of patterns, templates, and conventions for structuring one type of view. It defines the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template models for constructing its views [16]. The difference between a view and a viewpoint is that a viewpoint is a way of looking at a system while a view is what you see when looking from the chosen viewpoint. A viewpoint is a set of rules or methods, which will allow the architect of the system to create the architectural document [16, 12]. The following sections will describe some of the most common viewpoints used by software architects where each viewpoint contains models that are of importance together with possible problems associated with the viewpoint. Functional viewpoint Definition: Describes the system s runtime functional elements and their responsibilities, interfaces and primary interactions [16]. The functional view is the foundation of the architecture description and it illustrates how the system can assess the functional requirements. Functional Structure Model The elements that a functional structure model contains are functional elements, interfaces, connectors and external entities [16]. A functional element is a part that has well defined interfaces, which makes it possible to connect it to other functional elements. Examples can be a software module, an application package or something similar. The interfaces are needed since they define the inputs, outputs, and the semantics of the operations. Connectors are used in the linkage between the elements and they allow the different elements to communicate with each other. The external entities represent other systems, hardware devices or some other element that the system communicates with [16]. Problems One common problem that a software architect can face when constructing the functional view is that the interfaces are poorly defined because the responsibilities of the elements are not fully understood. The view can also become overloaded with information that belong in other viewpoints. It is important to write the diagrams that include the element definitions. A diagram without definitions will lead to a model that is meaningless [16]. Since the functional viewpoint is of interest to many types of stakeholders where each needs to be communicated to in different ways, it can be hard to create a single model or notation that is suitable for everyone. Several models must be created with different modeling languages depending on the stakeholders [16]. Information viewpoint Definition: Describes the way the architecture stores, manipulates, manages, and distributes information [16].

26 Chapter 3. Software development focusing on Software Architecture and 16 SOA The information viewpoint will, as the definition states, describe how the system handles information. This is important since all information system stores, manipulates or distributes information in some way [16]. The topics that the information viewpoint must assess are the structure and content of the information, the flow of information, data ownership, latency, references, transaction management and recovery, data quality, and data volumes and regulations. The following three models are common in the information viewpoint [16]. Static Data Structure Models The static data structure model describes the static structure of the data, which consists of the important data elements and the relationships between them. Examples of techniques in data analysis are Entity-relationship modeling 1, and class models 2 [16]. Information Flow Models To model how data is transferred from one component to another the information flow model has been created. The model studies the dynamic movement of information between the different components of the system, other systems or parts of the outside world. Coupled with each flow is a direction, information about the volume of data, the scope of the data, and the means by which the data is transferred [16]. Information Lifecycle Models The information in a system will probably change after a while and therefore it is important to analyze how the data changes over time. This is done in the information lifecycle model. Data often changes during its lifecycle in response to external events in updates, until it is deleted. This scenario is captured in entity life histories. The record of the overall changes in a system is presented in the state transition models. An example of a state transition model is a UML state diagram which contains the possible state transitions for an object [16]. Problems Several problems can occur in a system from an information viewpoint. Different systems have different representation of data which can lead to incompatibility. The data can also be inaccurate, inconsistent or incomplete. These problems must be identified early in the process in order to be avoided [16]. The data can be updated from several locations at once which must be handled by the system by developing strategies for resolving inconsistencies. Some solution such as always overriding old updates with never ones, or maintaining two copies of data and resolving problems manually can be used [16]. The latency associated with the retrieval of information can be a problem if it is unexpectedly poor. The problem can arise from overly complex architectures that are not designed to handle the volumes of data that they are presented with [16]. Concurrency viewpoint Definition: Describes the concurrency structure of the system, mapping functional elements to concurrency units to clearly identify the parts of the system that can execute concurrently, and shows how this is coordinated and controlled [16]. 1 A relational schema used to model a system and its requirement in a top-down approach. Entity relationship diagrams is an end product of the modeling process. 2 Model where static class objects in a system and relationship between them are showed. The UML class model is a common notation.

27 3.3. Software Architecture 17 Many information systems today sit idle until an external event occurs and respond to the event by doing some processing. Since several events can occur at the same time the architecture must be designed to handle concurrency. The concurrency viewpoint assesses this by defining the parts of the system that can run simultaneously and how the parts are controlled [16]. The concurrency viewpoint is important because it will help stakeholders understand the constraints and requirements associated with concurrency. It will also help avoiding common problems that can occur when several parts run simultaneously such as deadlocks and bottlenecks [16]. System-Level concurrency models A system-level concurrency model associates functional elements with runtime execution entities. The model contains a number of items that is used in the description of the view [16]: An operating system process that provides an environment for the execution of one or many threads. It is assumed that the processes cannot interfere with each other in any other way than through a communication mechanism. A process group contains processes that are closely related to each other. The details of the processes in the group are not specified. An operating system thread that run within an operating system process. In a concurrent system different processes need to communicate with each other in order to pass information within the system. This is done via interprocess communication mechanisms. State models A state model describes which states the runtime elements in a system can be in, together with the transitions between the states. A state machine is a collection of states and transitions for one runtime element. All interesting state machines contribute to the overall state model [16]. A state model contains the following elements: A state that describes a condition for a runtime element. A transition that defines the change from one state to another. An event, which indicates that something has happened and often trigger some event. An action is an atomic piece that can be associated with a transition. Problems One problem that can arise when building the concurrency viewpoint is that the models can become too detailed. It is better to concentrate on what is architectural important, which is the overall concurrency structure. Since the concurrency in a system can be hard to understand it is important to keep the complexity low [16]. Other problems that can occur, if not careful considerations are taken at an early stage, are deadlocks and race conditions [16].

28 Chapter 3. Software development focusing on Software Architecture and 18 SOA Development viewpoint Definition: Describes the architecture that supports the software development process [16]. Since almost every software project has some element of development it can be of importance to create a development view. The reason for this is because it often requires a lot of effort to plan the development environment. The development viewpoint describes how the code is structured, dependencies, build and configuration management of deliverables, system-wide design constraints, and which standards to use [16]. Module structure models A module structure specifies which modules that the source code should be grouped in and how the modules communicate with each other at a higher level. Modules that are closely related can be grouped into layers together with the specification of the dependencies between them [16]. Common design models In order to reduce risk and duplication, standard approaches can be decided upon. It can also be helpful to have commonality among the system elements because it will decrease the technical coherence, which makes it easier to operate and maintain. The common design model specifies pieces that define these attributes [16]. Codeline models The codeline model will define the overall structure of the system s code. It also specifies how the code is controlled in form of configuration management, where different types of source code should be located, and how it should be maintained [16]. Problems This view is not intended to be a full design of how the system should be implemented. It is therefore important to keep the amount of work at a reasonable level. The architect must also be careful with the distribution of the level of details. It is easy to have an uneven focus on things which will make some concerns clear but other more difficult to understand [16]. Deployment viewpoint Definition: Describes the environment into which the system will be deployed, including the dependencies the system has on its runtime environment [16]. After the software has been implemented and tested it will be put into a real environment where it will operate. The deployment viewpoint specifies the physical environment in which the system is intended to run. It also defines the hardware required, the technical requirements for the hardware, and the mapping of the software elements to the hardware in which it will operate [16]. Runtime platform Models The runtime platform is the main model in the deployment viewpoint. The model defines what hardware is required, the network connections between the nodes, and which software elements are hosted on which hardware nodes [16]. In the model each computer is represented as a processing node and client hardware as client nodes. The storage hardware together with the capacity and speed is also specified both for online and offline storage nodes. Network links are captured in the

29 3.3. Software Architecture 19 model, but the bandwidth requirements are not specified. The system s functional elements are mapped to the processing nodes in which they will execute [16]. Network models This model will define a specification of the network in which the system will operate. The specification contains which nodes should be connected, the network hardware, and the bandwidth requirements. Processing nodes, network nodes, and network connection describes the model and is typically represented as a network diagram [16]. Technology dependency models To manage dependencies in the deployment environment a technology dependency model can be created. The technology dependencies can be documented for each node in tabular form [16]. Problems Many dependencies in the runtime environment is invisible and can not be checked easily. It is important to specify which versions are required and if patches are available. The use of new and unproven technology can also be risky because it can lead to functional shortcomings, less performance, availability, or security. Another problem can be to gather all the expertise required in order to design, develop, operate and maintain the different technologies [16]. Operational viewpoint Definition: Describes how the system will be operated, administrated, and supported when it is running its production environment[16]. The operational viewpoint illustrates the operational concerns that the user of the system is likely to encounter together with the solutions that can be applied during the implementation in order to solve the concerns [16]. Installation models This model describes how the system can be moved from the development environment to the production environment. The installation model illustrates what needs to be installed or upgraded in order to move the system to its operational environment, the dependencies between the parts that is installed or upgraded, the constraints on the installation process, and what need to be done in order to undo the process if something goes wrong [16]. Migration models The migration model defines the strategy that will be used if a migration process is required. This includes the overall strategy to migrate information and users to the system, how the system will be populated, how the synchronization between the new and the old environment will be kept, and how the migration process can be undone [16]. Configuration management models Some systems will need constant reconfiguration, which makes it necessary to have a configuration management model. The model should address which configuration items exist and how they are managed, the dependencies that exists between the configuration groups, the different configuration value sets required for normal operation, and how the values will be applied to the system [16].

30 Chapter 3. Software development focusing on Software Architecture and 20 SOA Administration models When a system has been developed and is running in the operational environment it must be maintained and administrated to some extent. The administration model will define the operational requirements and constraints of the architecture. The model should define the monitoring and control facilities that are provided in the system. It should also define the required routine procedures that an administrator must perform at a regular basis together with likely error conditions [16]. Support models It is very likely that the stakeholder will require some sort of support when the system is operational. The support model will provide information about what groups need the support, what kind of incidents can occur, which support providers exists and which responsibilities they have. In addition to that an escalation plan also needs to be documented. The escalation plan describes the process when several support providers need to contribute together in order to solve the incident [16]. Problems There can often be a gap between the development staff and the operational staff, which can lead to difficulties if both parties are not engaged early in the development process. Software is often passed to the operational staff without much thought on operational requirements. It is also important to have backout plans if something goes wrong and things need to be undone and migration plans if one system is to be replaced by the new system [16]. Another factor that can cause some problems is the lack of management tools. The developers can manage the system by using their knowledge of the system. The operational staffs often do not possess that knowledge and thus require more sophisticated management tools [16] Perspectives Definition: An architectural perspective is a collection of activities, tactics, and guidelines that are used to ensure that a system exhibits a particular set of related quality properties that require consideration across a number of the system s architectural views [16]. There exist some quality attributes that are common among all the views described earlier. It would not work well to define a new view for each quality property. Instead perspectives are used as an orthogonal way of describing these attributes. A perspective is applied to each view but it is never handled alone and in isolation. Figure 3.4 on page 21 illustrates how the perspectives are applied to the views where each square represents the application of a perspective to a view. The perspectives will work as guides on how to analyze and modify the architecture in order to make sure that the system possesses the particular quality attributes. Different perspectives have different effect on a system and the amount of effort that is applied to each perspective can therefore vary depending on the system. The perspectives should be applied as early as possible in the design of the architecture in order to help avoid problems with lack of performance, availability and so on [16]. Security perspective Security is often of most importance for large information systems and special concerns must be taken into consideration when designing the architecture. There are five steps that an architect should perform when applying the perspective on a view [16].

31 3.3. Software Architecture 21 Figure 3.4: Illustration of how perspectives can be applied to views. In the first step the sensitive resources are identified. This action will establish what needs to be secured in the system rather than how to secure it. The identification process is performed with the security requirements together with the functional and information views as input. The second action will define the security policy or a trust model. This step will form the basis for the security implementation in the system. During the work with this model the people that can be trusted in the system must be identified together with their access rights to resources. The model must also include the integrity guarantees required within the system and the accountability required when sensitive resources are accessed. In the third step the threats to the system are identified which will define what in the system needs to be protected and what it needs to be protected against. A common notation used when defining the threat model is an attack tree that contains an illustration of the threats that the system faces and the likely probability of each occurring. The fourth action is to design the security infrastructure that enforces the system s security policy. Technologies such as single sign on, firewalls, cryptographic technologies, and so on are decided upon in this step which will affect a number of views, primarily the functional, information, deployment and operational views. In the fifth and last step in the security perspective the security risks are assessed. This means that the risks needs to be reevaluated in order to see if an acceptable cost and risk balance has been achieved [16]. Problems When applying the security perspective there are some problems that can occur. One common problem is that the security policies become too complicated. Security is hard to implement as it is and if the policy is complex the job becomes

32 Chapter 3. Software development focusing on Software Architecture and 22 SOA much more difficult during both the implementation and operation. This will increase the likelihood of flaws in the security implementation. Other problems can occur when unproven security technologies are used. One security flaw is enough to expose the whole system. To avoid further problems the security infrastructure should be able to handle failures in a safe way in order to avoid unexpected failures that opens up a hole in the security. It is also important that the system can be administrated effectively when the system is operating. The administration tools should be able to handle the system load and be designed for the system [16]. Many security mechanisms rely on some reliable time source in order to work. If the time can be altered in some way there is a flaw in the mechanism that could lead to security issues [16]. If no clear requirements or models are specified there is no way to ensure that the system is secure. It is difficult to add the security after the implementation. It will lead to a lot of rework, if it is even possible. There can also be the case that parts of the system are secured in some way while other parts are not. An example can be that a transfer of a file from one location to another is encrypted but the storage is not [16]. Performance and Scalability perspective The performance and scalability perspective is important because these factors can cause problems if they are not considered at an early stage. Although Moore s law states that the number of transistors that can be placed on an integrated circuit is doubled every eighteen to twenty-four months, the tasks that the systems must perform also become much more complicated. The systems must handle more data, users, and so on. The performance of a software system depends on more than just the processing power. The way software is written, hardware configured, and resources allocated and handled are factors that play an important role when it comes to performance [16]. Scalability is also a measure of performance, but it focuses on how well the system will perform when the workload increases. If a system can handle the workload currently present but has poor scalability properties it will perform poorly when the workload increases [16]. The first step that must be done when a performance and scalability perspective is applied is to capture the performance requirements. The requirements should be quantitative which makes it possible to analyze and measure if they are met. After the performance requirements have been established the performance model can be created. The model should provide the ability to assess the maximum workload of the system and supply estimates for capacity planning. By analyzing the performance model it can be calibrated and the system throughput under different scenarios can be estimated. In parallel with the analyze of the performance model, practical testing should also be performed. The practical test can include benchmarks or other measures with the goal to determine some performance metric. When the performance analysis and the practical testing are finished the results of these activities should be compared with the performance requirements. If they differ modifications on the architecture may be needed in order to fulfill the requirements. It is also possible that further testing is necessary in which case the performance analysis and the practical testing need to be repeated [16]. Problems It is common that software projects fail to have a complete and clear set of performance goals or even to address scalability concerns. This will lead to problems

33 3.3. Software Architecture 23 since a suitable framework for designing, tuning, and building the system will not be available. Another concern is that the performance model does not capture all the performance issues in the system. The model is an abstraction of reality and is only as good as its match with the reality. A common pitfall is to oversimplify the performance testing and modeling process. The practical tests that are performed must reflect how the real system will behave in order to get a reliable measurement [16]. Invalid environment and platform assumptions can also occur when new technology is used or technology that has never been used before is tested. It is also common that problem arises although there exists technology to avoid the problems. This can happen when the technology is misconfigured, used in the wrong way, or when the developers decides to write the software themselves [16]. When concurrency is introduced in the system the potential for contention is high. The reason for this is that threads often spend a lot of time waiting for other threads to finish in order for it to continue to solve the task. To avoid bottlenecks it is important to test the behavior of critical elements as early as possible [16]. Hardware has become cheap which leads to an increased amount of available computing power. Nowadays we do not have to be so careful with allocating resources. It is however a costly process of freeing up resources such as memory and locks at runtime, which has got a negative effect on the performance of the system [16]. Availability and resilience perspective The availability and resilience is important if the system has high requirements regarding these factors. A system must often be available at all time [16]. In order to ensure that the architecture is designed with an availability and resilience perspective a number of actions must be taken [16]: 1. The first step is to capture the availability requirements by working with the stakeholders to understand and validate the availability and categorizing them by the service they provide. 2. After the requirements are acquired an availability schedule should be produced. The schedule defines when the different system services need to be available and if the service under any period does not need to be in service. 3. In the third step an estimate of the platform availability is produced which will provide an accurate estimate of the availability of the underlying hardware and software. The estimate is the maximum theoretical availability that the system can provide. 4. In parallel with the estimate of the platform availability an estimate of the functional availability should also be done. This action must be performed since the system design will likely impose further unavailability of the system. In many cases a system require some period where it can not provide full functionality due to internal processing, updates, or some other task that must be performed. By drawing a functional availability schedule it becomes clear under which periods the system cannot provide full functionality. 5. After the estimates have been done an assessment of the architecture against the requirements must be performed. This action includes ensuring that the overall level of availability is acceptable and that the no availability risks are too high. If the requirements are not met the architecture needs to be reworked.

34 Chapter 3. Software development focusing on Software Architecture and 24 SOA Problems One common problem introduced in some systems is the single point of failure, which means that if one single element fails the whole architecture fails. The risk can be reduced by introducing replication and duplication but it can be very expensive. If a requirement states that the system must be available all time, maintenance and other task that must be performed during operation can be difficult. It is therefore important to assess the requirements in order to establish if it is cost effective to have the high availability [16]. Another problem that can occur is that different pieces of third-party software do not work together in a perfect way. If they do not work together under normal conditions it is unlikely that they will work correctly during a failure [16]. Evolution perspective Software systems often change over time and software that has not been designed with respect to this property can be difficult to change. The evolution perspective deals with the fact that the architecture should be designed in a way that changes can be performed as easy as possible [16]. The first step that must be taken in order for the architecture design to fulfill the evolution requirements is to characterize the evolution needs. This implies understanding the requirements and further analysis of the existing requirements. It must be determined what is likely to change over time, the type of change, magnitude of the change, likelihood of the change, and timescale of the required change. For each of the evolution requirements defined a scenario should be developed. The scenario will explain how the system must change in order to meet the requirement when it becomes necessary [16]. If the architecture need changes in order to support the evolution requirements the effort of creating a flexible system can be done during initial development or when the system changes are required. The choice depends on the type of system and the likelihood that the changes will be required [16]. Problems A problem that often occurs during the design of the architecture is that focus is put on wrong things. When this happens the architecture becomes more complex and expensive to build but not easy to change. Another problem can arise if the system is too flexible. It can affect the runtime efficiency and performance. It is however not impossible to design an architecture that have both high performance and high flexibility [16] Discussion All the viewpoints and perspectives that have been described in this chapter are of importance in a SOA project. The functional viewpoint is important since it will describe most of the functional requirements that exists and how they can be assessed. The viewpoint will contain the interfaces of the system and well defined interfaces are very important in SOA development. The information viewpoint will describe how the architecture stores, manipulates, manages and distributes information which is of importance in service based architectures. In SOA services can be executed concurrently and the architecture must be designed with this knowledge in order to avoid the problems that are associated with it. The concurrency viewpoint can contribute to the elimination of possible failures and help

35 3.3. Software Architecture 25 the stakeholders to understand the constraints and requirements associated with concurrency. The development, deployment and operational viewpoints apply to almost every system that is developed and deployed in a production environment. Systems developed in SOA will therefore benefit from an architecture that has been planned with these viewpoints in mind. In addition to the viewpoints every perspective will also describe properties that are important in service oriented systems. The security is often very important in a business application and a whole chapter has therefore been assigned to that area. Since services often are accessible over a network scalability and performance become increasingly important. If a SOA application is not scalable and has good performance the bussiness can suffer big consequences financially. The availability perspective will also be of most importance since the services must be able to handle requests at any time. If a service is not available it can also lead to consequences that have a big impact on the company that is responsible for the system. When a service oriented architecture is developed it is often impossible to apply every model of every viewpoint to every perspective. It would probably take too long time to produce all the artefacts associated with the different tasks. Depending of the project the artefacts to produce must be prioritized and only the most important to the project can be developed.

36 Chapter 3. Software development focusing on Software Architecture and 26 SOA

37 Chapter 4 Internet security focusing on Web services and J2EE This chapter will cover the key concepts in security and the mechanisms behind them. It will also cover the specific security challenges in the J2EE and Web service environments and how they are handled. Doing business in today s world usually requires that a company utilize the Internet for both business-to-customer and business-to-business interactions. Everyone relies on information from a variety of sources and tend to depend on its accuracy and reliability in making their own business decisions. The information is often mission-critical, marketvalued or confidential. Therefore the information must be protected while traveling over the Internet to avoid threats and risks such as service interruptions, unauthorized access, stealing and altering of information, impersonation, the spreading of viruses, and so on [1, 18]. Security is, unfortunately, in most projects considered a post-deployment event at the end of the development phase or an after-the-fact reaction when something goes wrong. Most business and organizations recognize the importance of information security, but very few have implemented strategies and processes to proactively identify and counter the risks they face. Not having good security often results in businesses and organizations suffering huge financial losses and losing customer confidence [18]. 4.1 Basics of security This section will describe the key concepts and goals of information security Security requirements and goals When we speak of security in software, it can refer to many areas of the system; applications, data, networks, communications, users, host systems, and so forth. There are some common security requirements and goals in these areas that involve the protection of data. These concepts will be named and explained in the following sections. 27

38 28 Chapter 4. Internet security focusing on Web services and J2EE Confidentiality Confidentiality is the concept of protecting sensitive data from being viewable by an unauthorized entity. There are many types of information that falls under the category of sensitive data. Some data may be illegal to compromise, such as medical records or a customer s credit card number. Other data may be sensitive in the way that it may uncover too much information about an application. To protect the confidentiality the data must be protected from unauthorized users during transit and in storage. This is often accomplished by using encryption algorithms [18]. Encryption is discussed in more depth in the cryptography section. Integrity Integrity is the concept of ensuring that data has not been altered by an unknown entity during transit or storage. For example, the information in an could be altered during transit, or a program available for download on a web site could be altered to contain malicious code, such as a virus or a Trojan horse. Many communication protocols, including the popular TCP/IP protocol, use checksums or CRC (Cyclic Redundancy Check) algorithms to verify data integrity. These techniques are however easy to overcome. An adversary could insert malicious content and then alter other insignificant parts of the data so that the CRC calculates the same value as before. To counter this threat, strong one-way hash functions have been developed. These functions make it computationally infeasible to create the same hash value from two different inputs [18]. One-way hash functions are discussed in more depth later in the cryptography section. Authentication Authentication is the concept of ensuring that a user s identity is truly what the user claims it to be. This is generally accomplished by having the user present his identity together with a piece of information that could only be produced by that user. The most common piece of information is a password. This ensures that users are who they say they are [9, 18]. There are however several ways a password could be compromised. For example, the confidentiality of the password could be compromised if it is sent over an unsecured line. Passwords are also easily exposed in other ways because people often write passwords down and leave them in places where other people easily can discover them. Another problem with passwords is that the same password is used for many different services. If one service is compromised it opens up multiple targets for potential abuse [18]. Passwords are an example of authentication based on what you know. Other ways of authentication can be based on what you have and what you are. An example of what you have-authentication is the device you use to log on to for example an Internet bank. It presents you with a challenge, the device generates a response from the challenge and you send back the response. The what you are-authentication is usually based on some sort of biometric. It can be for example a fingerprint or voice patterns. Each of these have their own weaknesses, therefore they are often combined to create a stronger authentication. For example, Internet banks often require both the response from the device and a PIN number or password. This way they combine what you have (the device) with what you know (the PIN number) to get a stronger authentication [18].

39 4.1. Basics of security 29 Authorization Authorization is the concept of determining what actions a user is allowed to perform after being allowed access to the system. This is performed in many different ways. One common method is to use access control lists (ACLs), which lists all users and their access privileges. Another technique is to assign each user a role or group identification and the applications then check this to determine what actions the user may perform [18]. Non-repudiation Non-repudiation is the concept that when a user performs an action on data, such as approving a document, that action must be bound with the user in such a way that the user cannot deny performing the action [18] Cryptography The following sections will take a closer look on some of the popular cryptographic algorithms and how their use contributes to achieving security goals. Cryptography has a central role in security. Almost all techniques for securing a service use some sort of cryptography. In the past few years there have been major advances in the cryptography area. For example, the advent of the one-way digitally signed hash algorithm opened up opportunities for verifying data integrity with algorithms such as MD5 and SHA-1 and to a lesser extent protect data through obfuscation. Encryption algorithms such as symmetric ciphers have evolved from the government-endorsed DES (Data Encryption Standard) to the latest algorithms such as RC4, IDEA, Blowfish and the government-endorsed AES (Advanced Encryption Standard). The perhaps most compelling recent achievement in cryptography has been the advent of asymmetric ciphers, which makes the handling of keys easier [18]. A general rule when dealing with cryptography is to use a tried and true published algorithm instead of developing one from scratch. The published algorithms have gone through rigorous testing and any limitations are well known [18]. One-way hash function algorithms One-way hash functions are algorithms that take as input a message and generate as output a fixed-size number. This number is referred to as the hash value. The purpose is to create a short digest that can be used to verify the integrity of a message. As mentioned earlier, in communication protocols the integrity is verified using checksums or CRC. These methods are fine for detecting corruption due to electronic glitches or some other natural phenomena, but if the corruption comes from an intelligent adversary something stronger is needed. A cryptographically strong one-way hash function is designed in such a way that it is computationally infeasible to find two messages that compute the same hash value [18]. Two examples of popular algorithms are MD5 and SHA-1. MD5 was created by Ron Rivest in 1992 and creates a 128-bit hash value. SHA-1 was created by the National Institute of Standards and Technologies in 1995 and produces a 160-bit hash value. SHA-1 is slower to compute than MD5 but is considered stronger because it creates a larger hash value [18].

40 30 Chapter 4. Internet security focusing on Web services and J2EE Symmetric ciphers Symmetric ciphers are mechanisms that transform text in order to conceal its meaning. They provide two functions: message encryption and message decryption. They are called symmetric since they use the same key for both encryption and decryption. The encryption function takes as input a message and a key value. The output is a seemingly random sequence of bytes. The decryption function takes the sequence of bytes and the same key value as the encryption function and generates as output the original message. The purpose of a symmetric cipher is to provide message confidentiality. A real challenge when using symmetric ciphers is the distribution of the key value. If the key value is not kept safe during transport, the encrypted data will no longer be safe [18]. This problem, often referred to as key management, will be discussed more in the key management section. There are plenty of published symmetric ciphers that have held up to a great deal of scrutiny. Some examples are: DES, IDEA, AES, Twofish and RC2 [18]. Symmetric ciphers are available in two types: block ciphers and stream ciphers. Block ciphers encrypt one block of data at a time, typically 8 bytes or 16 bytes in size, whereas the stream ciphers encrypts a stream of data. Stream ciphers are relatively new and are generally faster than block ciphers. However, since block ciphers have been around longer they are more popular and there are many free choices available. A popular stream cipher is Ron Rivest s RC4 which is used with SSL in all Web browsers [18]. Asymmetric ciphers Asymmetric ciphers provide the same two functions as symmetric ciphers: message encryption and message decryption. However, there are two major differences. The first is that the key value used in encryption is different from the one used for decryption. The two keys are usually referred to as the private key and the public key and together they are referred to as a key pair. The public key is often published in a directory. The second difference is that asymmetric ciphers are thousands of times slower than symmetric ciphers [18]. However, asymmetric ciphers offer several other advantages over symmetric ciphers. A key advantage is that it reduces the trouble of key management. When using a symmetric cipher you have to use a separate secure channel to distribute the key value and you cannot be sure how long the key will remain a secret. With an asymmetric cipher you can send your public key over an unsecured line. This is because you can only decrypt messages with the public key that has been encrypted with the associated private key. For example, if Anders want to send a secure message to Klas, he first asks Klas for his public key. Klas then sends his public key to Anders. Anders uses Klas public key to encrypt the message and then send the encrypted message to Klas. Klas then uses his private key to decrypt the message. Because only Klas private key can decrypt the message the information will be kept a secret [18]. Since asymmetric ciphers are really slow compared to symmetric ciphers you can use the asymmetric cipher to exchange a symmetric key. This way you can reduce both the trouble of key management and the overhead of the asymmetric encryption/decryption. The exchange of the symmetric key value could be done like this: Anders generates the symmetric key value and encrypts it with Klas public key. The only one who can decrypt the key value is Klas and therefore the key value is kept a shared secret between Anders and Klas [18].

41 4.1. Basics of security 31 The most popular asymmetric cipher is RSA. RSA keys can be authenticated, which prevents man-in-the-middle attacks. Examples of other asymmetric ciphers are Elgamal and ECC [18]. Digital signature Digital signatures are used to guarantee the integrity of the message sent to a recipient by being a representation of the identity of the message sender. The digital signature consists of a hash value calculated on the message, which then has been encrypted using the private key of an asymmetric cipher [18]. For example, if Klas wants to send a message to Anders but Anders wants to be really sure that Klas is the sender of the message and that the content of the message has not been changed during transport. Klas first calculates a hash value of the message and then encrypts that value with his private key and includes the digital signature in the message. Then the message is sent to Anders, who uses Klas public key to decrypt the signature. Anders calculates a hash value of the message and compares the decrypted hash value with the one he calculated. If they match Anders can be sure that Klas is the sender of the message and that the message has not been changed during transport. The reason why a hash value is calculated and then encrypted instead of encrypting the whole message is performance related. As mentioned in a previous section asymmetric ciphers are quite slow. Since only Klas private key could have generated the digital signature Klas cannot deny that he was the one who created the message. This means that digital signatures ensure non-repudiation [18]. Digital certificates A digital certificate is a document that uniquely identifies information about a party. It contains a party s public key plus other identification information that is digitally signed and issued by a trusted third party. The third party is also referred to as a certificate authority (CA). A digital certificate is often called a X.509 certificate and is commonly used to solve problems associated with key management [18]. In a trusted communication using digital certificates, a CA plays the role of the entity that issues a public key certificate. In order to trust a certificate, the relying party has to trust the root certificate. The root certificate is a certificate that is self signed, which means that the certificate contains the CA s public key and is signed with the CA s private key. All certificates issued by the CA contain the public key of the entity and is signed by the CA s private key. One of the most popular CAs is the company VeriSign. Most of the secure Web sites on the Internet have their certificates verified and signed by VeriSign [18]. Secure socket layer (SSL) and Transport layer security (TLS) Netscape released SSL 3.0 in 1996 for the purpose of securing data transfered over HTTP between the Web server and the Web client. The design of SSL allows it to also secure any data that is communicated over a connection-orientated, end-to-end reliable protocol, such as TCP/IP. The SSL protocol combine public-key and symmetric-key algorithms to authenticate the server side, optionally authenticate the client side, and secure all communications using encryption between the two sides [18].

42 32 Chapter 4. Internet security focusing on Web services and J2EE The company Certicom, mostly as an attempt to create and official IETF standard protocol out of SSL 3.0, wrote the TLS specification in There are some differences between TLS and SSL and this means that the two protocols do not interoperate. However, TLS 1.0 incorporates a mechanism by which a TLS implementation can back down to SSL 3.0 [18]. Common challenges in cryptography The implementer of a cryptographic algorithm must overcome the challenges involved with cryptography. Some of the most common challenges are described in the following paragraphs. Random number generation Bad random numbers is fatal for security. For example, in 1995 a paper written by Ian Goldberg and David Wagner described how one would go about to eavesdrop on a secured SSL session with Netscape 1.2. The implementation of SSL and associated cryptographic tools in Netscape were correct except for one thing; the key values were easily detected because the random number generation was predictable. Netscape fixed the problem by adding more sources of entropy. The first unsecured implementation used only the current daytime clock value, the process id and the parent process id, which made it possible to calculate the key within a few minutes [18]. Many modern operating systems support cryptographically strong pseudorandom number generators. One example is Bruce Schneier s Yarrow, which offers a platformindependent method of producing strong pseudo-random numbers. Many UNIX-style system use Yarrow to support the device /dev/random [18]. Key management As mentioned in an earlier section, key management is a real challenge within cryptography. One could say that it is the single most debated problem in cryptography. To secure data via encryption, one must exchange a key value to be used in the encryption process. If the communication parties only have an unsecured publicly accessible communication link, a secure exchange of the key value is impossible. However, asymmetric ciphers resolve this issue by providing a mechanism for exchanging the key values used in a symmetric cipher. With asymmetric ciphers a new problem arises and that is how to verify the identities of the communicating parties. This is resolved through the use of digital certificates, which is a sort of trust model. Trust models will be covered in the next section. The most popular solution is X.509 certificates since they are used to secure Web transactions with SSL [18]. Trust models A trust model is the mechanism used by a security architecture to verify the identity of an entity and its associated data, such as name, public key, and so on. The X.509 certificate is an example of a trust model. Identities are vouched for through a hierarchical structure that culminates at the root certificate, which is self-signed by a well-known certificate authority [18]. An other example of a thrust model is the model used by PGP (Pretty Good Privacy), which uses a web of trust instead of a hierarchical trust model. PGP, developed by Phil Zimmerman in 1991, is a program that uses a combination of RSA asymmetric cipher and the IDEA symmetric cipher to secure . A PGP certificate may contain many signatures, unlike the X.509 certificate. This means that the PGP certificate can be verified using any one of the signatures and the verifier can choose which signature it

43 4.1. Basics of security 33 trusts the most. Newer versions of PGP support use of X.509 certificates and this allows better interoperability for security providers [18] Critical application security flaws and exploits In this section the most common application flaws that are critical to security will be listed. It is important to have knowledge about common flaws and exploits so that during design and implementation the developer can mitigate the risks of these problems. Input validation failures Validating the input parameters before accepting a request is critical to application security. It is a good practice to validate all input, even from a trusted resource. Validating input will help in avoiding application-level failures and attacks from both intentional hackers and unintentional abusers. Input validation is a mechanism for validating data such as data types, format, length, range, null-value handling, verifying for characterset, locale, patterns, context, legal values and validity, and so on. Not validating input can cause a malicious code injection attack. If an application relies on client-side data validation, a hacker may exploit any flaw in the server. It is good practice to re-verify and validate input even after client-side validation [18]. Output sanitation Re-displaying or echoing data values entered by users is a potential security threat because it provides a hacker with a means to match the given input with its output. For example, if a Web page generated by a user s request is not properly sanitized before it is displayed, a hacker may be able to identify a weakness in the generated output. This weakness could be exploited to display pop-up banners or worse, change the content originally displayed by the site. To prevent these issues, the generated output must be verified for all known values. Any unknown values not intended for display must be eliminated. All comments and identifiers must be removed from the output as well [18]. Buffer overflow Buffer overflow occurs when an application tries to store more data in a data storage or memory buffer than its fixed length or its capacity can handle. The extra information will most likely end up in adjacent buffers. This event is likely to cause corruption, causing the application to crash. To perform this kind of attack, the hacker passes malicious input by tampering or manipulating the input parameters to force an application buffer overflow. These attacks are typically carried out using application weaknesses related to input validation, output sanitization, and data injection flaws [18]. Data injection flaw Security intruders can piggyback user data or inject malicious code together with user data while exploiting a weakness in the user data input environment. Data injection flaws are often found in browsers with pop-up windows (window injection vulnerability) or in SQL statements when external input is transmitted directly into SQL (SQL injection vulnerability). To avoid data injection flaws, it is important to enforce thorough input validation. All input values must be validated for known values only. The rest of them must be rejected [18].

44 34 Chapter 4. Internet security focusing on Web services and J2EE Cross-site scripting (XSS) With XSS, a Web application can gather information by using a hyperlink or script that contains malicious content. The attackers frequently use JavaScript, VBScript, ActiveX, HTML or Flash in a vulnerable Web application to gather data from the current user. The script may hijack the user s account information, change user privileges, steal cookie or session information, and so on. It is important to diagnose and test the application for XSS risks and vulnerabilities [18]. Improper Error Handling Most applications are likely to be affected by security issues related to error handling when they display detailed internal error messages about application conditions such as out of memory, null pointer exceptions, system call failure, database access failure, network timeout, and so on. This information usually reveals internal details that a hacker can use to crash the application. Adopting proper error handling mechanisms will display error messages as user-specific messages based on user input; no internal details related to the application environment or its components will be revealed. All userspecific error messages are stored in log files for auditing. In the event of an attack, the log files provide diagnostic information for verifying the errors and for further auditing [18]. Insecure data transit or storage Confidentiality of data in transit or storage is very important, because most security is compromised when data is represented in plain text. Using cryptographic mechanisms and data encryption helps ensure the integrity and confidentiality of data in transit or storage [18]. Weak session identifiers Giving out or using session identifiers before authentication or over not encrypted communication channels allow hackers to steal session information and then hijack the associated user sessions for unauthorized business transactions. The weakness of representing the session identifiers as clear text helps the hacker to spoof the user identity information. The weakness is intensified if the identity information is not validated by the service provider or has not got an expiry time. To prevent these issues, the application should issue encrypted session identifiers after initiating a secure communication channel using SSL because SSL ensures confidentiality and integrity of the session information [18]. Weak security tokens Weak security tokens refer to the use of password security tokens that allow hackers to guess passwords by using a dictionary or token decrypting tools to impersonate the user. Some Web applications may also echo back their passwords as Base64 values that are susceptible to an attack. If a Web application or HTML script echo the password or token, hackers may intercept them and then impersonate the user for unauthorized access. This is a common security problem in authentication and application session management. To address these issues one should adopt strong authentication, using for example digital certificates, biometrics, or smart cards. It is very important to protect

45 4.1. Basics of security 35 the password files and also to ensure that the passwords are strong enough so that they can not be easily guessed or cracked by hackers [18]. Weak encryption Using computers with lots of processing power can compromise a weak encryption. Algorithm key-lengths longer then 56 bits are considered strong encryption, but in most cases 128-bit key-length and above are recommended [18]. Session theft Session theft is also referred to as session hijacking and occurs when attackers create a new session or reuse an existing session. Session theft is performed by hijacking a clientto-server or server-to-server session. This bypasses the authentication. The attack can be done at several different levels: Web application session level, host session level, or in the TCP connection. In a TCP communication, session hijacking is done via IP spoofing techniques. An attacker uses source-routed IP packets to insert commands into an active TCP communication between the two communicating systems and disguises himself as one of the authenticated users. In Web applications the session hijacking is done via forging or guessing Session IDs or stealing Session ID cookies. To prevent session theft, one should consider the following best practices; always invalidate a session after logout, adopt PKI solutions for encrypting session information, and adopt a secure communication channel such as SSL/ TLS. This is important since session information usually contains sensitive information, such as passwords, credit card numbers, and so on [18]. Insecure configuration data The most common examples of insecure configuration data are; misconfigured SSL certificates and encryption settings, use of default certificates, default accounts with default passwords, and misconfigured Web server plug-ins. This particularly impacts the security in the Web and business tier. To prevent issues, it is important to test and verify the environment for configuration-related weaknesses [18]. Broken access control Access control determines an authenticated user s rights and privileges for access to an application or data. Any access control failure leads to loss of confidential information and unauthorized disclosure of protected resources such as application data, functions, files, folders, databases, and so on. Failure to enforce application-specific security policies and the lack of policy enforcement in application design are directly related to access control problems. To avoid problems with access control it is important to verify the application-specific access control lists for all known risks and to run penetration tests to identify potential failures [18]. Policy failures Security policies are used to provide rules and conditions that determine what actions should be taken in response to defined events. If the rules are missing, conflicting or insufficient, or there are invalid conditions or prerequisites, the security processing will not be able to enforce the defined security rules. This can make hackers discover and

46 36 Chapter 4. Internet security focusing on Web services and J2EE exploit any resource loophole. Policy failure is a security issue for application design and policy management [18]. Audit and logging failures Auditing and logging provides non-repudiation by providing irrefutable evidence about all application events. They record all key application events and any audit or logging failure can cripple the ability to diagnose suspicious activity and foil malicious attacks. The tracing of exceptions and specific bugs is made impossible if there are logging and audit failures present. The log files must be stored with restricted access [18]. Denial of service (DOS) and Distributed DOS (DDOS) The worst forms of network-level attacks are DOS and DDOS. These attacks consume excessive amounts of nonrenewable resources in the form of network bandwidth and CPU utilization. They can also cause destruction of host configuration information, resulting in application failures and operating system crashes. DOS attacks are performed by a single machine attacking an other machine, while DDOS attacks are performed by coordinating several machines to attack a single machine. DOS or DDOS attacks are initiated by exploiting application weaknesses and flaws related to resource management, authentication, error handling, and application configuration. Web-based applications are highly susceptible to these kinds of attacks and sometime it is impossible to determine whether the incoming service requests are part of an attack or ordinary traffic. Some approaches to mitigate the threat include host name verification and implementation of router filtering to drop connections from attacks initiated from un-trusted hosts and networks [18]. Man-in-the-middle (MITM) A MITM attack is a security attack in which a hacker is able to read or modify business transactions or messages between two parties without either party knowing about it. A MITM attack can be executed by spoofing the business transactions, stealing user credentials, or exploiting a flaw in the underlying public key infrastructure or Web browser. MITM is a security issue in application design and application infrastructure [18]. Multiple sign-on issues This is a common issue in enterprise application integration environments. It requires the user to log on multiple times because there is no common sign-on mechanism within the environment. When a user switches applications within a server, hackers can compromise security by using credentials from previous sign-on sessions. Since users are required to sign off explicitly from every application, there is an increased risk for human errors, loss of productivity, and failure to restrict the access to the applications which the user have access to [18]. Implementing single sign-on (SSO) mechanisms, where the user only have to signon once solves these problems by eliminating the need for users to remember several different usernames and passwords. SSO also gives an increase in productivity because users no longer need to physically enter repetitive usernames and passwords [18].

47 4.1. Basics of security 37 Deployment problems Many security exposure issues and vulnerabilities occur by chance because of application deployment problems. Conflicts and inconsistencies within application configuration data and the deployment infrastructure (hosts, network environment, etc) are included in these problems. The factor of human error in policy implementation also contributes and in some cases deployment problems are related to design flaws. Therefore it is important to review and test all infrastructure security policies and to make sure application-level security policies reflect the infrastructure security policies, and vice versa [18]. Coding problems Coding practices greatly influence application security. Issues related to coding can cause flaws and erroneous conditions in programming and application flow. To avoid issues with for example, input validation, race conditions, exceptions, and application failure it is recommended to adopt a coding review methodology followed by source code scanning for common mistakes. This is to identify all potential risks and vulnerabilities so that they can be corrected [18] Threat modeling Threat modeling help determine who is most likely to attack a system and what possible ways an attacker could compromise the system. The result of the threat modeling exercise clarifies what security precautions should be taken to protect the system [18]. Web applications and most computing systems use security procedures and tools to provide access for legitimate users and to prevent unauthorized users from accessing the system. Different users are often given different types of access. For example, a Web application gives read-only access to the public and only allows authorized users to update or insert new data. A potential hacker must look for what means of access are available for accessing the system and how to exploit any vulnerabilities. The hacker could for instance try to use malformed URLs, various FORM attacks, and so on to abuse input validation related failures. But if the hacker discovers a legitimate logon account, further possibilities for attacks opens up. Perhaps the hacker finds a way to alter data in a database. A threat model allows an assessment of what damage can be inflicted by an attacker who has specific types of access [18]. Attack trees can assist in modeling what threats there are to a system. The root node of an attack tree represents the goal of the attack. Child nodes represent direct actions that can attain the attack s goal. The action may or may not be directly achievable. If the action is directly achievable the child node is a leaf and if the action is not directly achievable the necessary actions are listed as child nodes under the node [18]. Figure 4.1 on page 38 shows a simple example of an attack tree for logging in to a LISA account. As you can see, the root node represents the goal of the attack, which is to log in to someone s LISA account. The nodes directly under the root node describe direct actions that can accomplish this. For example, the Learn password-node under the root node indicates that if one could learn the password you would be able to log in. The nodes directly under that node describe possible methods to learn the password. The process continues until a leaf node is reached. Ideally, the attack tree illustrates the possible avenues an attacker can follow, starting from any one of the leaf nodes and moving up until the goal of the attack at the root node is accomplished [18].

48 38 Chapter 4. Internet security focusing on Web services and J2EE Figure 4.1: Example of an attack tree. When the nodes of the attack tree have been identified, each node can be assigned a cost. For example, finding the written password is cheaper then bribing the target. However, the cost might not be related to money, perhaps the risk of sneaking around looking for the written password carries too much risk for getting caught for the attacker that it would be worth the price to bribe the target. Various costs or weightings can be applied to each node. These include ease of execution, legality, intrusiveness, probability of success, and so forth. As one applies costs to each of the nodes in the attack tree, one can start to see the path that has the least cost and is therefore more likely to be used by an attacker. The probable or likely paths and the risk value associated with the goal of the attack determine how much effort needs to be directed at securing those paths [18]. 4.2 Strategies for building robust security This chapter takes a look at some of the concepts and strategies that contributes to the development of robust security and design. End-to-end security requires a proactive approach; the essential security strategies and decisions for the application must be made and adopted during the design phase, not at the time of deployment. Security mechanisms must be implemented using a structured methodology including; patterndriven design, adoption of best practices, risk verification through reality checks, and proactive assessment of the deployment architecture. The robustness of security also needs to be enhanced and it can be done by using defensive strategies, security profiling, and security recovery and continuity strategies [18].

49 4.2. Strategies for building robust security The four W s Critical security flaws and exploits can exist across multiple server or application components. This fact reinforces the critical importance of end-to-end security, not just security for a server or a specific application component. To start establishing end-toend security, security architects and developers can start from the perspective of the four W s [18]: 1. Which applications are we protecting? Business applications and mission-critical services require protection from unauthorized access. To determine and identify which application resources need to have access control and security is important. 2. Who are we protecting the application from? Sensitive personal data or sensitive business transactions stored in applications and resources require protection from users other than the owners. It is important to protect these applications and resources from the public Internet and unauthorized users. Security architects and developers should consider the possibility of protecting them by categorizing users in their organization by rights and privileges granted. Users can then be grouped based on their access rights. Security architects and developers should also consider giving access to highly confidential material to only a few trusted administrators. It may be prudent not to allow administrators to access data or resources unless they have an active user account defined to carry out only selected operations. Monitoring, logging, and auditing user access is necessary throughout the application life cycle. 3. Where should we protect them? To have understanding about which applications need protection and from whom is not sufficient for end-to-end security. The next important consideration is where we should protect them. It is important to address all aspects of protecting an application and associated resources, including its different tiers, components, users, hosts, and network infrastructure. The enforced protection can be based on architecturally significant security criterias such as the specific location (single or multiple server machines, intranet or Internet), type of connection (TCP/IP or SOAP), nature of the objects or resource (database objects), communication (SSL/TLS or IPSec), and so on. 4. Why are we protecting them? A fault in the security system of business applications may cause great damage to an organization or to individual clients. It is important for security architects and developers to understand the potential for damages from security breaches. This will help them to properly protect business applications and resources. It is also important to understand the threat levels and vulnerabilities and then plan and establish a service recovery and continuity program for all potential failures Unified Process for security design The Unified Process (UP) is an industry standard process with a proven track record. UP defines the development disciplines, along with an iterative approach, for gathering, analyzing, implementing, and testing functional business requirements. However, it

50 40 Chapter 4. Internet security focusing on Web services and J2EE Figure 4.2: Secure UP: Security disciplines, taken from [18] does not have specific guidelines for security. This is because security is a non-functional requirement and UP fails to address how to incorporate the non-functional requirements of the system. Too often, security is retrofitted into the application at the end of the construction phase, leading to vulnerabilities and performance and/or usability impacts. To avoid this situation, UP can be extended with a security discipline that ensures that all of the security requirements of the application are defined, designed appropriately, implemented, and thoroughly tested. The incorporation of these security disciplines into UP is referred to as Secure UP [18]. Secure UP establishes the prerequisites for incorporating the fundamental security principles. It also defines a streamlined security design process within a software development life cycle. Secure UP introduces a security discipline with a set of new security activities. These activities are displayed in Figure 4.2 on page 40. One might wonder why there is need to split hairs over the difference between business and security requirements. The reason for that is because there is a wide gap between the people who know and understand the business needs of the application and those who know and understand the security needs [18]. The Secure UP-security discipline activities coalesce to form the basis of a robust security infrastructure and deliver an end-to-end security solution for an application or service. Below is an overview of the activities in the security disciplines [18]: Security Requirements

51 4.2. Strategies for building robust security 41 In this activity, one or more analysts will define the business-mandated security requirements of the system. This includes requirements based on industry regulations, corporate policies, and other business-specific needs. The analysts will be well-versed in regulatory compliance as well as corporate security policies. Security Architecture This activity focuses on the creation of an overall security architecture. Architects will use the security requirements specified by the analysts and create a draft of the candidate security architecture. The architectural decisions are qualified through a well-defined risk analysis and trade-off analysis process in order to identify the risks and trade-offs and how to mitigate them. The candidate architecture will also identify a set of security patterns that covers all of the security requirements within the component architecture and will detail them in a high-level way, addressing the known risks, exposures, and vulnerabilities. Before the final security design activity can begin the candidate architecture is prototyped and refined. The combination of security design with the other non-functional requirements will also be addressed to ensure that the security implementation does not compromise other functional or quality-of-service requirements. Security Design The security design activity takes the security architecture and refines it using approaches such as factor analysis, tier analysis, security policy design, threat profiling, trust modeling, information classification, and labeling. The design will be created and documented by a senior security developer and it will be based on the candidate security architecture, analysis results, and also taking into account the best practices and pitfalls regarding the strategies of each of the security patterns. Security Implementation Security aware developers will implement the security design. A good security design will decouple security components from the business components and therefore not require the security developers to have strong interaction or integration with business developers. The security patterns will be implemented using the strategies defined in the security design and incorporate best practices for securing the code. White Box Testing The white box testing activity is full knowledge security testing of the code. The security testers will review the source code looking for security holes or flaws that can be exploited. White box testing will be covered more deeply in the Security testing section. Black Box Testing The black box testing activity is zero knowledge security testing of the system. The security testers will attempt to break into the system without any knowledge of the code or its potential weaknesses. Black box testing will be covered more deeply in the Security testing section. Monitoring This activity is an ongoing activity for the system while it is in deployment. Operations personnel will monitor the application and all security facets of it. This

52 42 Chapter 4. Internet security focusing on Web services and J2EE consists of a broad range of areas, starting at the perimeter with the routers and firewalls and extending all the way back to the application it self. Monitoring is an integral part of security and an ongoing activity. Security Auditing In this activity security auditors will come in and audit the system from a security perspective. Their job is to assure that the systems are in compliance with all industry, corporate, and business regulations and that proper audit trails are being maintained and archived properly. These audit trails may also be reviewed for suspicious activity that may indicate a possible security breach Risk analysis Risk analysis is the process of describing threats. The description includes impacts, possible consequences, and their probability and frequency of occurrence. Risk analysis influences the security design process by helping the decision making process related to choosing applicable tools and mechanisms. This help determine how to mitigate the identified risks by establishing the selection criteria for safe-guards and countermeasures meant for preventing or reducing the risks to an acceptable level [18]. The risk analysis process may include a range of activities such as risk identification, risk assessment, risk characterization, risk communication, and risk-specific policy definition. These activities are depending upon the security requirements. A typical risk analysis artifact will gather information based on the following techniques [18]: Asset Valuation This technique is the fundamental process of determining the value of an asset. Asset valuation helps to justify the cost benefits in preventing or reducing the known risk. It also helps to satisfy the stakeholders, legal, and other regulatory requirements. Factors included in the assessment of the overall business value of the application or service are: initial and ongoing costs, insurance value and total estimated value, including infrastructure and other intellectual properties. Quantitative Risk Analysis This technique identifies all key risk elements and estimates the value associated with each risk. These elements are for example infrastructure cost, potential threat, frequency, business impact, potential loss value, safeguard effectiveness, and safeguard value. Based on this information it is possible to estimate the potential losses, analyze the potential threats, compute the Annual Loss Expectancy (ALE), and then identify countermeasures and safeguards. Qualitative Risk Analysis This technique identifies the threats and vulnerabilities specific to applicable scenarios identified through security reality checks. This helps, based on the findings, to mitigate the risks by identifying the appropriate safe guards and countermeasures to prevent them or to reduce the likelihood and effect of occurrence Trade-off analysis The purpose of trade-off analysis is to improve the quality of security architecture with explicit, efficient, and rational decisions. It helps weigh choices of security features

53 4.2. Strategies for building robust security 43 against potential threats or vulnerabilities. This assists in justifying a financial case or identifying alternative options [18]. A typical trade-off analysis artifact contains all of the security architecture and safeguard options and alternatives. It can also include an Effect Matrix, where the security options are represented in columns and security criteria are represented in rows. Each cell have two values, the top value indicates the impact on a scale from -10 to 10 and the bottom value indicates the relative importance of that security criterion on a scale from 1 to 10 [18]. Trade-off analysis is a ranking index for making architectural security decisions with clear assumptions and for addressing associated uncertainties [18] Security patterns Security patterns are an abstraction of business problems that address a variety of security requirements and provide a solution to the problem. The security patterns can be architectural patterns that depict how a security problem can be resolved architecturally (or conceptually), or they can be defensive design strategies upon which quality security protection code can be built. Patterns help architects and developers to communicate security knowledge, to define a new design paradigm or architectural style, and to identify risks that have traditionally been identified only by prototyping or experience [18] Best practices Best practices are selected principles and guidelines derived from real-world experience that have been identified by industry experts as applicable practices. They are considered exceptionally well suited to contributing to the improvement of design and implementation techniques. They are usually represented as do:s and don t:s [18] Reality checks Reality checks are a collection of review items used to identify a specific application behavior. They assist in the analysis of whether the applied design principles are practicable, feasible, and effective under all required circumstances. Within the security application area there are many grand design principles and theories. Some of them may not be practical, therefore can reality checks help to identify alternatives that have fewer penalties but achieve the same goal [18] Security testing Security testing is one of the most overlooked areas of application development at the same time as it is one of the most important. There are many factors to why security testing is overlooked, for example lack of time, tools, knowledge and understanding how important it is. The lack of security testing creates a serious security risk to the application [18]. Security testing is a time-consuming and tedious process, often even more so than functional testing. The security testing can be broken down into two categories, black box testing and white box testing [18].

54 44 Chapter 4. Internet security focusing on Web services and J2EE Black box testing Black box testing is also known as zero knowledge testing. This type of test makes no assumptions about the application. Black box testers approach the application as an attacker would, searching for information about the internal structure of the application and then try various exploits based on that information. For example, if a URL of the application ends with.asp, this might imply that the application is developed in ASP and therefore may be vulnerable to many well-known attacks [18]. Black box testers will employ a variety of tools for scanning and probing the application. On the Internet there are hundreds of different tools for hacking into Web applications. Many of the tools are highly sophisticated and provide comprehensive vulnerability scanning of any type of Web application. It is not uncommon for operational groups to run such scans periodically to ensure that their system is not vulnerable to the latest automated attacks [18]. In the general case black box testing will not uncover code-specific vulnerabilities. It will more likely discover unanticipated vulnerabilities arising from the infrastructure the application was built on. These vulnerabilities could come from network misconfiguration (routers, services, OS patches) or problems with the implementation language, etc. Developers or business owners cannot easily foresee these problems and they are usually only discovered during black box testing [18]. White box testing White box testing is the complete opposite of black box testing. Now the testers have full knowledge about the application. This means that the testers have access to the source code and all information about how the environment is configured. The testers will perform code reviews where they will be looking for possible weaknesses and write test harnesses to try to take advantage of those weaknesses. White box testers are usually ex-developers or testers that have enough development background to understand the application s programming language and know the nuances of it [18]. The white box tester s toolbox is a bit different from the black box testers. Their toolkit will contain tools that scan the code and probe it internally, where debuggers and source code scanners are the most common ones. The tools allow the white box testers to find application-specific bugs and vulnerabilities. For example, race conditions and input parameter checking is application specific and will probably not be discovered through black box testing. The white box testing tools will often find other problems such as memory leaks or performance issues. These problems are not directly related to security vulnerabilities, but they contribute to the reliability and availability of the system and those two are main concerns in application security [18]. 4.3 J2EE security architecture The J2EE (Java 2 Enterprise Edition) platform provides a platform for implementing services as multi-tier applications that deliver scalability, accessibility, portability, and manageability. These properties make the J2EE platform suited for enterprise-level applications. The platform is also designed to provide a security model that covers the core security requirements of a multi-tier application infrastructure [9, 18].

55 4.3. J2EE security architecture J2EE architecture and its logical tiers In the J2EE platform application, logic is divided into components according to function. The various application components are installed on different machines depending upon which tier the application component belongs to [9]. The J2EE platform is generally represented with the following logical tiers [18]: Client tier The client tier represents the J2EE platform s user interface or its application client that interact with the J2EE platform-based application or system. A client is typically a Java application, Java applet, Web browser, Web service, Java enabled device, or Java-based network application. Web or presentation tier The presentation tier represents the presentation logic for accessing the J2EE application and its business services, for example requests, responses, session management, and so on. From a security standpoint it delivers client login sessions, and establishes single sign-on access control to underlying application components. Components such as JSPs, servlets, and Java Server Faces (JSF) reside in the Web container. Business or application tier The business tier represents the core business logic. EJB components such as Session Beans, Entity Beans, and Message-driven Beans reside in this tier. This tier typically deals with business functions and transactions with back-end resources. Integration or EIS tier The integration tier represents the connection and communication with back-end resources such as Enterprise-information systems (EIS), database applications, and legacy or mainframe applications. J2EE components such as JMS (Java Message Service), J2EE connectors, and JDBC reside in this tier. Resources tier The resources tier represents the back-end application resources that contain data and services. These resources can be database applications, EIS systems, mainframe applications, and other network-based services. The components in the tiers execute inside of component-specific containers such as a Web container or an EJB container. Containers are the interface between a component and the low-level platform-specific functionality that supports the component. A container also provides the environment in which the components can be executed in a controlled and managed way and an abstraction layer through which the components can see the underlying services and architecture [9, 18] J2EE security architecture and mechanisms The J2EE platform provides a full-fledged security infrastructure and container-based security services that address the end-to-end security requirements of the different application tiers and their resources [18]. When describing the specific security requirements for the J2EE platform a set of standard terms and definitions are used. They are described below [18]:

56 46 Chapter 4. Internet security focusing on Web services and J2EE Principal An entity (a person or an application client) that can be authenticated by an authentication service or a security realm. Security realm or policy domain Provides common security policies and mechanisms that can be enforced by a security service for protecting J2EE platform-managed resources. Security provider Provides security technologies and associated services to enforce a security policy that protects applications and resources. J2EE vendors usually provide support for pluggable third party or standards-based security providers. Security attributes The security attributes are data-specific to a principal that allows or denies access to resources and to auditing of the principal. Security credential Contains information related to the authentication of a principal. The contents and format of a security credential vary depending on the authentication mechanisms in use. A J2EE application server provides, in general, the following security services [18]: Security realms for protecting server resources representing a logical group of users, groups, and access control lists (ACL). Authentication mechanism for identifying the user requesting access to J2EE server-managed resources. This can be accomplished using a combination of username and password or using digital certificates. With digital certificates the authentication is done using the identity of the X.509 certificate provided to the server as a part of an SSL authentication. Authorization of users and groups through ACLs, which allows policy enforcement and access restriction to specific users and resources. Data integrity and confidentiality by securing communication using SSL/TLS protocols. Secure client communication is done via SSL sessions using HTTP or RMI 1 /IIOP 2 over SSL. Auditing and logging of events for identification of failed login attempts, authentication requests, rejected digital certificates, and invalid ACLs. Filtering of client connections for the purpose of accepting or rejecting connections based on the origin via host name or network address or protocol. Support for pluggable JAAS (Java Authentication and Authorization Service)- based authentication and authorization services. Support for pluggable authorization using JACC (Java Authorization Contract for Containers). 1 Remote Method Invocation, see remote method invocation 2 Internet Inter-Orb Protocol, see

57 4.3. J2EE security architecture 47 Support for third-party security services via pluggable security provider agents to provide support for Web servers, portals, and other business applications. Implementation of Java-extensible security architecture and APIs such as JSSE (Java Secure Socket Extension), JCE (Java Cryptographic Extension), and so forth. Realm and user directory support using LDAP (Lightweight Directory Access Protocol) and relational databases. Support for single sign-on across all J2EE applications within a single security domain. Some of these security services are mandated by the J2EE specification and the application server vendor is responsible to ensure that these technologies are integrated into the server environment [18]. J2EE container based security The J2EE container-based security services primarily address the security requirements of the application tiers and components. The security mechanisms provided by the services are authentication and authorization to prove the identity of callers and service providers. They also provide control over the resources to which an identified user or system has access to [18]. A container provides two kinds of security: declarative and programmatic. The two following paragraphs will explain them in more detail. Declarative security Declarative security expresses an application component s security requirements in a deployment descriptor. The rules and permissions are described in a declarative syntax specific to the J2EE application environment. A deployment descriptor is an XML file that describes the deployment settings of an application, a module or a component. Because the deployment descriptor is declarative it can be changed without the need to modify and recompile the application. The Java EE server reads the deployment descriptor at runtime and acts upon the application, module, or component accordingly [9, 18]. Different types of components use different schemas for their deployment descriptors. For example, an enterprise JavaBean component use an EJB deployment descriptor (defined in the EJB 3.0 specification) called ejb-jar.xml and a Web component use a web application deployment descriptor called web.xml [9]. Programmatic security In a programmatic security model the security is embedded in an application. The J2EE container makes security decisions based on the invoked business methods to determine whether the caller has been granted access or not to a resource. Programmatic security is useful when declarative security alone is not sufficient to express the security model of an application. For example, an application component can perform fine-grained access control using two methods of the EJBContext interface (getcallerprincipal and iscallerinrole) or the servlet HttpServletRequest interface (getuserprincipal and isuserinrole). These methods allow components to make business logic decisions based on the security role of the caller or remote user [9, 18].

58 48 Chapter 4. Internet security focusing on Web services and J2EE Annotations Annotations, also called metadata, are used to specify information about security within a class file. This enables a declarative style of programming that includes both declarative and programmatic security concepts. The application server uses the information in the annotations when the application is deployed. However, not all security information can be specified using annotations, some information must be specified in the application deployment descriptors [9]. Annotations let you avoid writing boilerplate code under many circumstances enabling tools to generate it from annotations in the source code. It therefore eliminates the need for maintaining additional files that must be kept up to date with changes in the source files [18]. J2EE Authentication When a client interacts with a J2EE application it accesses underlying components and resources such as JSPs, servlets, EJBs, Web services, and other back-end applications. The first invocation starts a chain of invocations on subsequent components and resources. The J2EE platform therefore allows a client authentication at the initial call request. The client identity and its credentials can then be propagated to the subsequent chain of calls [18]. The J2EE environment provides for the following types of authentication [18]: Container-based authentication This is the standard authentication service provided by the J2EE server infrastructure. It allows authenticated users to access its deployed applications. There are four types of authentication types: 1. HTTP basic authentication, a username/password-dialog is used to authenticate a principal. 2. Form-based authentication. Similar to HTTP basic authentication but uses a form to pass the username and password to the Web container. 3. Client/Server mutual authentication. X.509 certificates are used over a secure communications channel (SSL/TLS protocol) to establish the client and server identities. 4. HTTP digest authentication. The client authenticates using a message digest containing the client password and sends it with the HTTP request message. These authentication types can also be performed in the EJB business tier. The application uses a Web component in front of the EJB component to provide authentication. Application-based authentication The application uses a programmatic security approach to collect the user credentials and verify the identity against the security realm. In a Web component-based application, the servlet adopts the authentication mechanism from the J2EE container services. A declarative security mechanism is then used to map the user principal to a security role defined in the deployment descriptor. Agent-based authentication This allows J2EE applications to use third-party security providers for authentication. Typically it is used to provide a single sign-on solution to portals, J2EEmanaged business applications and so forth. The agent usually resides as a proxy that intercepts the users request to the J2EE server. The J2EE server typically

59 4.3. J2EE security architecture 49 Figure 4.3: Protection domains uses JAAS-based authentication methods to integrate custom authentication technologies. Protection domains The container provides an authentication boundary between the external callers and the deployed components. It is the container s responsibility to enforce the security within its boundary. Interaction within the container-managed boundary is managed as protection domains, which maintain the identity proof for the interacting components to trust each other [18]. Figure 4.3 on page 49 illustrates the notion of protection domains. For example, when a user make an inbound request to the container to invoke a component, it is the container s responsibility to ensure that the authentication information is available to the component as a credential. Similarly, in the case of outbound calls, it is the container s responsibility to maintain the caller s identity to enforce the protection domain to the called components. In J2EE this is done by declaring the resource references in the deployment descriptor of the J2EE component that interacts with other components and external resources managed by the container [18]. J2EE Authorization A role-based authorization model is used in J2EE to restrict access to components and resources. The role represents security permissions or privileges granted to users or groups to access or restrict a particular set of resources or operations. The application deployer maps the users to roles in the target environment. When a client initiates a request with a successful authentication, the container verifies the security attributes from the client s credentials and identifies the access control rules for the target resource. The container allows access only if the rules are satisfied, otherwise the request is denied. There are two types of authorization mechanism in the J2EE platform, declarative and programmatic [18]: Declarative authorization This is done by listing the rules and resources in the application deployment descriptor together with a list of roles that are able to access the resource. In Web components such as JSPs and servlets, the access can be specified at the URL level and further down to GET or POST methods. In EJB components it can be specified down to specific class methods. Declarative is preferred and considered easy to deploy, but it has limitations when it comes to dynamic access rules, multi-role access and content level authorization. Programmatic authorization

60 50 Chapter 4. Internet security focusing on Web services and J2EE In programmatic authorization, the access control rule and associated logic is implemented directly into the system. This allows a finer-grained access control than the declarative authorization can provide. Using programmatic authorization it is possible to write applications that can enforce access control mechanisms such as dynamic access rules, multi-role access, and content level authorization. This can be implemented using the same interfaces and methods as in the J2EE programmatic authentication, namely EJBContext (getcallerprincipal and iscallerinrole) and HTTPServletRequest (getuserprincipal and isuserinrole). Java Authorization Contract for Client Containers (JACC) JACC defines a set of security contracts between the J2EE application containers and authorization policy modules. The contracts specify how the pluggable authorization policy providers are installed, configured, and used in access decisions [18]. In this way JACC provides a standard approach to plugging external authorization providers into a J2EE container. This means that the third party authorization providers are able to make authorization decisions when a user accesses J2EE resources [6]. Transport level security In the J2EE platform SSL/TLS protocols are used to provide secure communications ensuring integrity and confidentiality. The SSL/TLS transport security properties are configured at the container level and J2EE provides configuration options for rejecting unprotected requests and responses [18]. It is the responsibility of the application assembler to identify the components with method calls whose parameters or return values should be protected. The component s deployment descriptor is used to represent this information. The security using SSL/TLS-based communication can be specified for Web components and EJB components, including their Web service endpoints [18]. J2EE component/tier-level security J2EE-based applications are, as discussed in the introduction to the J2EE architecture, made up of several different components. Although these components run in different component containers, the J2EE specification mandates that J2EE server vendors deliver mechanisms for securing each tier and its associated components, clients, and users [18]. This section will take a closer look at each tier to see what mechanism is used to provide security in that specific tier, starting with the client tier. Client tier security Stand-alone clients, rich clients, or Java applets are commonly used as alternatives to Web-based clients. To enforce J2EE security mechanisms from a Java client the following mechanisms are used [18]: HTTPS connection using JSSE mechanisms. JAAS client-side callback handlers to interact with a JAAS Login-Module. Web- or presentation tier security In the Web- or presentation tier the authentication is performed using the following mechanism [18]: HTTP basic authentication.

61 4.3. J2EE security architecture 51 Form-based authentication. HTTP basic or form-based authentication over SSL (HTTPS). Client-certificate or mutual authentication. Digest authentication. Using JAAS pluggable authentication with smart cards or biometric sensors. Single sign-on authentication. Agent-based authentication (third party security). Authorization is performed using the following mechanisms [18]: Declarative authorization. Programmatic authorization. EJB tier or business component security In the J2EE environment, the EJB tier represents the business components. The EJB security model is a subset of the J2EE security model. This means that the authentication and authorization models are similar to the ones used with the Web components. The difference is that the EJB specifications does not specify any supported authentication schemes and leave the responsibility of providing them to the J2EE vendor [18]. Just as with the Web components the J2EE server allows both declarative and programmatic security. In a J2EE environment, it is common for the EJB components to rely on the authentication mechanism provided by the Web container [18]. J2EE uses the notion of protection domains to manage all of the interactions between the components. When a Web client invokes an EJB method, the container propagates the security context via the EJB stubs and skeletons [18]. EIS integration tier J2EE offers a standards-based integration infrastructure. This means that there are mechanisms for using JMS and communicating with for example relation databases via JDBC and EIS systems via J2EE CA [18]. The J2EE CA (Connector Architecture) offers a variety of security mechanisms to protect the EIS resources [18]: User identification, authentication and authorization of principals. Secure communication using for example Kerberos that provides end-to-end security with authentication and confidentiality services. Enabling EIS-specific proprietary security mechanism from for example Oracle, SAP, and BAAN. The J2EE Connector establishes, under the hood, a security contract between the J2EE server and the EIS resource adapter that extends the connection management to support secure communication. Java Message Service (JMS) is an integral part of the J2EE platform and it is an API for asynchronous messaging. Most messaging vendors provide support for some of these security features [18]:

62 52 Chapter 4. Internet security focusing on Web services and J2EE JMS provider authentication and access control. Usually user-name/password or digital certificates. JMS queues protection so that the destinations are available for access to privileged applications. Usually achieved using ACLs. JMS message and transport security. Usually based on the SSL/TLS protocols. For JDBC there are so far no standard security mechanisms, but most of the major database and JDBC driver vendors provide the following custom security mechanisms [18]: Secure communication using HTTP over SSL/TLS. Data encryption. Support for data integrity checking. Support for rich-client communication to databases via Firewall. Support for security auditing and reporting on data access. 4.4 Web service security - standards and technologies This section takes a look at the Web service architecture, standards and what technologies exists to enable security Web service architecture Web services introduced a new paradigm for enabling exchange of information across the Internet. The adoption of open industry standards and standards-based technologies using service-oriented architecture means that a client invoking a service does not need to be aware of what system environment the service is running under. This ensures interoperability among Web services providers and requesters [18]. Web services can be described using a simple operational model. The model can be seen in Figure 4.4 on page 53. The model uses three distinct roles and relationships that define Web service providers and users [18]: Service provider: Hosts the Web services and is primarily responsible for developing and deploying the Web services. The service provider also defines the services and publishes them with the service registry. Service registry: Hosts the lookup information and descriptions of published services and is primarily responsible for service registration and discovery of the Web services. The service requester uses the service registry to find and subscribe to the required services. Service requester: Acts as the Web service client, who is responsible for the service invocation. The requester locates the Web service using the service registry and invokes the service from the service provider.

63 4.4. Web service security - standards and technologies 53 Figure 4.4: Web services operational model A typical Web service architecture-based solution relies on these de facto Web services standards [18]: XML (Extensible Markup Language): The XML standard is endorsed by the W3C 3. It forms the basis for all Web-services standards and has been widely accepted as the de facto universal language for exchanging information between applications over the Internet. In the Web services architectural model, XML plays a vital role as the common wire format in all forms of communication for expressing complex data structures. SOAP (Simple Object Access Protocol): SOAP is a standard for a lightweight XML-based messaging protocol. It enables the exchange of information between two or more peers. SOAP enables the peers to communicate with each other in a decentralized, distributed application environment. It provides transport bindings on top of various Internet protocols such as HTTP, SMTP, and FTP. SOAP is endorsed by the W3C and key industry vendors such as Sun Microsystems, IBM, HP, SAP, and Microsoft. WSDL (Web Service Definition Language): The WSDL standard is an XML representation for describing the services as a collection of operations and its access information. It describes how service providers and requesters communicate with each other. Usually the service provider creates Web services by generating a WSDL file from its exposed business applications. Then the public WSDL address for lookup is published in a Web service registry, such as UDDI so that potential service requesters of the Web service can determine the location of the Web service. WSDL is endorsed by W3C as a standard. The format of an WSDL document will be described in chapter 6. UDDI (Universal Description, Discovery, and Integration): UDDI defines standard interfaces and mechanism for use by the electronic registries (the service 3 World Wide Web Consortium

64 54 Chapter 4. Internet security focusing on Web services and J2EE registry) that store and publish descriptions of XML-based Web services. Querying a UDDI registry for a service returns the location of the WSDL description. The requester can then construct a SOAP client interface that can communicate with the service provider. UDDI is endorsed by OASIS 4 as a standard Core security issues Because Web services open up for making business transactions over the Internet, security has become the most important focus. The Web services need to be secure, reliable and available to the service consumers [18]. Web services are susceptible to all the threats discussed in the Critical application security flaws and exploits-section in chapter 4, but since Web services extensively use XML some of the threats have been somewhat specialized. Below is a list of those threats [18]: XML Denial of Service: This is an attack on content-level vulnerabilities. An attacker makes use of malicious XML messages, manipulates parts of an XML document, or sends an oversized XML payload that can cause load-intensive operations at the target Web service endpoint. This causes systems to crash or to consume an excessive amount of system resources, both of which result in the inability to respond to further requests or perform operations. This is a hard problem to counter since traditional firewalls are quite ineffective for inspecting XML traffic because they do not provide support for detecting content-level threats. XML Schema Tampering: XML Schemas help to verify that an XML message is well-formed and valid. Since XML Schemas are publicly accessible they are liable to attacks. Using a potential loophole, the attacker alters the schema with erroneous and inconsistent information. This makes the Web service endpoint waste resources on failures related to message validation and verification. WSDL and UDDI Attacks: Since both WSDL and UDDI provide servicerelated information in a self-describing XML document that reveals the service location and its exposed operations they are susceptible to attacks. The attacker performs a number of operations with arbitrary input and output parameters using malformed data. The attacker may also inflict changes by tampering with the WSDL descriptions that affect the creation of client side artifacts. From an end-to-end Web service perspective, the complexity of the security threats and risks adds more difficulty to the security tasks (authentication, authorization, etc). In real-world Web services, it becomes very important to address these security issues so that they do not interfere with the benefits and successes of Web services adoption in business organizations [18] Web service security standards Since Web service solutions are implemented using standards-based technologies, it is important to adopt standards-based security mechanisms that facilitate and support interoperability and remain independent of operating system, application infrastructure, and programming language [18]. 4 Organization for the Advancement of Structured Information Standards

65 4.4. Web service security - standards and technologies 55 Many companies rely on SSL for protection because SSL provides authentication, confidentiality and message integrity. However, this only protects the data while it is in transit which makes the environment vulnerable to attacks in multi-step transactions. This results in a need to be able to more specifically address the security challenges. To solve this problem there are several application-level industry standards [4]. These are discussed in the subsequent sections. Content security XML-Signature: Allows signing of any sort of digital content or data objects. The content that should be signed is digested using a message digest algorithm (such as DSA-SHA1 or RSA-SHA1), and the resulting hash value is placed in an XML element. The XML element is digested and cryptographically signed. The signed form of the XML element represents the XML signature [18]. XML-Encryption: Allows encryption of any sort of digital content or data objects such as XML, binary data, and images. It builds on existing industrystandard encryption and facilitates a standard XML-based representation and processing model for encryption and decryption [18]. Message-level security WS-Security: Uses XML-Encryption for confidentiality and XML-Signature for data integrity. It also includes profiles that specify how to insert different types of binary and XML security tokens in WS-Security headers for authentication and authorization purposes. The tokens can be; Username/password (digest), X.509 certificate, a Kerberos ticket, a SAML assertion (explained in the Trust management section), a REL 5 document or a XCBF 6 document [4]. Secure message delivery WS-Addressing: XML framework for identifying Web services endpoints and for securing end-to-end endpoint identification in messages [4]. WS-ReliableMessaging: Framework for identifying and managing the reliable delivery of messages relying on WS-Security, WS-policy and WS-Adressing. It mandates prerequisites, for example trust between endpoints must be established and the message and endpoints must be formally identified [4]. WS-ReliableMessaging Policy Assertion: Defines a policy assertion so that a Reliable Messaging destination and source can describe their requirements for a given sequence [4]. Metadata WS-Policy: Framework that enables one to specify policy information that can be processed by Web services. A policy is expressed as one or more policy assertions representing a Web service s capabilities or requirements. WS-Policy expressions are associated with various Web service components using the WS- PolicyAttachment specification [4]. 5 Rights Expression Language 6 XML Common Biometric Format

66 56 Chapter 4. Internet security focusing on Web services and J2EE WS-SecurityPolicy: Defines a set of security policy assertions used in the context of the WS-Policy framework. WS-SecurityPolicy assertions describe how messages are secured on a communication path [4]. Trust management SAML (Security Assertion Markup Language): Framework for sharing security information on the Internet through XML documents. SAML provides a standard security token (a SAML assertion) that can be used with the WS-Security framework [4]. WS-Trust: Enables security token interoperability using a security token service that allows a party to request a security token from a trusted authority [4]. WS-SecureConversation: Defines the creation and sharing of security contexts between communicating parties. Security contexts mitigate the overhead involved in multiple-message exchanges. WS-SecureConversation defines a Security Context Token (SCT) element, involving a shared secret used to sign and/or encrypt messages, to support the requirements of security contexts [4]. WS-Federation: Provides support for the secure propagation (across Internet domains) of identity, attribute, authentication, and authorization information. By relying on the models defined in WS-Security and WS-Trust, WS- Federation enables brokering of trust and security token exchange, support for privacy by hiding identity and attribute information, and federated sign-out. It leverages WS-Policy and WS-MetadataExchange to describe and acquire metadata [4]. Public key infrastructure PKCS (Public Key Cryptographic Standards): A set containing 12 specifications developed and maintained by RSA Security [4]. PKIX (Public Key Infrastructure - X.509): An Internet Engineering Task Force (IETF) working group with the goal to develop Internet standards to facilitate the use of X.509-based PKI environments. These standards cover areas involving X.509 certificates, Certificate Revocation List (CRL), Lightweight Directory Access Protocol (LDAP), Certificate Management Protocol (CMP), and Time-Stamp Protocol (TSP) to mention a few [4]. XKMS (XML Key Management Specification): Defines a XML based protocol for distributing and registering PKI-based cryptographic keys for use in Web Services. This enables offloading of PKI functionality from the applications to remote trust service providers such as VeriSign. XKMS works in conjunction with XML-Encryption and XML-Signature [18, 4].

67 Chapter 5 Accomplishment This chapter contains a description of the system that has been developed. 5.1 Planning In the planning phase a timetable was created containing the different tasks and during what week the different tasks should be performed. By having a plan that can be followed, the risk of failure will decrease since every task can be reviewed against the plan and updated accordingly. We chose an iterative approach in the development of the project by creating mockups and use cases and refining them when the requirements changed and became clearer. 5.2 Requirements gathering In order to implement a system that satisfies all the requirements, a requirement gathering phase is necessary. During this phase a clear picture of what the system must and must not handle will be clear. In order to do this we had meetings with different kind of stakeholders that possessed different kind of knowledge. The external advisors gave much input regarding how the existing system works and what kind of data is associated with the system. Many of the functional requirements were discovered in meetings with the stakeholders that are the potential users of the final system. The following sections will describe two methods that we found very important in the requirement gathering process Mockup A mockup can be described as a preview of the system that has much of the appearance of the final product, but lacks the functionality. We found that creating mockups gave us important feedback regarding the requirements. By being able to show how the front end of the system will look like it is much easier for the users to understand what the system can do. This is important since it will give the users the possibility to further express the requirements and describe them in a meaningful way. For this project we created two kinds of mockups that were presented to the stakeholders. The first mockup consisted of paper sketches. The advantage of this type of 57

68 58 Chapter 5. Accomplishment mockup is that it is very easy and fast to create and gives important feedback that can be easily updated or changed. When the stakeholders were satisfied with the sketches a more illustrative mockup was created. It consisted of HTML pages with java scripts and it described the Web portal that is the front end of the system. This type of mockup is important since it will give the users the opportunity to test the system s functionality as if it was the real system. The real functionality was simulated, which made it possible to keep it as simple as possible Use case Use cases ware described during the RUP section in chapter 3. We found this to be a good way to describe the requirements to the stakeholders. By having different scenarios describing what will happen during various situations, feedback can be gathered. The use cases will also become an important description in the development phase since it contains all key functionalities that the system must include. One use case for each operation was created and reworked during several meetings with the stakeholders. The formality of the use cases was causal, describing different scenarios. The following scenarios were produced: List available reports. Request report. List report request. Delete report. Assign report access to users. Assign data IDs to users. All the use cases can be found in Appendix A. 5.3 System design The design of the system was divided into two parts: The Web service and the front end. Figure 5.1 on page 59 provides a simple overview of the system. The flow of information corresponding to the numbers in the figure are explained below: 1. The vendor user logs on to the LISA website using a secure HTTPS connection. 2. The front end has got the address to the UDDI register which contains all published Web service endpoints. 3. Each of the services that were discovered in the previous step are invoked during operations that list report types and data IDs. 4. The user is presented with the results obtained from the different services and is free to make subsequent requests. The requests may for example include requesting a report or downloading report files.

69 5.3. System design 59 Figure 5.1: An overview of the system The Web Service One key aspect of the Web service is that it should be dynamic. Reports can be very different depending on various parameters of different type. The system must be able to handle every report type that can be produced from the data that is available at the different servers. This section will describe the different parts of the Web service and how they work together. Report Type In the system a report that can be generated is described by a report type. A report type contains all the information that is necessary for the front end to present the report to the user and provide the possibility to enter values for the input parameters and send a generate report request to the service. Parameters Each report type can consist of zero or more input parameters. The parameters will determine on what data the report generation will be based, for example an organization number or a time interval. Eight types of different parameter types were identified during the requirement gathering phase: 1. String type

70 60 Chapter 5. Accomplishment A string type will represent all parameters that can be described by a simple string. Examples can be names and addresses. Several restrictions can be set for a string type by the report creator. A maximal and minimal number of characters can be specified together with a regular expression that the string must match. 2. Integer type Integer parameters such as organization numbers can be restricted by an upper and lower bound on its value. 3. Float type A float type parameter can also be restricted by an upper and lower bound. 4. Date type In order to represent dates as input parameters in a report, a date type has been defined. The report type creator can specify the earliest and latest date that the user can select. 5. List type A list type can be restricted by the number of items that can be selected and submitted to the service. Two kinds of lists can exist in the system; a simple list and a dependent list. A simple list will be populated when the report description is requested, which is done by calling the SQL statement associated with the list type in the database. A dependent list can be populated dependent on the values of other parameters. This will be useful when the amount of data is too much for a single list. If the data can be categorized the selections can be made in several steps. For example, if the goal is to choose a city, it would be unfeasible to list all cities that are available in the database. The list can be divided into one simple list and one dependent list where the simple list will contain the country names. Depending on what country is selected the dependent list will be populated with all cities in the selected country. A dependent list can be dependent on any number of parameters of any type. 6. Integer interval type The integer interval type contains two integer types with upper and lower bounds on the interval length as additional restrictions. 7. Float interval type The float interval type contains two float types and contain the same restrictions regarding the interval as the integer interval type. 8. Date interval type The last parameter type is a date interval type which is used when a period of time is to be specified. The upper and lower bound on the interval length is specified in number of days. In addition to the restriction of each parameter type described above, default values and help texts can be set which will help the user to enter the input parameter values.

71 5.3. System design 61 Report request When all required input parameters have been filled out by the user a report request object can be sent to the service. The report request contains all information that the service needs in order to generate the report file. Access and administration It is very important that users can not access report types that they are not allowed to access. The administration of access rights is done at the vendor level. Each report type contains information about which vendor offices are allowed to access the report type. All vendor offices have an administrator that can administrate the access rights to the reports at user level. In addition to administration of report types a restriction on the data that the reports are generated from also exists. Portfolio links and data IDs are associated with the data that exists in the databases. A vendor link contains information about what data a vendor office has access to while data IDs can restrict the data at the user level. When these two restrictions are combined it is possible to determine what data a user has access to. The interface The interface is very important in SOA since it will describe the system and define what operations the service will supply. When a web service is designed and implemented two approaches can be considered. A top-down approach starts with a WSDL file and generate the stubs from that description. The bottom-up approach starts with the stubs and the WSDL will be generated from the stubs. We choose the top-down approach since we think that the Web service description is an integrated part of the design of the system. The operations that are supported by the Web service are: getavailablereporttypes The purpose of the system is that users should be able to request reports without the need to contact any person at GE. In order to do so all reports that are available to the user must be listed at some point. This operation supplies that functionality. The request must contain an office ID together with a language code. The office ID will determine what report types should be included in the response and the language code will determine the language of the report types. getdataid In order to supply the functionality to administrate data IDs this operation has been included. Based on the portfolio links and the vendor office ID it is possible to gather the available data IDs and return them to the requester. getdependentlistdata This operation will populate a dependent list depending on the parameters supplied in the request. The populated list will be returned in the response. requestreport The requestreport operation is used when one or several report files should be generated. A thorough explanation of how this process works is explained in the next section.

72 62 Chapter 5. Accomplishment Figure 5.2: An overview of the elements in the request process. getreportrequeststatus The generation of report files is an asynchronous process where the generation time can take from milliseconds up to several minutes. This operation will therefore return information about the report requests that have been issued earlier. The response will contain information about the status of the requests, time when the requests were performed and an estimate of when the generation will be finished. getreportfiles When the report files have been generated by the service, invoking this operation will return the actual files that the generated report consists of. deletereportrequest A report request will automatically be deleted after three month or any other period of time that the administrator of the system chooses. This operation will delete the report immediately. The request process The system is developed to support multiple Web services working in collaboration in order to supply different kind of report types to the front end. A Web service endpoint is obtained from the UDDI registry and is invoked using the necessary credentials. The available report types are listed and all required parameters of the desired report type are filled in. When a request to generate a report file is to be performed, a number of steps have to be executed. These steps are illustrated in figure 5.2 on page 62 and described bellow:

73 5.3. System design The client sends a request message to the service by invoking the requestreport operation described in the previous section. The request contains all parameters that the service needs in order to fulfill the request. 2. The message is put in a queue allowing the service to process the request when resources are available. Since the operation is asynchronous the client is not forced to wait for the operation to complete. 3. When a thread in the service is available it will wait until a message is available in the queue. The message will then be fetched from the queue for further processing. 4. A validation process will validate the report request against the report type stored in the database. The request must contain all required parameters and the values of each parameter must satisfy the conditions specified by the administrator when the report type was created. 5. If the validation process was successful the request will be inserted in the database. When the information has been inserted, the stored procedure responsible for generating the report files will be invoked. 6. When the generation process is done an , informing the user that the generation has completed, will be sent to the client, given that an address was provided in the request. An will also be sent if the process fails at any step. The client can request status about the progress of the request process before, during, and after the report files have been generated. The report files will be available for transfer when the generation is successfully finished. The files are transferred as MIME content in the SOAP response message. The database The database design is important since it plays a vital role in the system. The information about report types and requests is stored in the database together with a number of stored procedures that the system will use in the communication with the database. Stored procedures are the only way the system can send and receive data to and from the database. This will eliminate the need to write long SQL-queries in the code and thereby achieve a better structure and code that is easier to maintain. The database contains tables for every parameter type that was described previously. The report types will be stored together with information about which offices have access to it. When a report request arrives to the service, it will be stored in the database in order to provide status information about the request. The stored procedures use that information in order to complete the generation of the report files. When the report is generated information about where the files are found in the file system is stored in the database. Configuration The system contains several configuration files where the administrator can set attributes that will affect the behavior of the system. The configurable settings describe for example how s are handled, the amount of threads for handling report requests and connections to the database, and security configuration.

74 64 Chapter 5. Accomplishment Security configuration The security is configured in several files. An input and output handler is defined for the Web service and these are configured according to the security that the administrator of the system chooses. In order to invoke the system the client and service alias and passwords are specified according to the generated keystore. The service is by default configured to use password digest, encryption and digital signatures on messages received The front end in LISA In order to demonstrate how the general report publication system can be used in a production environment we designed and implemented a front end. The front end is a Web application that will be running within LISA which will make it possible for vendor users to access the Web service through a simple Web interface. The Web application is designed with the model-view-controller architectural pattern, which will be described in chapter 6. This is implemented using the functionality provided by the Spring framework. The already existing database that LISA use has been extended in order to provide for management of the access rights regarding report types and data IDs. The Web application is built up of the following pages: Available reports On this page all report types that the user has access to are listed. The user can see the report types name and description and view the optional preview image. If the user selects a report type the user is transferred to the Input form page. Input form An input form for the parameters of the report type selected is displayed on this page. The form contains the names of the parameters together with a help text describing each parameter. When the user selects to send the form, the parameter values entered are validated in the Web application according to the restrictions specified in the report type. If one or more parameters are incorrect, the form is re-displayed together with specific error messages next to the incorrect parameters. The error messages are displayed in red font color for extra clarity. Requested reports This page displays the current status of all requested reports. If a report is under generation there will be a count down of the time left next to that entry. When a report is done the user have two options. The first is to download the generated report file(s) and the second is to delete the report. If the user selects to download the Download files page is displayed. Download files On this page the user can download the file(s) generated by the report request. A report can consist of many files. Therefore, the main file is marked to help the user to use the generated report. The main file is the file you should open after all the files are downloaded. Administrate reports On this page the vendor administrator user can administrate the users access to the report types. The vendor administrator can select to give everyone, no one or specific users access to a report type.

75 5.3. System design 65 Administrate data IDs On this page the vendor administrator user can administrate the user access to data IDs. The vendor administrator can select to give a user access to all, none or specific data IDs. All the text on the pages (names, descriptions, help texts, and error messages) is displayed in the user s language. If the user s selected language is not available the texts are displayed in the default language, which is English The tool for creating report types One requirement established at the beginning of the project was that a tool for creating report types should be implemented. The tool will help the administrator to create new report types using a graphical interface. The tool is developed in Java and uses Swing as the toolkit for producing the GUI. It is a simple program that generates a database script for inserting a new report type into the database.

76 66 Chapter 5. Accomplishment

77 Chapter 6 Techniques, softwares and frameworks used The following sections will describe the techniques, softwares and frameworks that have been used during the implementation of the system. 6.1 Web Services Since the system will provide functionality to clients over the network, Web services are the natural choice. It will provide operations that is accessible over HTTP and is independent of the operating system and the environment in which with it will operate WSDL A web service is described in the Web Service Description Language. It contains information about the operations that the service provides together with definitions of the messages that is exchanged in the communication between the service provider and the service requester. How the communication between them is performed is not defined and can vary from implementation to implementation [5]. The WSDL file includes several parts that are associated with each other in some way. The following elements were used in the definition of the Web service [5]: Types Using some type system such as XSD 1 the types container will define the data types in the service. The following example shows the data type defined in a complex type: <element name="name"> <complextype> <all> <element name="first name" type="string"/> <element name="last name" type="string"/> </all> 1 XML Schema Definition, 67

78 68 Chapter 6. Techniques, softwares and frameworks used </complextype> </element> Message The messages that will be used in the communication with the service are specified using this element. The message element will be mapped to one or several data type definitions defined in the Type section. An example of how a message can be specified is given below: <message name="getnameinput"> <part name="body" element="xsd1:name"/> </message> In the example above the namespace xsd1 is used when the Name element is referenced. The element must therefore be defined in this namespace. Operation An operation is an abstract description of an action supported by the services. It will specify which messages will be used when the operation is invoked. The following example shows a simple operation using the message in the previous example together with a corresponding output message. <operation name="getnames"> <input message="tns:getnameinput"/> <output message="tns:getnameoutput"/> </operation> In addition to input and output messages, fault messages can also be defined. Fault messages will be sent by the service when the service throws an exception of specified type. When the output message is omitted the operation becomes a one-way operation and the client will not get a response from the service. Port Type The port type will contain all the operations that the service provides. Binding The bindings will specify which protocols and data formats that will be used for a particular port type. Service The service will contain a collection of port tags defining the endpoints by a combination of a binding and a network address. When these points are combined in the WSDL file it will be possible for a client to communicate with the service. The WSDL file is therefore the only thing that needs to be published in order for clients to invoke the provided operations [5] SOAP SOAP stands for Simple Object Access Protocol and can be described as XML over HTTP. The Web service section in chapter 4 described SOAP and when it is used [2].

79 6.2. Frameworks 69 The advantage of SOAP is that it allows easier access thorough proxies and firewalls since it can send messages over HTTP and HTTPS. Since it uses XML it can however be slower than other communication protocols due to the overhead associated with the serialization/deserialization, validation, and communication [2] UDDI UDDI stands for Universal Description Discovery and Integration and was developed in order to publish and discover businesses worldwide. The UDDI registry can also contain the service description of the businesses [32]. We have used juddi which is an open source java implementation of the UDDI specification. It supports all the common application services and relational databases [32]. A custom authentication class has been added to the distribution in order to restrict the access to publish new services in the back-end database Java EE 5 Java Enterprise Edition is a collection of software standards that has been defined by the Java industry and specifies a java platform for internet based applications. The major concepts of java EE 5 is the following [7]: Annotation instead of deployment descriptors Annotations are Java modifiers that can be specified in the code which will remove the need to include deployment descriptors in the project. Simplified EJB software development Java EE 5 includes a new EJB 3.0 API which will decrease the amount of work performed by the developer. Dependency injection to access resources Dependency injection will enable an object to use annotations to request external resources. Java persistence API model A new persistence API has been developed which is a persistent API for objectrelational mappings. Entities, represented by lightweight java classes, represent a table in a relational database. Entity instances correspond to individual rows in the table [24]. Web services JAX-WS 2.0 is an API that has been developed and is included in Java EE 5. It will provide a library of annotations and toolkits of Ant 2 -tasks and command line utilities that hides the complexity of the XML message protocol. The low level tasks are handled by the API, such as marshalling and unmarshalling. 6.2 Frameworks Frameworks can provide programs, code libraries, or other software that can be useful in a software project. The following sections will describe the three frameworks that have been used in this project. 2 A software tool for automating software build processes,

80 70 Chapter 6. Techniques, softwares and frameworks used Spring Spring is an application framework for the Java platform that provides solutions for many technical challenges that Java developers are faced with. It contains a collection of modules that can be used independently of each other. The different modules of frameworks are [31]: Inversion of control container Inversion of control is a concept where programmers, instead of specifying events during the lifetime of a program, register desired responses to particular events. External entities will take control over the events and the order of them. Spring includes a container which has responsibilities that is related to inversion of control. The container contains means of configuring and managing java objects. Aspect-oriented programming framework Aspect oriented programming is a programming paradigm that will help the developers separate concerns by breaking down the program into distinct parts. The framework supports this by modularize concerns that applies to many aspects of a program. Data access framework Spring tries to address the difficulties that are common for developers to encounter when applications are to communicate with databases. It provides resource management, exception handling, transaction participation, resource unwrapping, and abstraction of BLOB 3 and CLOB 4 handling. Transaction management framework The transaction management framework will bring an abstraction mechanism to the Java platform that is capable of local and global transactions, nested transactions, and transaction safe-points. Model-view-controller framework When a graphical interface is to be designed and developed, it is important to separate the data model from the user interface. Model-view-controller is an architectural pattern that will decouple the data access and business logic by having a controller. This will help to reduce the complexity in architectural design, and increase the flexibility and reuse. Remote access framework The remote access framework provides an abstraction for working with various RPC based technologies available for the Java platform. Authentication and authorization framework Framework that allows for configuration of authentication and authorization processes that supports many standard, protocols, tools and practices. Remote management framework Spring provides a framework for management of Java objects for local or remote configuration. 3 Binary Large Object which is a collection of binary data stored in a database. 4 Character Large Object is a collection of character data stored in a database.

81 6.3. Application servers 71 Messaging framework A messaging framework is included which allow configurative registration of message listener objects for messages from message queues. Testing Spring supports classes for writing unit tests and integration tests XFire XFire is a Java SOAP framework for development and consumption of Web services. The framework supports both top-down and bottom-up generation of stubs and WSDL files. The stubs represent Java classes of the types and faults defined in a WSDL file. XFire contains all Web service standards such as SOAP, WSDL, WS-Security, etc [13]. It is possible to use annotated classes without the need for code generation and WSDL files, although it can be a good idea to consider beginning with a service definition anyway. Calls to Web services that is based on XFire will be interpreted by a Servlet that applies the invocation on appropriate JavaBean that has been implemented and annotated by the programmer. Compared to Axis, which is another SOAP framework, XFire is about two to six times faster [13] Logging In order to log events that occur in the system in an easy and manageable way, the Log4j Java logging framework has been used. It provides six logging levels; trace, debug, info, warn, error, and fatal, which can be used depending on the event that should be logged [27]. The configuration of the framework can be done in either a property file or an XML file which defines three components: [27]. 1. Loggers Loggers are log file names that are known to the Java application. A logger can be individually configured at a specific level such as info, error, etc. 2. Appenders An appender will handle the output of the logging text. For example, a FileAppender will write the output to a file while a ConsoleAppender will write to the console. 3. Layouts Appenders can use layouts in order to format the output. Log entries can for example be written one line at a time or as HTML. 6.3 Application servers The project consists of two systems that require application servers in order to function; the Web service and the Web application. Tomcat 6 was chosen as the container for the Web service. The reason why this application server was chosen is that it supports the Java EE 5 platform and is open source. It also has a large community and is relatively easy to configure.

82 72 Chapter 6. Techniques, softwares and frameworks used For the Web application, Weblogic 10 was used, which is an application server from BEA Systems. This was a natural choice since LISA is running in an environment with Weblogic 8 which will be upgraded to Weblogic 10 in the near future. Although Tomcat and Weblogic were used in the development other containers that support Java EE 5 can be used. The configuration is however different in other application servers. 6.4 Queue management The queue management system is based on Websphere MQ, which is a network communication technology from IBM. It provides a logical container for the message queue and is responsible for transferring data to other queue managers via message channels. Messages are delivered only once and are kept in the queue even if the system crashes. In this system, Websphere MQ is used as the queue management system for report requests that arrives to the Web service. These messages will be stored in the queue until the service is ready to process the message. 6.5 Other technologies In the creation of the Web application a number of techniques and standards were used and some of the most important are described in this section Java Servlet Java Servlet is a technology that was created as a portable way to provide dynamic, user-oriented content. Servlets are used in the request-response programming model and is a language class that can extend the capabilities of servers that support this model. The most common applications that use Servlets are those that are hosted by Web servers. A servlet is an object that receives a HTTP request and generates a response in form of a Web page based on the request [8] JSP JSP stands for Java Server Pages and is a technology for creating both static and dynamic content. It contains a language for developing JSP pages and accessing server side objects together with a mechanism for defining extensions to the JSP language [8]. A JSP is described by two types of texts; static data and JSP elements. The JSP elements construct the dynamic content and can be expressed in two syntaxes; standard and XML. The XML tags are called actions and are used to invoke built-in functionality. It is also possible to define JSP tag libraries that will provide a platform independent way of extending the capabilities of the Web server [8, 26]. A JSP compiler will compile the JSP pages into Java Servlets. The compiler may produce java code that is compiled by the Java compiler or it may generate byte code for the servlet directly. It is also possible to interpret the JSPs on-the-fly and thereby reduce the time it takes to load the page [26].

83 6.5. Other technologies JavaBeans A java bean is a class that is written in Java and follows a particular convention. It can be defined as reusable software components that can be manipulated visually in a builder tool. They can encapsulate several objects into a single object, which is easier to send and receive [25]. The conventions that the implementation of a JavaBean must follow are [25]: The class must have a public constructor without arguments. The properties must be accessible via get, set and other methods. The class should be serializable. It should not contain any event-handling methods.

84 74 Chapter 6. Techniques, softwares and frameworks used

85 Chapter 7 Results The system has been tested for basic functionality. The database was populated with several reports types that together contained all of the parameter types. This way the correctness of both the Web application and the Web service could be verified. 7.1 Screen shots This section contains screen shots of some of the pages of the Web application and of the tool for publishing new report types. The screen shots are displayed in figure 7.1 to figure 7.8 starting on page 76 ending on page Documentation Besides handing over the source code to GE, some documentation was also produced. The documentation consists of a few documents describing how to set up the environment and how compile the Web application and Web service. The documents also describes the service in a more detailed way so that the developers taking over the project can understand how the service works and how the different operations should be invoked. 75

86 76 Chapter 7. Results Figure 7.1: A listing of the report types that are available. If you press the small icon in the Description column, the preview image for that report is displayed. If the SELECT button is pressed, the input form for the parameters is displayed.

87 7.2. Documentation 77 Figure 7.2: This is an example of an automatically generated input form. Here the Branch list has been filled based on the selected value in the Country list and on the value in the Organisation no field. The date chooser to the right of the End value field is displayed when you press the small icon. The report is generated when you press the REQUEST REPORT button and you are transferred to the REQUESTED REPORTS page.

88 78 Chapter 7. Results Figure 7.3: A listing of the statuses of the reports that have been requested by the user. The status of both of the reports ia Done, this means that they are ready for download. If you press the DOWNLOAD button you are transferred to a page where you can download the report file(s) and if you press the DELETE button the report is deleted.

89 7.2. Documentation 79 Figure 7.4: This is the download page for a report. Here the DOWNLOAD button has been pressed and a Save file dialog has been opened.

90 80 Chapter 7. Results Figure 7.5: The page for administrating which user has access to a report. In this case six of the users have been given access to the report.

91 7.2. Documentation 81 Figure 7.6: The page for administrating which Data IDs a user has access to. In this case the user has been given access to nine Data IDs.

92 82 Chapter 7. Results Figure 7.7: This is the main view in the tool for creating new report types. The tool generates a database script that inserts the new report type into the database. When you press the Add button att the bottom the view for adding a parameter to the report type is displayed.

93 7.2. Documentation 83 Figure 7.8: This is the view for adding a parameter to the new report type.