Architectural Design of a Conformative Authentication Service for Security Platforms

(1)

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

Architectural Design of a Conformative

Authentication Service for Security Platforms

by

Mikael Hermansson

LIU-IDA/LITH-EX-A--13/004—SE

2013-01-31

(2)

(3)

Final thesis

Architectural Design of a

Conformative Authentication Service

for Security Platforms

by

Mikael Hermansson

LIU-IDA/LITH-EX-A–13/004-SE

2013-01-31

Supervisor: Ulf Karg´en (IDA)

Jonas Elmqvist (Cybercom) Examiner: Nahid Shahmehri

(4)

(5)

Abstract

Authentication services in security platforms often need to handle different types of systems which have various requirements regarding the authentica-tion. These requirements can often interfere with each other and the issue here is that the authentication service often needs to be manually adjusted to comply with these requirements. Therefore there is a need for a flexi-ble architectural design which enaflexi-bles changes and could open up for new emerging technologies and possibilities. This thesis presents an architec-tural design of a conformative authentication service based on SAML 2.0 to be used in security platforms. In this thesis a requirements analysis was performed and an architectural design was developed. The architectural de-sign presented in this thesis is conformative in various aspects, e.g. usage of various authentication methods, versatile handling of attributes, handling of various SAML 2.0 profiles, possibilities to participate in various identity fed-erations and handling of legacy systems not supporting SAML. In addition, an evaluation comparing the candidate architectural design presented in this thesis with a currently active architectural design was performed. This eval-uation showed that the candidate architectural design was considered better for more usage scenarios.

(6)

(7)

Acknowledgements

First of all I would like to thank both Cybercom Group AB and the Depart-ment of Computer and Information Science (IDA) at Link¨oping University for giving me the opportunity to work with this thesis. I would especially like to thank my supervisor at Cybercom, Jonas Elmqvist, for his many ideas and support throughout this thesis. Then I would like to thank my examiner at IDA, professor Nahid Shahmehri, and my supervisor at IDA, Ulf Karg´en, for their help with reviewing and improving this thesis. Finally, I would like to thank the other employees at Cybercom who have given valu-able input to this thesis, especially Jonas Dehlin, Marcus Gustafsson, ˚Ake Bengtsson and Magnus Nilsson.

Link¨oping, January 2013 Mikael Hermansson

(8)

(9)

List of Figures

1.1 Method Overview . . . 4

2.1 Architectural concepts . . . 10

2.2 Layered Style . . . 15

2.3 Layers With Sidecar . . . 16

2.4 Pipe-and-Filter Style . . . 16

2.5 Shared-Data Style . . . 17

2.6 Kruchten’s 4+1 View Model . . . 19

2.7 SAAM Process Model . . . 23

5.1 Authentication Overview . . . 35

6.1 Example of SAML Participants . . . 43

6.2 SAML Concepts . . . 44

7.1 CESP Components . . . 50

7.2 Use Case 1, Emergency and Rescue Enterprise . . . 63

7.3 Use Case 2, Umbrella Organization . . . 64

7.4 Use Case 3, Banking Service . . . 65

7.5 Use Case 4, Company Federations . . . 66

7.6 Use Case 5, Large Identity Federations . . . 67

8.1 System Overview . . . 70

8.2 Logical View . . . 71

8.3 Process Blueprint . . . 74

8.4 Request and User Interface Process Flow . . . 75

8.5 Validation Process Flow . . . 76

8.6 Configuration Process Flow . . . 77

8.7 Logging Process Flow . . . 78

8.8 Session Process Flow . . . 79

8.9 Response Generator Process Flow . . . 80

8.10 Authentication Core Process Flow . . . 81

8.11 Authentication Method Process Flow . . . 82

(14)

8.13 Attribute Process Flow . . . 84

8.14 Federation Process Flow . . . 85

8.15 Development View . . . 86

8.16 Request and User Interface Module . . . 87

8.17 Validation Module . . . 87

8.18 SAML Profile Module . . . 88

8.19 Configuration Module . . . 89

8.20 Contents of Configuration Module Database Submodule . . . 90

8.21 Authentication Core Module . . . 91

8.22 Session Module . . . 91

8.23 Authentication Method Module . . . 92

8.24 Attribute Module . . . 93

8.25 Attribute Processing Module . . . 94

8.26 Federation Module . . . 95

8.27 Legacy Module . . . 96

8.28 Logging Module . . . 97

8.29 Response Generator Module . . . 98

8.30 Physical View . . . 100

8.31 Scenario 1 . . . 102

(15)

List of Tables

7.1 Internal requirements . . . 54

7.2 Customer requirements . . . 56

7.3 OWASP Top 10 Overview . . . 60

9.1 List of Scenarios . . . 109

9.2 Scenario Evaluation for Current Active Architecture . . . 114

9.3 Scenario Evaluation for Candidate Architecture . . . 118

9.4 Evaluation Summary Table . . . 120

(16)

(17)

(18)

Chapter 1 Introduction

This chapter is an introduction to a master thesis (30 credit points) final report. The thesis was examined at the Department of Computer and In-formation Science (IDA) at Link¨oping University and is the final part of a 5 year degree leading to a Master of Science in Computer Science and Engineering. This thesis has been performed at Cybercom Group AB in Link¨oping. Cybercom Group AB is an IT company that delivers high qual-ity business solutions, primarily in telecom management, connected devices, Internet services and security.

1.1 Background

There are a large amount of systems where security is of great importance. In these systems the confidentiality, integrity and availability of the internal applications and data needs to be assured. Typically this is achieved by implementing the system in a closed network environment where external users have no access to the system.

The increasing demand for service oriented applications has led to a need for opening up these systems to offer services to external users. This is not a trivial task if the security level of the system shall be preserved. Therefore there is a need for a security platform that handles the communication with the internal applications without compromising the confidentiality, integrity and availability of the internal applications and data.

To meet this need, Cybercom Group AB has developed an integration and security platform called Cybercom Enhanced Security Platform, CESP, which offers features such as authentication, access control and logging. Most customers use the platform to enable secure access to their systems. The platform is based on SAML 2.0, which is a standard for exchanging authentication and authorization data.

Authentication is needed to make sure that only trusted users can gain access to the system. The authentication service in security platforms like

(19)

1.2. PROBLEM DESCRIPTION

CESP needs to be able to handle different authentication methods and dif-ferent kind of actors such as individuals or services. The authentication service needs to assure that the user has been identified, authenticated and assigned different attributes (characteristics which describe an identity, e.g. full name and date of birth). An assertion, which is a signed proof of this, is generated by the authentication service. This assertion can then be used to gain access to applications instead of performing a new authentication each time and also enables single sign-on between applications and organizations. Many organizations also want to enable users from other organizations that they trust to securely access their internal applications and data with-out the need for additional authentications. This is called identity federa-tions, which is an emerging technology that can offer both convenience and economic advantages, e.g. more efficient access management and reduced administration costs.

1.2 Problem Description

A security platform like CESP needs to be able to handle various types of systems and these systems often have a variety of different requirements regarding authentication which often can interfere with each other. Exam-ples of such differing requirements could be different types of authentication methods, different ways to handle user attributes or compliance with differ-ent SAML profiles. The problem with this is that the authdiffer-entication service often needs to be manually adjusted for each system which can lead to lots of manual work. These manual adjustments could also lead to the risk of introducing errors and possibly also increased security risks if the authenti-cation service was not originally designed for handling these requirements. A more flexible authentication service could also open up for new emerg-ing technologies and possibilities. To meet new customer requirements and increasing demands for flexibility but at the same time comply with the standards, there is a need to revise the architecture of the authentication service in CESP.

The thesis addresses the following problems:

• How can an architectural design of a conformative authentication ser-vice be developed based on a given set of requirements?

• How can versatile authentication be enabled in the same architectural design?

• Are there any problems with combining different authentication meth-ods in the same authentication service?

(20)

1.3 Objectives

The objective of the thesis is to examine the possibility of designing a con-formative authentication service from a given set of requirements without compromising the security of the system. An evaluation of the architecture shall also be performed.

1.4 Method

The work in this thesis was divided into four main phases: literature studies, requirements analysis, architectural design and evaluation. An overview of the thesis method structure is shown in Figure 1.1.

Figure 1.1: Method Overview

The first phase, literature studies was performed to get the background information needed to create the architectural design for the authentica-tion service. The literature studies were divided into five areas: Software Architecture, Security Architectures, Identity Management, Electronic Au-thentication and SAML.

The second phase of this thesis was the requirements analysis which was performed to elicit and analyze the requirements for the architectural design of the authentication service. The requirements analysis was per-formed using semi-structured interviews with Cybercom employees working with CESP. The results from the semi-structured interviews were summa-rized as a requirements list and a set of use cases. The requirements list was in addition evaluated by two Cybercom customers to make sure that it conformed to their requirements. To gain an additional security

(21)

perspec-1.5. METHOD CRITICISM

tive of the requirements, the security requirements engineering framework described in [22] was used. The OWASP Top 10 [38] was also used to make sure that the most common application vulnerabilities were considered.

The architectural design phase was performed to create the architectural design of the authentication service. Kruchten’s 4+1 View Model [32] was used as a base for the architectural design and consists of five views: Logical View, Process View, Development View, Deployment View and Scenarios. During the architectural design of the authentication service no prior knowl-edge about the architectural design of the current active authentication ser-vice in CESP were given. This decision to exclude that knowledge was taken to avoid being inspired by the design decisions of the previous architecture in order to encourage innovation and to avoid repeating any deficiencies.

Finally, an evaluation was performed using a qualitative scenario-based evaluation method called SAAM [30]. The evaluation was performed to-gether with Cybercom employees. The purpose of the evaluation was to analyze and compare the new candidate architecture presented in this the-sis with the current active architecture.

1.5 Method Criticism

The requirements elicitation was performed using semi-structured interviews with Cybercom employees. However, to provide a more complete picture of the requirements, all authentication service stakeholders should take part in the elicitation. During the requirements phase, to get an additional secu-rity perspective on the requirements the secusecu-rity requirements engineering framework described in [22] was used. However, all parts of this framework was not used and this could cause some aspects to be missing. A smaller framework would have been more suitable for the purpose of getting an additional security perspective of the authentication service requirements.

Kruchten’s 4+1 View Model [32] was used as a base for the architectural design. This model contains information about how to describe the corre-spondence between the different views. However, this part of the model was omitted. Excluding this part of the model could result in some aspects of the architectural design not being covered.

To perform the evaluation SAAM [30] was used. Using this model, all stakeholders should participate in the evaluation. During the evaluation in this thesis, only Cybercom employees working with CESP and the authen-tication service could participate. To get a more complete evaluation, all authentication service stakeholder (e.g. the customers) should have been participating in the evaluation. Another aspect which affects the result of the evaluation is that the scenarios covers requirements which were not known when the current active architecture was designed. This implies that the candidate architecture presented in this thesis have a great advantage compared to the current active architecture. Another evaluation approach which does not focus on these requirements would have been a more fair

(22)

approach. In addition, SAAM is a rather extensive model, a smaller model could have been more suitable for evaluating the architectures.

1.6 Limitations

This thesis only focuses on using SAML 2.0 for the exchange of authentica-tion data. There are several other alternatives (e.g. OpenID and OAuth), but they have not been considered in this thesis. This thesis only covers the architectural design of an authentication service. Implementing the design is out of scope of this thesis since there is limited time.

1.7 Intended Audience

This thesis is intended for an audience with a reasonable background in computer science, software engineering or similar. Some basic knowledge in the area of information security is also advised.

1.8 Thesis Overview

Chapter 1: Introduction gives a description of the background and the purpose of this thesis.

Chapter 2: Software Architecture gives an introduction to software architecture, presents architectural styles and describes software

architecture evaluations.

Chapter 3: Security Architecture presents a description of security architectures and various considerations and patterns useful for designing secure software architectures.

Chapter 4: Identity Management describes what digital identity management is all about and various considerations regarding digital identity management. The chapter also introduces concepts such as single sign-on and identity federation management.

Chapter 5: Electronic Authentication presents a description of what electronic authentication is and describes various concepts related to electronic authentication.

Chapter 6: SAML describes the Security Assertion Markup Language (SAML), what it is all about and how it is structured.

Chapter 7: Requirements Analysis gives a description of how the requirements analysis was performed and presents the results of the

(23)

1.8. THESIS OVERVIEW

requirements analysis.

Chapter 8: Architectural Design presents the architectural design of the authentication service.

Chapter 9: Evaluation describes the architectural evaluation that was performed and the results of the evaluation.

Chapter 10: Conclusions and Future Work gives conclusions drawn from this report and discusses future work related to this report.

(24)

Chapter 2 Software Architecture

This chapter gives an introduction to software architectures and various related concepts, e.g. quality attributes, structures and views. Various architectural styles are presented and a description of software architecture evaluation is given.

2.1 Overview

A software architecture can be seen as a high-level description of a software system which describes the elements in the software and their relationships. There exist lots of different definitions of software architecture since it is a growing and rather young discipline. In [5] software architecture is given the following definition: “The software architecture of a program or a computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the rela-tionship among them.”. This definition implies that the architecture defines the elements in the software and how they relate to each other and does not include things that do not concern their interaction. In other words, the architecture is an abstraction which only includes details about how el-ements use, are used, relate or interact. In most cases elel-ements interacts using interfaces. Interfaces divide the information about an element into a public and a private part. The architecture is only concerned with the public part, the private parts concerning internal implementations are not part of the architecture at all. [5]

Another definition of software architecture is given by the IEEE 1471-2000 standard [26]: “The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” This definition empha-sizes that software architecture is not only a description of the system at a certain point but also includes principles guiding the design and evaluation of the software system.

(25)

2.1. OVERVIEW

Software architectures are highly coupled to the organizational and busi-ness context in which they are used and to the busibusi-ness and organizational requirements. The desire to satisfy the organizational and business goals highly affects the design decisions. Software architecture flows from the experiences in the organization and the experiences that the architect has gathered. The software architecture is a development product that gives high return on investment in the form of quality, schedule and cost. This is since it is the foundation for the rest of the product’s lifecycle which in-cludes development, integration, testing and modification. Analyzing the architecture and finding errors early in the product life cycle is more effec-tive compared to the other development activities since the architectural decisions affect so many other parts of the product’s lifecycle, and if it is later shown that the architecture was wrong then it cannot be changed so easily. Architecture also sets the foundation for re-use, not only for re-use of components but also re-use of the whole architecture which can lead to families of products being developed and new business opportunities. [5]

What is the difference between design and architecture? Architecture is design but not all design is architecture. Many design decisions are left out of the architecture to be decided by designers and implementers [15]. The architecture creates constraints for the following activities which cre-ates the details of the system. The main purpose of the architecture is to make sure that the quality and behavioral requirements are satisfied and that the business goals are fulfilled [15]. These requirements and goals are achieved in the architecture by making architectural decisions about the system structure. Compared to design, the architecture is often concerned with issues of longer range while design is more about producing the right answer and the expected functionality [5]. The architecture is often faced with lots of competing and conflicting influences and demands from both the organizational and technical environment which often aren’t even concerned with the expected functionality. These demands are often as important as the explicit demands even though they are seldom written down [5]. There are many stakeholders that influence the architecture and they often have different concerns which are important for them and sometimes these con-cerns can be conflicting [5]. These conflicting concon-cerns are something that the architect will need to handle.

To elicit the requirements various techniques can be used, for example use cases. Often it is not possible to include all requirements from the stake-holders and tradeoffs will have to be made. Sometimes certain requirements are not noticed until parts of the architecture are constructed and then additional tradeoffs may have to be made. [5]

Software architecture is often used to separate the overall structure of the system, often in terms of subsystems and interfaces which are separated from the internal details of the subsystems [21]. A system consists of several structures and no single part can be said to be the architecture alone [5]. A structure could for example be a system partitioned into implementation

(26)

units which means that the focus lies on the system’s functionality. Another structure could be one which describes how elements interact with each other during runtime which has focus on how the functions are carried out. A single structure can’t be said to be the architecture alone unless the system is trivial [5]. A structure conveys information about the architecture, which consists of a combination of several structures. This implies that the architecture can consist of various types of elements and various types of interactions and also various types of contexts. The behavior of the elements that can be observed by other elements is also said to be a part of the architecture [5].

Between a simple sketch and a complete architecture are several stages which can be very useful. Some important concepts regarding this are: refer-ence model, architectural pattern and referrefer-ence architecture. The relations between these architectural concepts are shown in Figure 2.1.

Figure 2.1: Architectural concepts

Architectural patterns are common descriptions of elements, their rela-tions and constraints describing how they shall be used. A common ex-ample of an architectural pattern is the client-server pattern. Innumerable architectures that use the client-server pattern exists, but they are all dif-ferent from each other. Architectural patterns often bring certain quality attributes, for example performance or availability which is often the reason why a particular pattern is chosen. [5]

A reference model divides a problem into parts that cooperate to solve the assignment. The reference model divides both the functionality and the dataflow. Common examples that have useful reference models are for example compilers and database management systems. [5]

Reference architectures map a reference model onto software elements and their data flows. Here the different software elements cooperate to implement the functionality and a software element can include parts of the functionality or several functions. [5]

(27)

2.2. ARCHITECTURAL STRUCTURES AND VIEWS

2.2 Architectural Structures and Views

Moderns systems are often complex and difficult to understand as a whole and therefore we most often focus our attention to one or a small number of the systems’ structures. This means that to be able to communicate appropriately about the architecture there is a need to clarify which struc-tures we are communicating about and which view of the architecture that is currently discussed. Having multiple views in an architecture helps stake-holders handle system complexity by separating the various concerns into separate views [3]. The terms structure and view are related and are often used interchangeably. According to [5] a view consists of a representation of a set of elements and the relations among them as they are written and read by the stakeholders. A structure on the other hand is the elements itself as they actually exist. Architectural structures can in general be divided into three groups: module structures, component-and-connector structures and allocation structures.

2.2.1 Module Structures

In a module structure the elements are modules which represent areas of functional responsibility. The elements are units of implementation and represent a code-based way of viewing the system. A module structure also describes the relations to other modules, which other modules that can be used and which other parts of the system that each module uses. Some common module structures are: decomposition, uses, layered and class. [5]

2.2.2 Component-and-Connector Structures

In a component-and-connector structure the elements are runtime compo-nents and connectors [5]. Connectors handle the communication among components. Components are often described as self-contained objects with well-defined interfaces that can be used in various environments and connec-tors are used to join components and to encapsulate protocols between the components [21]. The component-and-connector structures describe which the major executing components are and their interactions [5]. They also describe how data is moved through the system and different parts that can be run in parallel. Some common component-and-connector structures are: client-server, concurrency, process and shared data [5].

2.2.3 Allocation Structures

Allocation structures show the relationship between the elements and the external elements in the environment where the software is created and exe-cuted. The structures shows things like which processor an element executes on, which files that store the elements during the development process and

(28)

how elements are assigned to development teams. Some common allocation structures are: deployment, implementation and work assignment. [5]

2.3 Quality Attributes

For most systems quality attributes like security, performance, availability, scalability etc. are as important as making sure that the system performs the correct actions. For example, results could be useless if it takes to long time to perform the actions or if the results are revealed to the competitors [15]. These quality attributes are typically addressed by the architecture but must be considered throughout the whole development process [5]. No quality attributes are exclusively dependent on the architectural design or exclusively dependent on the implementation. The quality attributes are concerned making sure that both the big picture and the details are correct. This means that architecture is critical to achievement of quality attributes but architecture itself is not capable of achieving the quality attributes, it only provides the foundation [5].

There exists a lot of different definitions of various quality attributes [5] and this poses some problems from an architects point of view. The defini-tions are not complete, e.g. when reasoning about a quality attribute like modifiability one cannot state that an architecture is entirely modifiable. The architecture can be modifiable with respect to a specific set of changes but not modifiable to another set of changes. Another problem which the different definitions brings is that the communities which developed the def-initions often have their own vocabulary, which means that the same occur-rence can be using different names [5]. The lack of standardized definitions can therefore cause misunderstandings and communication issues. To avoid these issues it is important to make sure to document the architecture in a comprehensive way. When documenting software architecture it is impor-tant to make sure to describe the quality attributes that drove the design, the decisions made to meet these quality attributes and arguments about the quality attributes [15]. The architecture documentation will serve as a basis for analysis which makes it possible to determine if quality attributes are achieved. Quality attributes can be shown in the architecture in vari-ous ways, e.g. the major design decisions and architectural styles used have quality attributes associated with them [15].

Some of the most common quality attributes are: availability, modifia-bility, performance, security, testamodifia-bility, usability and scalability. Some of these quality attributes can be both software quality and system quality at-tributes since both hardware and software could be needed to achieve them [21].

Availability is concerned with system failure and the results of a sys-tem failure. Syssys-tem failures occur when the syssys-tem is not providing the services it should provide according to it’s specification and can affect both the users and other systems [5]. Availability is about how failures can be

(29)

2.3. QUALITY ATTRIBUTES

detected and prevented, about how long it is acceptable for a system to be out of service and what should happen when a failure occurs. System availability can be increased by using several tactics which mainly are di-vided into three categories. The categories are fault detection (includes, e.g. ping/echo, heartbeat and exceptions), fault recovery (includes e.g. vot-ing, active/passive redundancy and shadow operation) and fault prevention (includes e.g. transactions and process monitors) [5].

Modifiability is about the ability to make changes to a software after it has been deployed. There exist various reasons for changing the software, e.g. correct remaining errors, fix performance issues and changes in require-ments [21]. The main concerns of modifiability is: what can change, when is the change made an who makes it [5]. Unexpected requirements changes could require large modifications and therefore the software should be de-signed for changes and take evolution into account [21]. To increase the system modifiability several tactics are presented in [5], these tactics are split into three categories. These categories are: localize modifications (in-cludes e.g. anticipate expected changes and generalize the module), prevent ripple effects (includes e.g. information hiding and restricted communication paths) and defer binding time (includes configuration files and component replacement) [5].

Performance is generally concerned with how long it takes for the sys-tem to respond when an event occurs [5]. Various performance goals exists, e.g. throughput and response time [21] and these goals can be measured at design time using various methods. Performance is however generally con-sidered to be rather complicated to analyze and measure since there exists so many various events and arrival patterns, e.g. events can occur by user inputs, inputs from other systems and within the system. When an event is recieved the system either processes that event or the processing is blocked, which leads to two types of response time usages: resource consumption and blocked time [5]. To enhance the performance the time of these activities needs to be reduced.

Security is a quality attribute that measures the systems ability to resist unauthorized usage. Attacks are attempts to breach security, e.g. unau-thorized data access or modification or denial of service attacks. According to [5] security can be characterized as providing nonrepudiation, confiden-tiality, integrity, assurance, availability and auditing. There exist various tactics for achieving security, and generally they can be divided into three main categories: resisting attacks, detecting attacks and recovering from attacks [5].

Testability is about to which extent a software is testable [21] and is often described by how easy it is to demonstrate the softwares faults through testing. To be able to test software it is essential that it is possible to control the internal states, the inputs and to be able to observe the output [5]. Tactics for achieving testability have the goal of making testing easier and includes among others: management of input & output and internal

(30)

monitoring.

Usability considers how easy it is for the user to accomplish a task and the level of support that the system provides for this task [5]. Several usability tactics exists and the one which is most closely related to the architecture is to separate the user interface from the rest of the system to provide easier modification [5] of the user interface to meet the users demands and needs. Scalability is about how easy it is for the system to grow after initial deployment [21]. Scalability is concerned with both system and software issues. From a system perspective, a centralized system limits the scalability scope while a distributed system offers possibilities for much more scalability. From the software view the architecture need to be designed to help making growth possible. Using a distributed component-based approach helps to increase scalability compared to a centralized design [21].

2.4 Architectural Styles

According to Garlan and Shaw [19] an architectural style defines a family of systems of components and connectors in terms of their structural orga-nization. Architectural styles are often considered to be the building blocks of software architectures and includes a description of the components and connectors that can be used, various constraints and a description of benefits and drawbacks [15].

2.4.1 Communicating Processes

Communicating Processes is a type of component-and-connector structure where each component can execute as a separate process [15]. There exist several variants of this style. One of the most common variants for systems using substructures is to run the top-level components as separate processes and let the subcomponents execute in the parent’s process [15]. Other vari-ants are e.g. using threads instead of processes. Communicating processes can often be used to describe which portions of the system that can work in parallel and to analyze reliability and performance.

2.4.2 Coupling-and-Cohesion

The notations of coupling and cohesion was introduced by Stevens et al. [45] in the context of structured design when dividing computer systems into modules. Coupling is concerned with the degree that one module relates to the other modules and cohesion is concerned with the degree of which the elements of a module belongs together. Coupling and cohesion are often used as metrics to evaluate software systems. Typically low coupling between the modules and high cohesion within the modules are desired and considered a property of a well-structured software system and good design.

(31)

2.4. ARCHITECTURAL STYLES

2.4.3 Decomposition Style

The Decomposition Style consists of modules (the components) and the decomposition (a type of part-of relation) relations among them. The De-composition Style is used for decomposing a system into its implementation structure and organizes the system into modules and submodules with in-dividual responsibilities. Various criteria are used for decomposition of a module into submodules, e.g. the information-hiding design principle encap-sulates changeable parts of the system into individual modules to enhance modifiability [15]. The constraints put on the Decomposition Style is that modules can only have single parents. The Decomposition Style presents the responsibilities of a subsystem in a system and can be used for e.g. work assignment and analyzing the consequences of changes.

2.4.4 Information Hiding and Encapsulation

The principle of encapsulation and the principle of information hiding are often used interchangeably and refers to method of hiding the internal rep-resentation of a class or a module to shield it from misuse and enhance the reusability and modifiability.

2.4.5 Layered Style

Figure 2.2: Layered Style

The Layered Style hierarchically divides the software into units that groups modules that offer related services. The Layered Style is represented by a layer diagram and is one of the most commonly used styles in software architecture [15]. An example of the Layered Style is shown in Figure 2.2. Each layer provides a cohesive set of services that communicates through interfaces in a strict ordering relation. The relation used in the Layered Style is: allowed to use, which is a variant of the depends-on relation. Since true layered systems promotes modifiability and portability many architectures

(32)

strive to be be shown as layered even if they are not [15]. According to Clements et al. [15] a valid layer system cannot allow a a layer to use the services of a higher layer, since allowing upward usage destroys desirable properties that the Layered Style brings. Some other desirable properties that the Layered Style brings is increased abstraction, enhancement and reuse [19]. However the Layered Style also have some disadvantages, e.g. all systems are not easily structured in a layered manner and finding right abstraction levels can be hard [19]. There exists some variations of the Layered Style regarding which lower layers that can be used, some layering schemes allow a layer to use the services of any lower layer while some only allow the nearest lower layer. Various notations for the Layered Style exists in the literature, e.g. stack notation (shown in Figure 2.2), segmented layers, rings, layers with sidecar (shown in Figure 2.3) etc. Layers are often used in security architectures and this usage is further described in Section 3.4.4.

Figure 2.3: Layers With Sidecar

2.4.6 Pipe-and-Filter Style

The Pipe-and-Filter Style consists of a single type of components, the filter and a single type of connector, the pipe. A filter handles the transformation of a the input data it receives trough one ore more pipes and forwards the results trough one ore more output pipes [15]. An example of the Pipe-and-Filter Style is shown in Figure 2.4. Several filters are often connected and the filters executes incrementally [19]. Filters can also exist in parallel and then execute concurrently. Filters are typically used when the processing can be divided into a set of separate steps and therefore the filters don’t need to know the identity of the upstream or downstream filters [15]. Filters can be used to improve reuse since filters are independent, improve throughput using parallelization and simplify reasoning about behavior.

(33)

2.4. ARCHITECTURAL STYLES

2.4.7 Repository Styles

In repository styles one of the component types are called repositories and consists of large collections of persistent data that other components read data from or write data to. Access to repositories are often handled by Database Management Systems (DBMS) that provides interfaces to handle the data operations. The DBMS often provides services like atomic trans-actions, security, concurrency control and integrity [15]. When repository styles are used the repository component often consists of both the DBMS and the data repository. Some examples of repository styles are: Shared-Data Style and Blackboard Style. In Blackboard Style the data repository may notify the other components about data changes and are mainly used in systems requiring complex interpretations of signal processing [19]. In the Shared-Data Style the components that access the data are responsible for initiating the communication with the repository. This style is further explained in the following section.

Shared-Data Style

The Shared-Data Style (shown in Figure 2.5) have one or more shared-data storage components and shared-data access components that reads or writes the shared-data. The shared-data storage components provides data per-sictence, concurrent access by transaction management, access control, dis-tribution and caching of data [15]. A benefit of using the Shared-Data Style is that it supports modifiability by decoupling the data producers from the data consumers [15]. Architectural quality attributes often associated with this style are e.g. performance, security, availability and scalability. Data could for example be replicated into multiple stores to enhance performance and availability by redundancy [15].

(34)

2.5 ADL and UML

An Architecture Description Language (ADL) is a formal language intended for representation of software system architectures. ADLs presents a way to describe and analyze architectural designs [39] and often includes a formal syntax. Most of the ADLs were created to fulfill specific needs for specific domains and therefore only gained wider adoption within their specific areas. Unified Modeling Language (UML) which is a general modeling language commonly used within software engineering have for a long time not been accepted as an ADL but is now not only accepted as an ADL but have also become a de facto standard notation for software system architecture [39].

2.6 Software Architecture Models and

Meth-ods

Software architectures can be developed and described using various models and methods. Some of the most popular models and methods are: Attribute Driven Design, ISO/IEC/IEEE 42010, Kruchten’s 4+1 View Model and RM-ODP which are described in the following subsections.

2.6.1 Attribute Driven Design

Attribute Driven Design (ADD) is a method for designing architecture that focus on fulfilling both functional and quality attributes [5]. The ADD method is focused on the earliest stages of the design process and is based on on recursive decomposition [4]. The decomposition process is based on a set of quality attribute scenarios which the software needs to satisfy. The ADD method uses three different kinds of views: module view, component and connector view and deployment view [4]. These views represents the first step of the the design process and is therefore rather coarse-grained and more detailed design decisions are needed to make the architecture ready for implementation [5]. The ADD method is designed to handle uncertainty in requirements and depends on “architectural drivers” which are combinations of functional, quality and business requirements that needs to be defined in a reasonable level [4].

2.6.2 ISO/IEC/IEEE 42010

ISO/IEC/IEEE 42010 is a ISO standard named Systems and Software en-gineerings - Architecture description which is based on two main ideas: a framework for architecture description and statements of the information that needs to be included in a ISO/IEC/IEEE 42010 compliant architecture description [29]. In ISO/IEC/IEEE 42010 the documentation of software architecture is based on views and an architecture description consists of

(35)

2.6. SOFTWARE ARCHITECTURE MODELS AND METHODS

one or more views. Requirements for an ISO/IEC/IEEE 42010 architecture description includes [29]:

• Identification and overview information.

• Identification of the stakeholders and their concerns. • Definitions for all architecture viewpoints.

• Architecture views and architecture models for all architecture view-points.

• Architecture correspondences and correspondence rules. • Architecture rationale decisions.

2.6.3 Kruchten’s 4+1 View Model

The 4+1 View Model of Architecture was introduced in 1995 by Philippe Kruchten [32] and is a model for describing software architecture using a set of concurrent views. Kruchten’s 4+1 View Model is an architecture def-inition model which describes the architecture from multiple viewpoints to simplify the complexity of the system [41]. The model is based on multiple views that separately represent the different concerns of the various stake-holders. The model also separately handles functional and non-functional requirements and proposes a notation for how to describe each view. The 4+1 View Model of Architecture consists of four views (logical view, process view, development view, physical view) plus a fifth view (scenarios) that tie the other four views together. The use of the fifth view (scenarios) has been one of the major success factors of the 4+1 View Model which has lead to its widespread adoption [41]. A visual description of Kruchten’s 4+1 View Model is shown in Figure 2.6. For each view, a set of elements

Figure 2.6: Kruchten’s 4+1 View Model

which consists of components, containers and connectors are presented by Kruchten [32], however the 4+1 View Model is generic and other notations can be used.

(36)

The logical view conveys the functional requirements and represents the functionality provided to the end-user. The system is divided into abstrac-tions described as objects or object classes. The approach used and de-scribed by Kruchten [32] is to describe the logical view as class diagrams or class templates.

The process view describes the architecture as a network of communi-cating processes and gives the concurrency and synchronization aspects of of the system. In this view non-functional requirements like performance, scalability and availability are also addressed. The Process View is often described as a set or processes and their relations, and can be described at various levels of detail. The processes are executable units that can be controlled (e.g. started, stopped and reconfigured). To handle load and availability concerns these processes can be replicated [32].

The development view handles the module organization of the software. The software is divided into modules and submodules which can be devel-oped by teams or individual developers. Often the development view is divided into subsystems that are organized in layers. The development view is often used as a basis for planning, cost evaluation, allocation of work teams, progress monitoring and various other management activities. The recommenced approach for the Development View is to use a layered style where each layer has well-defined responsibilities [32].

The physical view describes the mapping between the software and the underlying hardware and also shows distribution properties. Mostly non-functional requirements like reliability, performance, availability and scala-bility are handled by the physical view [32].

The scenarios connects the other four views and shows how they work together and helps the stakeholders to get a better understanding of the other views. This view is redundant with the other four views (hence +1), however it has two main purposes: to help discover new architectural ele-ments during the design and for validation and illustration after the design is complete [32]. In addition, the scenarios provides a way to communicate and reason about the architectural decisions. The scenario view is some-times also called the use case view and according to [15] the use case view is described as architecturally important portions of the use case model.

The elements of the various views are connected to elements in other views and the information flow is from top to bottom and from left to right (as shown in Figure 2.6). This is the original notation from [32], several variations of this flow exists, e.g. [41] describes the information flow as bidirectional since they argue that as the system evolves, the information can flow in both directions. The relations between the elements and the mappings between the different views can be combined and use for various purposes, e.g. as measurable proofs that the system meets it’s requirements [41].

(37)

2.7. EVALUATING SOFTWARE ARCHITECTURES

2.6.4 RM-ODP

The Reference Model for Open Distributed Processing (RM-ODP) is a frame-work that creates architectures that supports integration of distribution, in-terworking and portability [28]. RM-ODP is based on formal description techniques to specify the architecture [28] and describes the architecture from five viewpoints [41]:

• The enterprise viewpoint (business model). • The information viewpoint (information flow).

• The computational viewpoint (component-based software elements). • The engineering viewpoint (distributed nature).

• The technology viewpoint (mapping of component details to technolo-gies).

RM-ODP also provides additional support for architecture analysis by using eight distribution transparencies: Access, Failure, Location, Migra-tion, RelocaMigra-tion, ReplicaMigra-tion, Persistence and Transaction [41]. These transparencies masks critical properties from the view and thereby we can assume that the property is correctly implemented [41]. Using these trans-parencies makes it easier to validate the remaining visible parts of the ar-chitecture.

2.7 Evaluating Software Architectures

Software architecture evaluations determine properties of software architec-tures by analyzing them and verifies architectural decisions compared to problem statements and requirements. The evaluations also determine the satisfactions of quality attributes and helps to find tradeoffs between them since the quality attributes often affect each other in a positive or negative manner. Performing software architecture evaluations has many benefits and the major advantages are that they tend to increase quality, control cost and decrease risks [5].

Software evaluations are typically performed either before implemen-tation (early evaluation) or after implemenimplemen-tation (late evaluation). Early evaluation are often based on the specifications and the descriptions of the software architecture while late evaluation often is based on metrics, e.g. coupling and cohesion of components. Abowd et al. [1] propose to catego-rize the evaluations into two types: qualitative evaluation and quantitative evaluation. Qualitative evaluations use qualitative questions to measure quality. Examples of questioning techniques are: scenarios, questionnaires and checklists [1]. Quantitative evaluations focus on quantitative measure-ments that address specific quality attributes.

(38)

The qualitative technique that have been most widely used are scenario-based methods, which evaluate the software architectures abilities with re-spect to a set of scenarios and offers a systematic way to investigate the software architecture and are flexible and simple [3]. Scenarios describes a single interaction that a stakeholder has with the system and the scenario-based methods determines if an architecture can perform the scenario or not. Some of the most common scenario-based evaluation methods are ALMA, ATAM, SAAM and SBAR which are described in the following subsections.

2.7.1 ALMA

Architecture-Level Modifiability Analysis (ALMA) is is a scenario-based evaluation method that is developed to address the modifiability quality attribute [7]. The ALMA method was initially developed and tested for business information systems only [27]. ALMA is divided into five main steps: software architecture description, scenario elicitation, scenario evalua-tion and interpretaevalua-tion of results [7]. The outcomes of an ALMA evaluaevalua-tion consists of: impact estimates for each scenario, a modifiability model and a scenario generation stopping criterion [27]. ALMA focuses on modifiability, and this focus can be divided into three main goals: maintenance prediction, risk assessment and software architecture comparison [7].

2.7.2 ATAM

Architecture Tradeoff Analysis Method (ATAM) is a comprehensive scenario-based method to evaluate software architectures according to satisfaction of quality attributes [5]. ATAM especially provides a way to evaluate soft-ware architectures with respect to competing quality attributes [42] and is based on SAAM (see section 2.7.3) [27]. The ATAM evaluation is carried out in 9 steps and is considered to be a more complex method compared to SAAM [42]. The ATAM evaluation focuses on the most important quality attribute requirements, which means that the evaluation will not tell if all the requirements of an architecture is will be met [5]. ATAM is a robust evaluation method that focuses on the high-priority scenarios and on finding areas of risk in an architecture [5].

2.7.3 SAAM

Software Architecture Analysis Method (SAAM) is a method used for ana-lyzing the properties of software architecture. Originally the method was de-veloped to compare competing architectures and was introduced by Kazman et al. [30] in 1994. It has with increased experiences evolved and therefore there exist variations in the steps involved in SAAM [31].

The inputs to the SAAM method mainly consists of business drivers, architecture descriptions and quality requirements. The outputs consists of

(39)

2.7. EVALUATING SOFTWARE ARCHITECTURES

quality sensitive scenarios and estimated efforts required to fulfill the sce-narios. Some recognized business drivers for software architectures are the quality attributes [30]. According to Kazman et al. [31] the scenarios differ widely in both size and complexity. The scenarios are brief description of the desired use of a system, and they are typically a sentence long. Kazman et al. [31] also emphasizes that not all scenarios are impacted by the ar-chitecture, some depend on code level or hardware level aspects and some cannot be evaluated at architectural level. The scenarios are divided into direct scenarios and indirect scenarios. Direct scenarios are those that are directly supported in the architecture and indirect scenarios are those that requires changes to the architecture. The purpose of the SAAM is not to criticize any architecture, but rather about providing a way to decide which architecture that is best suited for an organization’s needs [30]. A visual-ization of the SAAM process model is shown in Figure 2.7 and consists of the following steps [31]:

Figure 2.7: SAAM Process Model

1. Describe candidate architecture(s). This candidate architecture(s) shall be described so that it is well-understood by the parties involved in the evaluation. Both the computation and data components shall be described.

2. Develop scenarios. The scenarios that are elicited shall describe the activities the system must support and changes that are likely to be made to the system. It is important to capture all uses of the system and tasks that are relevant to various roles, e.g. end-user and system administrator.

3. Perform scenario evaluations. For each indirect scenario the vari-ous changes to the architecture that are needed shall be listed together with a estimate of the cost of performing the change. Changes are ei-ther new components or connections that need to be introduced or

(40)

that changes need to be made to the specifications of existing compo-nents or connectors. This stage should result in a summary table that lists all scenarios (both indirect and direct). For the indirect scenarios the impact or changes shall be described. The tabular summary is especially useful when comparing alternative architectures to find out which architecture that best supports a set of scenarios.

4. Reveal scenario interaction. Scenario interaction is when two indi-rect scenarios require changes to the same components or connections. Revealing scenario interactions therefore consists of identification of scenarios that affect common components and is a way to measure how well an architecture supports separation of concerns. For each component all indirect scenarios that affect it should be determined. 5. Overall evaluation. The final step is overall evaluation which is

about weighting each scenario according to their relative importance to produce an overall ranking. The weighting should be performed by all stakeholders involved in the evaluation and is a way to reflect about the importance of the quality attributes that the scenario represents.

2.7.4 SBAR

Scenario-Based Architecture Reengineering (SBAR) is a method for reengi-neerings software architectures [6] and the method is used to evaluate op-erational quality attributes of an architecture [42]. The reengineering of an software architecture is often started by major changes in the require-ments and these changes are often concerned with software quality attributes [6]. The input to an SBAR evaluation consists of an updated requirements document and the existing architecture and the output is an improved ar-chitecture [6].

(41)

Chapter 3 Security Architecture

This chapter explains what security architecture is and describes security goals and security considerations. Various secure design patterns are pre-sented and the area of software security architecture is described.

3.1 Introduction to Security Architecture

Security architecture is a design that handles requirements (e.g. authenti-cation and authorization) and risks (e.g. risks of a particular environment) and determines which security controls should be used [47]. The term se-curity architecture is broad and generally consists of the following elements: network, host, applications, information, software, hardware, databases and physical [2]. There are no general security architecture solutions which will work across organizations and with changing infrastructure. This implies that security architectures need to be able to adapt changes both in tech-nologies and strategies [2]. In software architecture, the term “security”can often do more harm than good since there exist various definitions which are often conflicting [40]. This implies that the architecture must provide specific security guidance to the other stakeholders [40]. Software security architecture is something that needs to be handled as an iterative process by decomposing complex problem areas to get an understanding of the details and then building up the design according to the security goals [40].

Various security components focuses on hardening systems against threats while often excluding other goals. Secure design patterns (described in Sec-tion 3.4) focuses on both strong security and good architecture and therefore brings balance to the architecture [41].

Security Assertion Markup Language (SAML) is an open standard for ex-changing security information (authentication and authorization data) and can be used as a base for software security architectures. SAML provides opportunities for authentication, encryption, management of digital rights and federated architectures and is further described in Chapter 6.

(42)

3.2 Security Goals in Architectures

Software architects are often given the goals of designing future-proof sys-tems, which implies that the system should have the flexibility to adapt to changes of various natures [41], e.g. technology changes, volume growth, introduction of new interfaces and changes in the threat landscape. These goals increase the complexity of the system and to handle this complexity the systems are often divided into multiple levels of abstraction. The ar-chitect often creates interfaces between subsystems to minimize the impact of changes to subsystems onto the whole system. This way of designing the architecture enables the architect to hide design decisions about the im-plementation of subsystems from the other parts of the system. However adding security to the architecture often has the negative impact of col-lapsing the hierarchy of abstraction by promoting low-level decisions to a higher level [41]. Therefore security need to be implemented according to structured security architecture guidelines to avoid creating tension in the design.

3.3 Security Considerations

Designing for failure, i.e. making a design that can handle and recover from failures, is a fundamental principle in security design. In most systems the focus is on the basic flow of the system since it is these flows which provides business value, however from a security perspective it is important to focus on the exceptional and the alternative flows since these often become the attack vectors [40]

The use of distributed systems is increasing and these systems are often used in ways not intended by the original architectural design, e.g. old legacy systems get connected to the web, data and messages are used in ways not intended by the protection mechanisms [40]. A security countermeasure for this type of security problem is to move the security mechanisms closer to the assets, e.g. using technologies like encryption for the data elements to constrain access to persistent data [40].

3.4 Secure Design Patterns

Secure Design Patterns have the purpose to avoid introducing vulnerabil-ities and to mitigate consequences of vulnerabilvulnerabil-ities [17]. Secure design patterns exists at various levels ranging from high-level architectural pat-terns to implementation patpat-terns, however this section will focus on secure design patterns suitable for architectural design of software systems. Archi-tectural security patterns have to goal of enabling valid communication in a way which is as transparent as possible, while at the same time blocking all invalid communication [41]. This section will introduce some of the secure

(43)

3.4. SECURE DESIGN PATTERNS

design patterns for architectures.

3.4.1

3.4.2 Distributor

The distributor pattern is a more abstract architectural structure that takes a communication stream and separates it into multiple streams based on some criteria [41]. Distributors can be either symmetric (identical outgoing streams) or asymmetric (separating outgoing streams based on e.g. protocol and QoS rules) [41]. Distributors are often used in security architectures at specific network choke points (e.g. for load balancing) [41]. In these situations it is important to use the same security strategy at all outgoing locations to avoid attacks of the type that uses wrapping of one type of communication into another type to bypass security checks.

3.4.3 Interceptor

Interceptors are a type of man-in-the-middle security components [41] that can add, delete or modify the communication between communicating par-ties. Interceptors ore often used in security architectures and can be bined to supply complex decision support, and can by that implement com-plex security actions [41].

3.4.4 Layers

The general layered style for software architectures is described in Section 2.4.5. The layer pattern is one of the most widely used patterns in secu-rity architectures and is used for various purposes. Using layers in secusecu-rity architectures provides a way to separate the different layers using clearly defined interfaces which helps to hide implementation details in one level from the other levels [41]. Layers are used to separate functionality, e.g.

(44)

secure transport, secure infrastructure and security services [41]. Layers in security architectures are often even more strict than layers in the gen-eral sense. This strict type of layering prohibits interaction of a layer with anything else than the direct underlying layer [41]. Regarding security, the most important attribute of a layer is modifiability since this provides possibilities for adding additional security to an existing software without affecting the code of other parts of the software [41].

3.4.5 Trusted Third Party

A trusted third party is an entity that is trusted by all other entities involved in secure communications [41]. In the initialization phase all participants agree to trust the third party, and this trust includes information received, decisions and validations. There exist some variants of a trusted third party, e.g. inline (acts as a proxy), online (real time interaction) and offline (pro-cessed when available) [41]. Various examples of trusted third parties exists e.g. Public Key Infrastructures (PKIs). PKI is one of the most used meth-ods for handling public encryption keys. In PKIs the Certificate Authority (CA) is a trusted entity which is used to sign documents, the Registration Authority (RA) is the trusted entity which handles the proof of identity for certificate requests. PKIs also includes Certificates Revocation List (CRL) servers which handles a list of revoked certificates and the Online Certifi-cate Status Protocol (OCSP) handles real time verification of certifiCertifi-cates. Another variant of trusted third party is the PGP cryptosystem where users sign each other’s certificates.

3.5 Software Architecture Security

Security have for a long time been presented as an independent property of a software system rather than a real system feature, it is only recently that se-curity has become a principle that is integrated into the design of the system [41]. Garlan and Shaw [19] provides some actions that an architect should perform when designing secure software, e.g. decomposing the system into subsystems (where each subsystem has a specific architectural style), choose security components that matches the styles (by implementing the required security properties), add security constraints and choose communication se-curity components that enforce required sese-curity properties. The choice of architectural style therefore drives the choices of security components and their relations to other parts of the system.

Additional principles for secure software architecture includes e.g. proper identity management (described in Chapter 4), authentication and autho-rization (described in Section 4.4 and in Chapter 5).