H2020 ICT9 Project DeliverableD6 - CHOReVOLUTION · (CEFRIEL), Marco Masetti (Softeco), Angelo Naselli (Softeco), Olivier Bouzereau (OW2) Final version ready for PMC PMC 15 July 2015

H2020 ICT9 Project

Deliverable D6.1

CHOReVOLUTION Platform Re-quirements and Integration Re-quirements

http://www.chorevolution.eu

LATEX template v. 1.0

Project Number : H2020-644178Project Title : CHOReVOLUTION

Automated Synthesis of Dynamic and Secured Choreographiesfor the Future Internet

Deliverable Number : D6.1Title of Deliverable : CHOReVOLUTION Platform Requirements and Integration

RequirementsNature of Deliverable : ReportDissemination level : PublicLicence : –Version : 3.0Contractual Delivery Date : 1 July 2015Actual Delivery Date : 15 July 2015Contributing WP : WP6Editor(s) : Marco Autili (UDA), Amleto Di Salle (UDA), Alexander Pe-

rucci (UDA), Massimo Tivoli (UDA)Author(s) : ALL partnersReviewer(s) : Marco Masetti (Softeco), Angelo Naselli (Softeco), Olivier

Bouzereau (OW2)

AbstractThe goal of this document is to elucidate the requirements of the CHOReVOLUTION platform, i.e., thelocal requirements of the constituent components developed in WP2 and WP3, as well as their inte-gration and development requirements. Satisfaction of platform requirements results from addressingthe local components and integration requirements jointly with the use-case related requirements inWP4 and WP5, since developers of applications based on the CHOReVOLUTION solution are ac-tually the users of the platform. To this end, in collaboration with WP4 and WP5, analysis resultscoming from the use cases investigation are also accounted for. Furthermore, previous experience ofthe consortium partners coming from the CHOReOS project (of which CHOReVOLUTION is a follow-up project) is leveraged. Different categories of requirements are elicited, e.g., requirements on thefunctionalities that will be supported by the constituent components, requirements on the way thelatter will be developed and integrated at the level of their interfaces and architectural connections, aswell as their non functional requirements.

Keyword ListFunctional requirements, non functional requirements, integration requirements, development requirements,requirement collection process, requirements description.

CHOReVOLUTIONH2020-644178 III

CHOReVOLUTIONH2020-644178 IV

Document History

Version Changes Author(s)0.1 Outline Draft Marco Autili (UDA)

1.0 First preliminary draftMarco Autili (UDA), Mas-simo Tivoli (UDA)

1.1 First preliminary draft containing all chapters ALL partners1.2 First revision of individual chapters ALL partners1.3 Second revision ALL partners1.4 Third revision after PMC2 meeting in L’Aquila - Italy ALL partners

2.0 Overall integration and editionMarco Autili (UDA), Mas-simo Tivoli (UDA), ALLpartners

2.1 Chapters restructuringMarco Autili (UDA), Mas-simo Tivoli (UDA)

2.2 Comments from reviewers addressedMarco Autili (UDA), Mas-simo Tivoli (UDA), ALLpartners

3.0 Final version ready for PMCMarco Autili (UDA), Mas-simo Tivoli (UDA)

A.0 Final version Marco Autili (UDA), Mas-simo Tivoli (UDA)

Document Reviews

Review Date Ver. Reviewers CommentsOutline 15 May 2015 1.0 ALL partners Preliminary draft version available

Draft 19 June2015

1.4Marco Autili, Mas-simo Tivoli

Intermediate version released forinternal review

QA 29 June2015

2.2

Gianmarco Panza(CEFRIEL),Marco Masetti(Softeco), AngeloNaselli (Softeco),Olivier Bouzereau(OW2)

Final version ready for PMC

PMC 15 July 2015 A.0 PMC –

CHOReVOLUTIONH2020-644178 V

CHOReVOLUTIONH2020-644178 VI

Glossary, acronyms & abbreviations

Item DescriptionAPI Application Programming Interface

BPMN2 Business Process Modeling Notation - ver. 2CD Coordination Delegate

DoW Description of WorkEE Enactment EngineGUI Graphical User InterfaceM2M Model to ModelR&I Research & Innovation

RBAC Role Based ACcessSOA Service-Oriented Architecture

CHOReVOLUTIONH2020-644178 VII

CHOReVOLUTIONH2020-644178 VIII

Table Of Contents

List Of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI

List Of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Requirements Collection Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Requirements specification template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Requirement specification fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 Requirement terminology and prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.3 Requirement verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 CHOReVOLUTION platform overview: a toolbox of well-integrated components. . 113.1 CHOReVOLUTION platform overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 CHOReVOLUTION actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 CHOReVOLUTION platform components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Local requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Integration requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6 Development requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Annex A Security analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Annex A.1 Maintaining operational security condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Annex A.1.1 At design time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Annex A.1.2 At runtime time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Annex A.2 Threats Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Annex A.2.1 Method description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Annex A.2.2 Security threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Annex A.3 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

CHOReVOLUTIONH2020-644178 IX

CHOReVOLUTIONH2020-644178 X

List Of Tables

Table 2.1: CHOReVOLUTION Requirements Specification Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

CHOReVOLUTIONH2020-644178 XI

CHOReVOLUTIONH2020-644178 XII

List Of Figures

Figure 1.1: Local requirements versus Integration requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Figure 3.1: CHOReVOLUTION approach at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 3.2: CHOReVOLUTION platform overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 3.3: CHOReVOLUTION actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure Annex A.1: CHOReVOLUTION Flow diagram for UTC scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

CHOReVOLUTIONH2020-644178 XIII

CHOReVOLUTIONH2020-644178 XIV

1 Introduction

The objective of the CHOReVOLUTION platform is to provide automated support to the synthesis,deployment and enactment of choreography-based service-oriented systems through distributed com-position of heterogeneous software services. Overcoming the limitations of current service compositionapproaches, the CHOReVOLUTION platform defines methods and implements related tools that con-stitute the core of an innovative technological platform for realizing dynamic and secured servicechoreographies in the Future Internet. Specifically, the CHOReVOLUTION platform is a toolbox ofwell-integrated software components to be developed in WP2 and WP3. The platform will be validatedagainst the industrial use cases in the domains of Intelligent Transportation Systems (ITS) and SmartMobility & Tourism (SMT) developed by WP4 and WP5. The goal is to boost the availability and mar-ket take-up of the CHOReVOLUTION components and highlight potentials for productivity gains in theindustry sector.

The CHOReOS EU project1 introduced an Integrated Development and Run-time Environment(IDRE) to support the realization of choreographies in the Future Internet. CHOReOS choreographiesare static meaning that they are not able to dynamically evolve, and do not account for security issues.The CHOReOS IDRE is organized around “core components” for choreography modeling and synthe-sis, choreography deployment and enactment, and choreography execution on top of the CHOReOSmiddleware. Around these core components, “complementary components” was developed to take re-quirements as input, discover suitable services, analyze the synthesized choreography, and monitor itsexecution.

As acknowledged by the EU commission and experts, the CHOReOS results and related experi-ments have been found promising. Specifically, at the time of CHOReOS birth and development (witha still premature establishment of the Future Internet), prototyping a novel overall IDRE and validatingit against the CHOReOS use cases was recognized as a big challenge per se. To raise the CHOReOStechnology to its full innovation potential, it has been recommended that (i) “the maturity level of theCHOReOS IDRE tools should be enhanced for adoption by industries” and (ii) “the produced chore-ographies should exhibit those capabilities that enable their effective applicability in industrial contexts,namely dynamic (i.e., adaptable and evolvable) and secured choreographies”. Indeed, the overallrecommendation was to increase the probability of success, hence reducing risks, by focusing on theenhancement of the core components to enable dynamic choreographies and on the development ofnew ones to support secured choreographies.

Addressing such recommendations, CHOReVOLUTION comes into play to deliver a toolbox whoseconstituent components bring the production of dynamic and secured choreographies to the technologyreadiness level required by industries.

In this respect, CHOReVOLUTION is a follow up of CHOReOS and, hence, some of the requirementscollected in this document are a revised version of requirements coming from CHOReOS. Following therequirements collection process described in Chapter 2 and adopting the related requirements speci-fication template allows for distinguishing among newly introduced requirements – needed because ofthe new CHOReVOLUTION capabilities (dynamism and security) and its new use cases – and previousrequirements coming from CHOReOS.

1http://www.choreos.eu/

CHOReVOLUTIONH2020-644178 1

http://www.choreos.eu/

A further overall objective of CHOReVOLUTION concerns the establishment of a CHOReVOLU-TION community and market take-up. We aim at developing the conditions that will enable the take-upand further enhancement of the code base by third-party developers, especially SMEs, including de-velopment of new applications to be commercialized. To ensure sustainability beyond the lifespanof the project by means of third-party interest and contribution, we aim at establishing CHOReVO-LUTION as an ambitious open source project, with its own market visibility and stakeholders, sup-ported by a well-established open source community such as OW2. Within OW2, CHOReVOLUTIONwill be promoted under the umbrella of the Future Internet Software and Services initiative (FISSi,http://www.ow2.org/view/Future_Internet/), an activity set to develop awareness for OW2Future Internet software towards members and non-members alike, open source vendors and propri-etary vendors alike, with a market oriented approach.

This document reports a first version of the CHOReVOLUTION platform requirements. They areorganized into local requirements of the constituent components, as well as their integration and devel-opment requirements.

• Local requirements describe the functionalities that will be offered/required by the constituentcomponents and the related interfaces (see Figure 1.1).

• Integration requirements prescribe how the constituent components integrate at the level of archi-tectural connections, according to their offered/required interfaces (see Figure 1.1).

• Development requirements concern tools supporting rules and best practices of the coding pro-cedures, and related collaborative activities among the platform developers, that are required forthe implementation of the constituent components.

Figure 1.1: Local requirements versus Integration requirements

The process of collecting requirements was inspired by the commonly used VOLERE methodol-ogy2 [7], and for specifying each single requirement, we adopt a VOLERE-inspired template.

The set of requirements will be used by consortium members to set ambitions and prioritize R&Iwork, to assess the achievement of the overall aim of CHOReVOLUTION described in the DoW, aswell as to be able to verify the possibility to meet the CHOReVOLUTION community expectations thatwill likely influence the CHOReVOLUTION platform development during and after the lifetime of theproject. New requirements may show up and (the version of) existing ones may evolve according tonew needs and expectations of both consortium members and community members. The requirementsset will be revised and amended as needed, as an outcome of the platform integration and use-caserealization testing and validation over the CHOReVOLUTION platform. As integration testing, leadingto bug fixing, code refactoring/optimization of the current release of the platform, and validation of sucha release, will be carried out in dedicated sessions along a calendar year of the project starting from theplatform release provided at the end of the previous year, the new release at the end of the year will beemployed to realize the use-cases being developed in WP4 and WP5. Details about the managementof the CHOReVOLUTION platform releases will be provided in deliverable D6.2.

2http://www.volere.co.uk/


http://www.ow2.org/view/Future_Internet/

http://www.volere.co.uk/

In the light of the latter consideration, the first version of the requirements reported in this documentwill be then moved into a tool (e.g., JIRA3 or Tuleap4) that, together with issue and project trackercapabilities, allows for requirements management and maintenance. Such a tool will be provisioned byOW2 together with other development management tools (e.g., Maven5 and Bamboo6) for supportingthe implementation of the toolbox constituent components.

The rest of this document is organized as follows:

• Chapter 2 describes the methodology we followed to collect the requirements. Furthermore, arequirement specification template is defined by describing its constituent fields and explainingtheir rationale and aim.

• Chapter 3 provides an overview of the platform and describes its constituent components andinvolved actors.

• Chapter 4 provides the local requirements for the platform constituent components.

• Finally, Chapter 5 and Chapter 6 provide the integration requirements and development require-ments, respectively.

3https://www.atlassian.com/software/jira4https://www.tuleap.org5http://maven.apache.org6https://www.atlassian.com/software/bamboo


https://www.atlassian.com/software/jira

https://www.tuleap.org

http://maven.apache.org

https://www.atlassian.com/software/bamboo


2 Requirements Collection Process

In this chapter, the requirements collection process is presented. The adopted methodology is de-scribed in Section 2.1; the adopted requirements specification template is defined in Section 2.2

2.1. Methodology

The adoption of a common methodology to define a process for gathering, collecting and specifyingrequirements increases the probability that all needed aspects are taken into account and incorporated,also in favor of more objectivity. Such a methodology should be based on a well-known approachthat has already been proven to be effective. Requirements for the CHOReVOLUTION platform weredefined by the consortium partners, considering different points of view, project objectives, use cases,past experiences and knowledge, also coming from the CHOReOS project. Together, the outcomesfrom these sources resulted in a coherent set of requirements for the CHOReVOLUTION platformpresented in this document.

As introduced, the approach to requirements gathering and collection was inspired by the well knownand commonly used VOLERE methodology, as adjusted to the CHOReVOLUTION needs. It consistedof the following steps:

1) Project goals, DoW, scenarios and related use cases (reported in the deliverables D4.1 [1] andD5.1 [2]), previous CHOReOS requirements were analysed in order to identify an initial set of re-quirements specifically focusing on the new challenging capabilities to be offered by the CHOReV-OLUTION platform. As already said, the new capabilities mainly concern choreography dynamicadaptation and evolution, and secure choreographies.

2) As a result of step 1, the initial list of requirements was defined and was treated as a baseline.

3) Next, the list was cross-verified and updated by consortium members taking into account theirknowledge and experiences as well as technical constraints. In this step three iterations wereneeded:

- In the first iteration, requirements were divided into groups according to the overall CHOReV-OLUTION platform overview given in Chapter 3, the identified first-class components, andtheir interconnections. Each WP Leader, together with (at least two) representatives perpartner involved in the WP, was responsible for the shape and content of requirements refer-ring to their respective WP. The purpose of the first iteration was a collection of all possibleinputs and ideas according to particular project area.

- In the second iteration, the combined effort of identifying requirements within WPs wasmerged into the overall set of requirements. Having the whole list of requirements fromdifferent WPs, consortium members were collaboratively able to consolidate them, identifygaps, redundancies and define one comprehensive set of requirements.

- In the third and final iteration, requirements were specified in more detail, providing the fulldescription of all requirements.


4) At the end of the process, the requirements resulted organized into three main groups, namely,local requirements, integration requirements, and development requirements.

5) The outcome of the whole process is the final set of defined requirements organized into thegroups above and reported in Chapter 4, Chapter 5, and Chapter 6, respectively.

The specification process of each single requirement was inspired by the SMART approach [5] andits principles. The application of this approach is aimed at defining clear, unambiguous requirements,which can be measured at the final stage. In a manner of speaking, “requirements should be as SMARTas possible”. However, in a research project like CHOReVOLUTION, where many aspects are yetto be considered and analyzed during the whole project lifetime, specifying, updating, and validatingrequirements while meeting the SMART principles is not always possible since the beginning. In thiscase, an incremental process should be adopted. That is, as already introduced in Chapter 1, newrequirements may be added and (the version of) existing ones may evolve according to, e.g., newneeds and expectations of members of both the consortium and the (emerging) CHOReVOLUTIONopen source community.

Starting from the seminal work on the SMART approach in [5], different definitions of SMART require-ments have been available during the past years. For the purpose of requirements specification in theCHOReVOLUTION project, the following definitions were considered:

• Specific - Concise and Complete - clear, there is no ambiguity, the requirement shouldn’t be opento interpretations, should contain the proper amount of detail. Words such as several, some, soon,fast, and other undefined terms should be avoided.

• Measurable - Testable and Unambiguous - the requirement should be interpreted only one way,and the way how the final solution can be tested/verified to prove that this requirement is metshould be indicated. Undefined time periods/quantities and non-fact based measurements, likebetter than, often, should be avoided.

• Attainable - it should be actually possible for the system to exhibit the requirement under the givenconditions. The requirement should be appropriate for the project, realistic to achieve within theproject parameters, derived from a valid source of information.

• Realizable - Necessary and Feasible - the requirement should be needed for the solution to func-tion properly within the scope of the project, and possible to achieve considering resources, bud-get, and due date.

• Traceable - Identifiable and Linked - the requirement should be uniquely identifiable through anumbering hierarchy, to be traced (forwards and backwards) from its conception through specifi-cation to subsequent design, implementation, and test.

2.2. Requirements specification template

The VOLERE methodology provides a Requirements Specification Template with guidelines for writingappropriate requirements specifications, and it is intended for use as a basis for requirements specifi-cations. In order to define the requirement specification fields to be incorporated in the template, thefollowing aspects were considered:

1) Functional aspects - the fundamental or essential subject matter of the product, the main capa-bilities of the product, offered functionalities, services, and processes to be realized. The productis the CHOReVOLUTION toolbox containing well-integrated software components that provide au-tomatic support to the realization of dynamic and secure service choreographies, from modelingand synthesis, to enactment and execution.


2) Non functional aspects - the properties of the offered functionalities (such as, performance, lookand feel, and security aspects), and, as part of the development requirements, constraints on thecoding procedures and related collaborative activities among the developers of the componentsconstituting the toolbox (such as, adopted standards, rules and best practices on collaborativecoding activities and bugs tracking procedures).

3) Project drivers - the business-related aspects, including the purpose of the project and all thestakeholders. Aspects such as project concept, objectives, purpose and vision are described inDoW.

4) Project constraints - restrictions on the product realization:

- due to the budget or the time available, the time schedule and budget are defined in DoW;

- due to design recommendations, e.g., a particular way of implementation, using particularhardware, software or business practice.

5) Project issues - the conditions under which the project will be done, presenting all factors thatcontribute to the success or failure of the project. Project issues include, e.g.:

- open issues - factors that are uncertain and might make significant difference to the product;

- analysis of off-the-shelf solutions - investigation of existing products, and adoption of state-of-the-art solutions;

- risks - risk analysis is being performed at the project level and is under control of the projectmanager;

- tasks - details of the life cycle and approach that will be used to deliver the product, for eachtask realization details are described in the DoW.

Within the three requirements groups identified in Section 2.1 (list item 4), the above aspects naturallyled to split the requirements into functional requirements and non functional requirements, some ofthem “being influenced” by the last three project-related aspects. Project influences will be made clearin the requirements description field when needed. All the considered requirement specification fieldsare described in Section 2.2.1.

2.2.1. Requirement specification fields

Requirements for the CHOReVOLUTION platform have been described in the form of tables (one foreach requirement). An example is given by the table below. The table consists of the following fields:

• ID - a unique identification of the requirement, which combines the name (a capital letters string),the type (either F or NF standing for functional or non functional, respectively), and the numberof the requirement. The name refers to the abbreviation of the group name it belongs to. Forexample, MOD-NF-1 uniquely identifies the non functional local requirement number 1 of thechoreography modeler. Referring to the platform overview given in Chapter 3, the following listreports all the group name abbreviations we use in this document:

Local requirements groups

- MOD: Choreography Modeler Requirement

- SYN: Synthesis Processor Requirement

- IDM: Identity Manager Requirement

- SINV: Service Inventory Requirement

- SEC: Security and Federation Server Requirements


- EE: Enactment Engine Requirement

- VSB: Evolution Service Bus Requirement

Integration requirements group

- INT: Integration Requirement

Development requirements group

- DEV: Development Requirement

ID MOD-NF-1 Priority VERY HIGHSource Consortium experience, CHOReOS Version 1.0Verification A Ownership WP2, WP6Description The choreography modeler MUST be able to support choreography specifica-

tions conforming to the BPMN 2.0 EMF meta model.Comment The BPMN 2.0 EMF meta model is the one used by the Eclipse BPMN2 Modeler

(https://www.eclipse.org/bpmn2-modeler/).This requirement has a dependency with the requirement MOD-F-1.

Rationale Conformance to the BPMN 2.0 EMF meta model ensures internal interchange-ability of the choreography specification among the CHOReVOLUTION toolboxcomponents, and external interchangeability with existing tools (external to thetoolbox) that use the same meta model.

Assessment The definition of the BPMN 2.0 EMF meta model induces verification rules thatcan be used by analysis tools, e.g., EMF Validation Framework (projects.eclipse.org/projects/modeling.emf.validation), to automaticallycheck the conformance of the choreography specification to the BPMN 2.0 EMFmeta model.

Table 2.1: CHOReVOLUTION Requirements Specification Template

• Priority - is determined by the importance of the requirement, according to the priorities definedin Section 2.2.2.

• Source - indicates the origin of a given requirement, e.g., DoW, scenarios (described in deliver-ables D4.1 [1] and D5.1 [2]) and consortium experience, including the previous experience comingfrom the CHOReOS project.

• Version - indicates the evolution of the requirement. Initially, all requirements have version 1.0.

• Verification - specifies the method that should be adopted for the verification of the requirementsas described in Section 2.2.3.

• Ownership - WPs and/or Tasks responsible for a given requirement, i.e., for its tracking, its real-ization during the project, but not necessarily responsible for its implementation (which, e.g., maybe carried on together with other partners).

• Description - provides explanation of the requirement (this is the main body of the requirement).

• Comment - additional, relevant information can be placed here, e.g., explanations, referencerequirements, general comments, examples, etc.

• Rationale (for requirement) - this field clearly states why this requirement has been specified andthus why it is needed. Examples of such rationale are:

- it is needed for the CHOReVOLUTION use cases, scenarios,

- it is desirable by the users of the platform,


https://www.eclipse.org/bpmn2-modeler/

projects.eclipse.org/projects/modeling.emf.validation


- it is needed because of existing legal constraints, standards and so on,

- it is needed because of its validity recognized in the context of the previous CHOReOSproject,

- it is needed because of a lack identified in the context of the previous CHOReOS project,e.g., the need of dynamic choreography adaptation and secure choreographies,

- because related existing solutions simply possess such feature/functionality,

- because, based on the partner’s experience, this requirements needs to be fulfilled,

- because of development constraints.

• Assessment - describe how the requirement should be verified according to the verificationmethodology specified in the Verification field.

2.2.2. Requirement terminology and prioritization

In CHOReVOLUTION, the description of requirements makes use of the keywords “MUST”, “MUSTNOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”,“MAY”, and “OPTIONAL”. These keywords are to be interpreted as described in the IETF RFC 21191 2.

• MUST: This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absoluterequirement of the specification.

• MUST NOT: This phrase, or the phrase “SHALL NOT”, means that the definition is an absoluteprohibition of the specification.

• SHOULD: This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasonsin particular circumstances to ignore a particular item, but the full implications must be understoodand carefully weighted before choosing a different course.

• SHOULD NOT: This phrase, or the phrase “NOT RECOMMENDED” mean that there may ex-ist valid reasons in particular circumstances when the particular behavior is acceptable or evenuseful, but the full implications should be understood and the case carefully weighted before im-plementing any behavior described with this label.

• MAY: This word, or the adjective “OPTIONAL”, means that an item is truly optional. One vendormay choose to include the item because a particular marketplace requires it or because the vendorfeels that it enhances the product while another vendor may omit the same item.

The priority of a requirement determines to what extent a given requirement should be fulfilled in thefinal solution. The considered requirements priority levels are:

- VERY LOW: Do if there is enough available time before the end of the project

- LOW: Nice to be delivered by the end of the project but not required

- MEDIUM: Important to be delivered by the end of the project

- HIGH: Essential to be delivered by the end of the project

- VERY HIGH: Fundamental pieces that must be done first so we can progress1https://www.ietf.org/2http://tools.ietf.org/html/rfc2119


https://www.ietf.org/

http://tools.ietf.org/html/rfc2119

2.2.3. Requirement verification

The four fundamental methodologies that CHOReVOLUTION considers to verify requirements are:

• Inspection (I) - visual verification to determine if the system meets a requirement. For CHOReV-OLUTION, software inspection means to visually examine the software artifacts constituting theCHOReVOLUTION platform, e.g., for screens that were requested, check for the fields neededfor data entry, verify that a given component exposes the interfaces needed for integration, verifythat the necessary buttons exist, etc.

• Analysis (A) - verification through the analytical evidences obtained by calculation, e.g., by mod-eling, simulation or forecasting. For example, concerning the requirements of the CHOReVOLU-TION platform reported in this document, analysis might concerns to complete a series of checksin which CHOReVOLUTION developers or choreography designers consider the characteristics ofinput parameters and initiate some platform functionalities; check that the platform functionalitiesreturn with no exceptions. Whereas, concerning the requirements of the CHOReVOLUTION sce-narios reported in the deliverables D4.1 [1] and D5.1 [2], this verification methods might concernthe analysis of the relationship between increasing numbers of service instances in a runningchoreography and the time it takes for the choreography to accomplish the tasks it has beendefined for; record the results to capture degradation of the running choreography and use thisinformation to predict at what point the choreography no longer meets the maximum allowabletime to return results as defined by the requirements.

• Demonstration (D) - verification of operational characteristics by observation of the CHOReV-OLUTION platform functioning or the CHOReVOLUTION scenarios execution, possibly withoutphysical measurement. For example, software demonstration may mean to enter required dataon a screen and select a button to return a specific report; ensure that the report is returned withthe needed type of data.

• Test (T) - verification of characteristics that are measurable and directly or indirectly reachable.For example, concerning the requirements of the CHOReVOLUTION platform, software testingmay mean to enter parameters and specify options for a platform function as stated in the pre-defined unit-test plan, launch the function and check if it returns the expected result. Whereas,concerning the requirements of the CHOReVOLUTION scenarios, software testing may mean toconfigure a trigger the scenario and check if it behaves according to an expected flow. The termTest is often used to include all four methods.


3 CHOReVOLUTION platform overview: a toolboxof well-integrated components

The distributed coordination of services within choreographies requires dynamic adaptation and evolu-tion of services due to continuous changes.

Changes include: (i) goal-changes, as users and involved business organizations may change theirneeds and preferences; as a consequence, the initial specification the choreography was synthesizedfor may change; and (ii) context-changes, as services may be substituted, and network conditions,available resources and so forth may change. Moreover, choreographies may be in operation for along time, and this makes it impractical to replace or retry the whole choreography process whenever achange occurs. Instead, CHOReVOLUTION choreographies will continuously evolve to meet new andmodified requirements and to support new technologies.

Figure 3.1 shows a high-level overview of the CHOReVOLUTION approach to the development ofchoreographies that span the whole choreography life cycle, from modeling, synthesis, to enactmentand execution on the cloud.

Figure 3.1: CHOReVOLUTION approach at a glance

As far as the CHOReVOLUTION platform is concerned, supporting the development of dynamicand secured choreographies first requires design-time methods for modelling (i) the participant ser-vices/things interfaces, (ii) their interaction protocols with respect to the other services/things involvedin the choreography, and (iii) a characterization of the choreography itself so as to enable reasoning onsecurity management. These methods should support the following abilities: choreography synthesis,adaptability, evolvability, security, and enactment and execution. To this respect, the CHOReVOLUTIONplatform enhances the CHOReOS results (and related methodologies and technologies) by employing,e.g., Enterprise Integration Patterns1 (EIP) for integrating mismatching message passing and inter-action protocols, and outcomes from standards bodies and consortia, such as WS-I2, for reliable and

1http://www.enterpriseintegrationpatterns.com/2http://www.ws-i.org/


http://www.enterpriseintegrationpatterns.com/

http://www.ws-i.org/

secure protocol integration and messaging delivery among services/things. Furthermore, the CHOReV-OLUTION platform comprises also novel and more powerful technologies that can be integrated withexisting ones. A high level security analysis was performed and described in Annex A. Depending onit, different components were added to the plateform.

In order to support the systematic realization of dynamic and secured choreographies, the platformallows for: (i) modeling the intended choreography both functionally by abstracting the behavior of theintended participant services and non-functionally by expressing possible service operational profilesthat, in particular, serve as support for multi-organization and multi-domain security management; (ii)synthesizing the specified choreography in a way that it is automated, adaptable, evolvable, and secure;(iii) executing the synthesized choreography on the Cloud as a distributed collaboration of both servicesand Things; and (iv) dynamically adapting the synthesized choreography to possible goal- and context-changes.

After providing an overview of the platform in the next section, a description of all the involved actors(Section 3.2) and a detailed description of the components constituting the platform (Section 3.3) willfollow.

3.1. CHOReVOLUTION platform overview

Figure 3.2 shows an high-level (logical) overview of the CHOReVOLUTION platform as a toolbox ofwell-integrated components. Indeed, in order to provide the reader with an overall picture, in the figurewe mix main platform components and related involved actors, further sketching the flow of the mainactivities to be followed for realizing the desired choreography. This overall picture will then serve asbaseline in deliverable D6.2 where we will precisely define the platform architecture and the way theusers has to use it. A detailed description of the constituent components is given in Section 3.3.

To the purpose of realizing the desired choreography, domain experts and choreography designerscooperate in order to produce a specification (Choreography Diagram) of the choreography. This is doneby using a suitable software tool for choreography modeling (Choreography Modeler). In more details,domain experts and choreography designers (i) set the business goal (for example, assist travelers fromarrival, to staying, to departure), (ii) identify the tasks and participants required to achieve the goal (forexample, reserving a taxi from the local taxi company, purchasing digital tickets at the train station, andperforming transactions through services based on near-field communication in a shop), and (iii) specifyhow participants must collaborate through a BPMN2 choreography diagram, further specifying possibleadaptation points and security rules through the additional modeling notations to be devised in WP2.

From the produced BPMN2 choreography specification and the specified additional models, and byusing the CHOReVOLUTION Synthesis Processor, choreography developers first select from a ServiceInventory those services that can act as suitable participants to play the roles of the specified choreogra-phy. Services are published in the service inventory by service providers, e.g., transportation companiesand airport retailers that have identified business opportunities in the domain of interest. The registryalso contains the registration of end users (e.g., a tourist) interested in exploiting/partecipating to thechoreography through, e.g., their mobile apps. Then, an automated choreography synthesis method isperformed. This method exploits model transformation and code synthesis techniques in order to derivea number of additional software entities:

• Coordination Delegates (CDs). When interposed between the services to be choreographed, CDsare able to coordinate the services interaction in a fully distributed way. The coordination logic isdistributed among a set of Coordination Models (CMs) that codify coordination information. Then,at run time, the CDs exchange the coordination information codified into the CMs to prevent un-desired interactions, i.e., those interactions that do not belong to the set of interactions allowed bythe choreography specification and can happen when the services collaborate in an uncontrolledway. The coordination logic implemented by the CDs may change at run time, e.g., because of


Figure 3.2: CHOReVOLUTION platform overview


changes in the choreography specification, hence triggering the dynamic reconfiguration of thechoreography.

• Adapters. By leveraging a sufficiently accurate notion of behavioral interface refinement, Adaptersenforce service-role similarity, hence binding the concrete services to the abstract roles definedby the choreography. The synthesized Adapters enforce exact similarity through complex datamappings and complex protocol mediation patterns. That is, in addition to pure coordinationthrough CDs, the CHOReVOLUTION platform enables run-time choreography evolution throughautomated protocol mediation and data-flow coordination, which means effectively coping withheterogeneous service interfaces by leveraging as much Enterprise Integration Patterns [3] andProtocol Mediation Patterns [4] as possible in a fully automatic way. For instance, Adapters areable to map message data types, or reorder/merge/split the sequence of operation calls and/orrelated I/O messages.

• Security Filters (Filters). Filters apply security-centric filtering policies that are specified by thedesigner(s) and domain expert(s). The latter dictates how to filter the interaction protocol of par-ticipant services with respect to different cross-boundary and multi-organization security require-ments. In others words, Filters can be synthesized to answer two main needs. The first one is tobe able to call a service depending on its authentication mechanism (credentials and protocol).The second one si to force different roles based on different application security contexts: thematching rule implemented by the filter can vary at run-time. Expected application contexts willimply dynamic adaptation and evolution without the need to re-synthesize the filters.

Beyond these additional software entities, a Concrete Choreography Specification is generated. Itcontains information that is required by the Enactment Engine to correctly perform the choreography de-ployment on the Cloud and related enactment process. That is, the Concrete Choreography Specifica-tion is an XML-based declarative description of the choreography that specifies the inter-dependenciesamong services, CDs, Adapters and Filters, and their locations.

In order to enable dynamic adaptation and cross-federation security enforceability at the servicelevel, leveraging the run-time support offered by the Enactment Engine, Adapters and Filters can beconfigured, monitored, controlled, and managed at run time by choreography operators and identity& security managers. Adapters and Filters are, then, supplied in order to manage both service-roleprotocol interoperability and security interoperability issues.

In particular a Filter provides a management interface to be queried:

• for the list of service attributes (proxifying information from Adapter/Service);

• for the global service status (monitoring);

• for a list of played roles (proxifying information from Adapter/Service);

• for a list of supported application contexts;

• to force a specific application context.

Moreover, Filters deal with security aspects enforcing the authorization control. They take care ofevaluating the existence of a valid “security token” or “federation”. The access is validated against the“federation server”. The result of an authorization process will affect the service application context(e.g., authenticated access, federated access, (un)authorized access).

Finally, the run-time support for running CDs, Adapters and Filters is provided by the CHOReVOLU-TION middleware developed in WP3 (see the description of the VSB component in Section 3.3).


3.2. CHOReVOLUTION actors

In this section we discuss all the actors involved in the CHOReVOLUTION context as shown in Fig-ure 3.3.

Figure 3.3: CHOReVOLUTION actors

Three main roles that can be played by CHOReVOLUTION actors have been identified.

• End User. In the more general sense, end users are the consumers/clients of the choreography-based applications realized by means of the CHOReVOLUTION platform. In particular, within theCHOReVOLUTION project, they concern all the people involved in the usage of the use casesdeveloped by WP4 and WP5, e.g., citizens, drivers, tourists, etc.

• Platform User. In the more general sense, platform users exploit the CHOReVOLUTION platformcomponents for realizing a specific choreography-based application. To this end, they shouldhave those minimal skills (e.g., modulo suitable training, developer and user guides, etc.) re-quired to understand the notion of choreography and the CHOReVOLUTION way for realizingchoreography-based applications. For instance, they may concern software architects, develop-ers, software engineers, domain experts, etc.

• Platform Developer. In the more general sense, platform developers are involved in the designand implementation of the platform components. In particular, developers from the CHOReVOLU-TION consortium, as well as third-party developers from the CHOReVOLUTION community fallinto this class of actors.

Platform users are, in turn, specialized as follows.

• Domain Expert. A domain expert has the responsibility of defining the business goal in orderto help, and cooperate with, the choreography designer in the production of the choreography


specification. Thus, the domain expert is in charge of identifying the business tasks that mustbe accomplished to achieve the goal, their flow(s), and related non functional preferences, e.g.,desired QoS, and business-level security policies.

• Choreography Designer. Starting from the description of the business goal informally set bythe domain expert, this actor has the responsibility of refining and transforming the business goalinto a BPMN2-based specification of the choreography. The latter concretizes the business goalinto a machine readable specification that is amenable of automated treatment by the SynthesisProcessor (see Figure 3.2). Moreover, to support choreography dynamic adaptation and securityenforcing, the designer can use the additional modeling notations to be defined in WP2 to spec-ify choreography adaptation points and security rules (see the description of the ChoreographyModeler component in Section 3.3).

• Choreography Developer. Being supported by the CHOReVOLUTION Synthesis Processor,the developer selects Thing-based and Business-oriented services that have been published byservice providers in the CHOReVOLUTION Service Inventory (see Section 3.3). These are theservices that are suitable for playing the choreography’s roles, as specified by the designer inthe BPMN2-based specification. Furthermore, by using the Synthesis Processor, the developerautomatically generates CDs, Adapters, and Filters, together with an XML-based specification ofthe choreography to be used for automatic deployment, enactment, and execution.

• Platform Administrator. By using a web console provided by the Identity Manager, the plat-form administrator is in charge of monitoring the global status of the platform, managing domainadministrator accounts and providing ordinary platform maintenance.

• Domain Administrator. By using the above web console, the domain administrator has theresponsibility of monitoring the status of a specific domain, managing end-user accounts (in termsof consumers, service providers and approvers) and retrieving compliance data for business. Thedomain administrator can also act as an “approver” to set which consumers and providers self-operations (such as self-registration and authorization requests) should be accepted or rejected.

• Security Manager. The role of the security manager is to collect security concerns for the differentconcrete services selected by the Synthesis Processor. After identifying these concerns, s/hehas to identify the necessary adaptations (limited to authentication mechanisms) and create themissing elements. That could be specific accounts or specific attributes for existing accounts.Another activity the security manager is involved in is to build, as much as possible, new circlesof trust with, for instance, identity federation.

• Choreography Operator. An operator is an actor who has the responsibility of launching thesynthesized choreography. The operator can also deploy, enable or disable a specific choreog-raphy. Besides this, by using the web console provided by the Identity Manager, an operator isresponsible for managing services and roles, monitoring services status, providing maintenance(maybe forcing application contexts) and taking care of the rescue management.

• Service Provider. A service provider is responsible for publishing services in the Service Inven-tory.

• Identity & Access Management Engineer. The Identity & Access Management Engineer isresponsible for identifying, designing, integrating and maintaining the identity and access man-agement platform for CHOReVOLUTION. This is a senior security engineer that has direct expe-rience in instituting and maintaining a centralized identity management and a data-centric accessmanagement system.


3.3. CHOReVOLUTION platform components

In this section, we describe the components of the CHOReVOLUTION platform.

• Choreography Modeler. It is in charge of integrating standard BPMN2 Choreography Diagrams,produced through the Eclispe BPMN2 Modeler3, with additional models based on new notations(to be defined in WP2) that allow the choreography designer to deal with dynamic adaptation andsecurity. In particular, suitable extensions of existing automata-based notations (e.g., LTSs, PNs,Interface Automata) are supported to express the abstract interaction behavior of a choreographyrole as a behavioral interface. These notations support defining and reasoning on a suitable no-tion of behavioral refinement, which serves to the Synthesis Processor to automatically enforceservice-role similarity, hence generating the Adapter required for binding a concrete service to achoreography role. Suitable model-to-model transformations are developed to automatically trans-late the BPMN2-based choreography model into the more formal analysis- and synthesis-specificmodels expressed by means of these notations. Furthermore, as mentioned above, the supportednotations allow the specification of the adaptation/evolution points of a choreography, i.e., varia-tions. Several behavioral views are associated to each choreography role. Each variation is aspecific role’s view associated to a specific service operational profile. The latter represents anabstract specification of a filtering policy that dictates how to filter all the possible role’s behaviorwith respect to different cross-boundary and multi-organization security requirements. The speci-fication of this logic is one of the inputs of the Synthesis Processor and it is used to automaticallygenerate Security Filters. The relation between a choreography role and the set of service oper-ational profiles associated to it represents the definition of an extended notion of service identitythat depends on specific application contexts, which is suitable for dynamic adaptation and se-curity enforcement purposes. The adopted notations should allow for characterizing applicationcontext in terms of identity and related attributes. This will enable the Identity Manager to syn-chronize application contexts and to enforce a binding between service and application contexts(including the setting of binding attributes coming from the notation).

• Synthesis Processor. It will be realized by a number of REST (REpresentational State Transfer)services that perform synthesis-time activities, and related model transformations, to automaticallygenerate CDs, Adapters and Filters. The processor takes as input the BPMN2-based choreogra-phy specification produced through the Choreography Modeler, and synthesizes an intermediatemodel that is independent from the specific choreography modeling notations. This means thatthe Synthesis Processor can be used in different practical contexts in which different modelingnotations might be adopted, provided that a dedicated M2M transformation is developed. Start-ing from this intermediate model, the Synthesis Processor extracts a characterization of eachchoreography participant (e.g., expected interaction protocol plus non functional attributes), andgenerates the set of CDs that are required to realized the distributed coordination logic imposedby the specified choreography. Having the above participant characterizations further allows forselecting suitable candidate services from the Service Inventory. After concrete services havebeen selected to act as choreography participants, the Synthesis Processor automatically gener-ates Adapters. Each Adapter bridges/mediates the concrete service interaction protocol in orderto exactly match the abstract participant interaction protocol. In other words, Adapters realize cor-rect service-role binding by solving possible interoperability issues (e.g., signature and protocolmismatches) between concrete services and abstract participants. Starting from the specifica-tions of the filtering policies, the Synthesis Processor produces Security Filters that locally wrapthe services. To achieve cross-federation security enforceability at the service level, the gen-erated Filters can be dynamically (re-)configured and managed by the Identity Manager. Theapproach is to employ Security Filters that manage security interoperability issues by applyingsecurity constraints, such as specific security policies, attributes used by service providers, and

3https://www.eclipse.org/bpmn2-modeler/



existing identity federation. The security filter will have to contain the specific request for Feder-ation Server to retrieve credentials allowing to access to the service. For example this requestcould take as input a username/password credential and to request to obtain a SAML token tocall the service.

Finally, the Synthesis Processor generates the Concrete Choreography Specification as an XML-based declarative description of the choreography that specifies the inter-dependencies amongservices, CDs, Adapters and Filters, and their locations.

An important consideration here is that CDs, Adapters, and Filters are generated only when strictlyneeded.

• Federation Server and Security Components. The Federation Server is in charge of solving, asmuch as possible, the different security interoperability issues. For that, its design is based on thefact that the different services, involved in choreographies, will need authentication mechanismsbut, today, a lot of standards exist. The three main capabilities of Federation Server are:

• adapting the different security mechanisms at protocol level. For instance, it may concernadapting Kerberos token to SAML token.

• providing credentials acceptable by the service Provider. Different accounts with their cre-dentials shall be store in Federation Server to be used to call a specific service.

• managing the access to the service by authorized or not the access depending on the au-thorization policies.

For these purposes, the Federation Server provides different components (not shown in Fig-ure 3.2). The first one is an STS (Security Token Service [6]) based on the WS-Trust definition.This component adapts the security protocol between a consumer and a provider. In CHOReV-OLUTION we focus on security token adaptation. The second one is an IDMapper that givescredentials to access a service. Consumer account information can be given as input and thiscomponent produces the corresponding account information that are accepted by the provider.The third component is an IdP (Identity Provider) that stores the accounts requested by the IDMap-per. IdP has to implement a part of the standards requested by the STS component (e.g., SAML,OpenID). The last one is the PDP (Policy Decision Point) in charge to authorized or not the accessto the service depending on the authorization policy deployed.

At design time, the security manager uses the Federation Server to create accounts and theirmapping for the different services, maintain different circle of trust between the different providers,and managed access policies.

At run time, the Federation Server is called by the Security Filters to request credentials to accessa service. In this case, the Federation Server provides accounts (with their related credentials)allowing to use the accessed service and check the authorizations.

• Service Inventory. The Service Inventory maintains services definition. As already introduced,it contains services published by providers (for example, transportation companies and airportretailers) that have identified business opportunities in the domain of interest. Services in theinventory are described by using service description languages that support automated serviceselection. For instance, service interfaces can be described using WSDL (Web Services Descrip-tion Language4). Service interaction protocols can be described using BPEL (Business ProcessExecution Language) or automata-based notations (such as LTSs, Petri Nets, etc.) that specifythe flow of messages exchanged with the environment. Additional notations can be also used tospecify non functional attributes of the described service behavior.

4www.w3.org/TR/wsdl


www.w3.org/TR/wsdl

The Service Inventory contains either the description of CHOReVOLUTION-enabled services orreferences to existing third-party services (e.g., Google services, Amazon services). The formerexposes suitable deployment and management interfaces. These are required by CHOReVOLU-TION to, e.g., interpose CDs among services, or to support dynamic adaptation through run-timeconfiguration and management of Adapters and Filters. Thus, CHOReVOLUTION-enabled ser-vices can be newly developed services or existing ones after being suitably wrapped/proxyfiedso to expose the above deployment and management interfaces. This allows to realize flexi-ble choreographies that dynamically bind both CHOReVOLUTION-enabled services and existingones, and compose them in a fully-distributed way while managing adaptation and security of theoverall choreography.

The inventory also contains the registration of end users interested in exploiting the choreographythrough their client applications, e.g., mobile apps.

As shown in Figure 3.2, the Service Inventory can be queried via both a REST interface, by theSynthesis Processor, and a web interface, by the involved actors.

• Identity Manager. Based on Apache Syncope5 and ConnId6 connector framework, the IdentityManager is responsible to manage users and services. In particular, the Identity Manager will beable to: (i) query the services/filters about supported application contexts (they span from stan-dard contexts supported by every service/filter to service specific contexts) and played roles; (ii)force a specific application context for a certain service (e.g., possibility to put a service in “main-tenance” or disable/enable services); (iii) query services about their global status (monitoring); (iv)query the service for their specific attributes. The Identity Manager interacts with the concrete ser-vices through the deployment and management interfaces described above (see the descriptionof the Service Inventory).

The Identity Manager provides a web console (a web application) exposing features for end-usersand administrators. This web console permits to: (i) manage service provider and consumer ac-counts; (ii) enroll new services and roles; (iii) manage service status including application contextforcing; (iv) manage services access authorizations; (v) approve end-user self-operations and re-quests; (vi) perform end-user self-registration and self-management. The ability of an individualuser to perform a specific task is regulated by given business roles. In this respect, the con-sole grant a Role Based ACcess (RBAC) to its features. Specifically, the web console interactswith the Identity Manager (business level) exploiting the RESTFul interface provided by this one.The access to these business services requires authentication. The web console provides user’scredentials at every request in order to perform any action on the Identity Manager. The Iden-tity Manager grants access to its services based on the internal business roles owned by therequesting user.

The Identity Manager exploits suitable connectors for identity management that allows the man-ager to: (i) manage/monitor concrete services; (ii) to manage running choreographies; (iii) syn-chronize the Service Inventory with the concrete choreography specification by interacting withthe Enactment Engine to access the information about services (e.g., services’ interdependen-cies and specific service attributes); (iv) provision service access policies.

The Identity Manager realizes the provisioning of managed services by means of a sub-component delegated to propagate/synchronize service and user data to/from external resourcessuch as concrete services, VSB, user credentials repository and so on. The default behavior ofthis provisioning sub-component (defined at platform design time) can be flexibly customized/spe-cialized by specifying work-flows given at platform configuration time.

• Enactment Engine. The Enactment Engine (EE) is the component responsible of the deploy-ment, configuration, update, and monitoring of all the virtual environments needed to execute the

5http://syncope.apache.org/6http://connid.tirasa.net/


http://syncope.apache.org/

http://connid.tirasa.net/

choreography’s services, therefore enacting the choreography itself and allowing for its evolution.

A virtual environment could be a virtual machine (VM) or a container (for example a Dockercontainer).

EE receives as input the Concrete Choreography specification, produced at the end of the Syn-thesis process. The Concrete Choreography specification, as already mentioned before, containsall the references to the actual location of all services that need to be deployed, together with thelocation of the respective Coordination delegates, Adapters and Security Filters, and their interdependencies. EE, through the REST APIs exposed by the underlying cloud infrastructure, willthen instantiate the needed virtual environments, taking into account the functional and non func-tional requirements set by the choreography, configuring them to host and execute the servicesand the related CHOReVOLUTION software artifacts (CDs, Adapters and Filters).

In CHOReVOLUTION, choreographies may evolve in time, automatically adapting themselvesto different contexts. When this happens, EE will be able to update a virtual environment toaccommodate the functional changes (e.g., a different service) and the non functional ones (e.g.:shorter response time). In the former case, EE will receive instructions on what are the servicesand/or the related CHOReVOLUTION software artifacts that need to be modified, and will updatedthe involved virtual environments with the new services and/or software artifacts; in the latter case,EE will modify the resources available to the affected virtual environments according to the newnon functional requirements. If necessary, a pool of equal virtual environments acting in parallelthrough a load balancer will be created.

Moreover, EE is also responsible of monitoring the instantiated virtual environments, reacting incase of service disruption.

• VSB. The purpose of the eVolution Service Bus (VSB) is to enable multi-protocol access to bothServices and Things. In particular, it enables interoperability among heterogeneous interactionparadigms of both domains, while conserving as much as possible their semantics. VSB com-prises: (i) an abstract bus specification that prescribes the high-level semantics of the commonbus protocol; and (ii) a concrete bus implementation that may rely on one or more existing proto-cols for implementing the common bus protocol. The abstract VSB semantics unifies the commonsemantics of multiple middleware paradigms. In particular, this includes the client-service (CS),publish-subscribe (PS), tuple space (TS) and data-streaming (STR) paradigms, which are amongthe most widely employed ones, with numerous related middleware platforms, such as SOAPand REST for client-service; MQTT for publish-subscribe; JavaSpaces for tuple space; and Web-Sockets for data-streaming. Services and Things relying on different middleware platforms canbe plugged onto the VSB Binding Components (BCs), which adapt their native middleware to thecommon bus protocol.

VSB BCs are designed to be easily extensible to support new middleware platforms. A BC isresponsible for the transformation of messages that run through the service bus. According tothe Internet of Things specifics, VSB BCs should handle dynamic environments, resource con-straints, data orientation, etc. VSB will be flexible, lightweight, and efficient in terms of messagetransmission speed and bandwidth consumption. To best adapt to different cases of interconnec-tion between Services and Things, VSB will be able to use and switch between several protocols(e.g., REST and Web Services for Services, CoAP for Things) employed as the common busprotocol.


4 Local requirements

ID MOD-F-1 Priority HIGHSource Consortium experience, DoW Version 1.0Verification A,I Ownership WP2Description The Choreography Modeler MUST support the additional notations to be defined

in WP2 in order to specify adaptation points and security rules at the choreogra-phy level.

Comment A detailed description of this requirements will be provided as soon as moretechnical details will be clarified in WP2 for what concerns the specific modelingnotations that will be defined.This requirement has a dependency with the requirement MOD-F-2.

Rationale A specification of possible adaption points and security rules of the choreographyis required to synthesize Adapters and Security Filters.

Assessment Analysis and inspection methods to be used for assessing this requirement willbe defined as soon as the specific modeling notations will be defined.

ID MOD-F-2 Priority HIGHSource Consortium experience, DoW Version 1.0Verification A Ownership WP2Description The models to specify adaptation points and security rules at the choreography

level supported by the Choreography Modeler MUST conform to a dedicatedmeta model (to be defined in WP2) that will include the BPMN 2.0 EMF metamodel.

Comment This requirement has a dependency with the requirements MOD-F-1 and SYN-F-1.Moreover, since in CHOReVOLUTION BPMN 2.0 Choreography Diagrams willbe specified by using the Eclipse BPMN2 Modeler (https://www.eclipse.org/bpmn2-modeler/), and hence they will be conforming to the BPMN 2.0EMF meta model, this requirement have a dependency also with the requirementMOD-NF-1.

Rationale The specification of adaptation points and security rules is done at the level of thechoreography specification, and hence they MUST be amenable of integrationwith BPMN 2.0 Choreography Diagrams. As a consequence, the related mod-eling notations have the necessity to explicitly refer to actual elements of BPMN2.0 Choreography Diagrams, and to implicitly refer to conceptual elements of theBPMN 2.0 EMF meta model.

Assessment Leveraging the BPMN 2.0 EMF meta model, verification rules can be usedby analysis tools, e.g., EMF Validation Framework (projects.eclipse.org/projects/modeling.emf.validation), to automatically check con-formance with the BPMN 2.0 EMF meta model.






ID SYN-F-1 Priority VERY HIGHSource Consortium experience, CHOReOS Version 1.0Verification T Ownership WP2, WP3Description The Synthesis Processor MUST be able to take as input a BPMN2-based chore-

ography specification, i.e., a BPMN 2.0 Choreography Diagram, and additionalmodels defined by using the notations to be devised in WP2 for specifying chore-ography adaption points and security rules.

Comment This requirement has a dependency with the requirements MOD-F-1, MOD-F-2,SYN-F-2, SYN-F-3, SYN-F-4, SYN-F-5, SYN-F-6, and MOD-NF-1.

Rationale BPMN 2.0 Choreography Diagrams are the standard de facto for specifyingchoreography-based service-compositions. In order to generate CDs, Adapters,and Security Filters, the Synthesis Processor takes as input the BPMN 2.0Choreography Diagram and the additional models, and applies to them modeltransformations based on (conforming to) the BPMN 2.0 EMF meta model.

Assessment Test cases will be generated to assess that no conformance errors will be raisedby exploiting, e.g., the EMF Validation Framework (projects.eclipse.org/projects/modeling.emf.validation).

ID SYN-F-2 Priority VERY HIGHSource Consortium experience, CHOReOS Version 1.0Verification T Ownership WP2Description The Synthesis Processor MUST implement a model transformation to extract a

characterization of each choreography participant in order to select candidateservices from the Service Inventory for each participants.

CommentRationale The projection of the BPMN 2.0 choreography given as input into the participants

involved in the choreography is required to extract the expected interaction proto-col and non functional attributes of each single participant. Having the participantcharacterization further allows for selecting suitable candidate services (i.e., con-crete services) from the Service Inventory to be bound to the choreography.

Assessment Test cases will be generated to verify if the extracted characterization of the par-ticipants is the expected one. For what concerns testing the correctness of thederived participant interaction protocol, the execution of the test cases can beautomated by “navigating” the generated interaction protocol of the participantand simulating it against the choreography to check if the flows traversed by theparticipant interaction protocol are allowed by the choreography.




ID SYN-F-3 Priority VERY HIGHSource Consortium experience, CHOReOS Version 1.0Verification T Ownership WP2Description The Synthesis Processor MUST be able to generate a set of Coordination Del-

egates as Web services that proxify the concrete services participating to thechoreography.

CommentRationale Coordination Delegates (CDs) implement a distributed coordination algorithm

and are required to realized the distributed coordination logic imposed by thespecific choreography. CDs need to be interposed between the services to bechoreographed so as to coordinate the services interaction in a fully distributedway by preventing undesired interactions, i.e., those interactions that are not al-lowed by the choreography specification given as input.

Assessment Several test cases will be defined to check if the number of generated CDs isthe expected one with respect to the number of participants and their interactionroles in the choreography (i.e., consumer, provider, prosumer).Moreover, other test cases will be defined to check the correctness of the dis-tributed coordination algorithm by stressing specific control-flow constructs ofBPMN 2.0, e.g., sequential flow, conditional branch, fork and join.

ID SYN-F-4 Priority VERY HIGHSource Consortium experience, DoW Version 1.0Verification T Ownership WP2Description The Synthesis Processor MUST be able to generate a set of Adapters as Web

services that proxify the Coordination Delegates (CDs).CommentRationale Adapters are required to bridges/mediates the concrete service interaction proto-

col in order to exactly match the abstract participant interaction protocol as coor-dinated by the CDs. To this end, Adapters enforce service-role similarity betweenconcrete services and abstract participant. Service-role similarity is required tosolve possible interoperability issues.

Assessment Several test cases will be defined to check if the number of generated Adaptersis the expected one with respect to the number of participants whose interfacesand interaction protocol does not match the ones of the concrete services.Moreover, other test cases will be defined to check the correctness of the adapta-tion logic realized by the generated Adapters by stressing well-known enterpriseintegration problems, and related enterprise integration patterns [3].


ID SYN-F-5 Priority VERY HIGHSource Consortium experience, DoW Version 1.0Verification T Ownership WP2Description The Synthesis Processor MUST be able to generate a set of Security FiltersComment This requirement has a dependency with the requirements FED-F-1, FED-F-2,

FED-F-3, FED-F-4, FED-F-5.Rationale The Security Filters are required in order to manage security interoperability

issues by applying security constraints and security attributes used by serviceproviders, and existing identity federation. These Filters hence dictates how tofilter the interaction protocol of participant services with respect to different cross-boundary and multi-organization security requirements

Assessment Test cases will be defined in conjunction with the requirements FED-F-1, FED-F-2, FED-F-3, FED-F-4, FED-F-5.

ID SYN-F-6 Priority VERY HIGHSource Consortium experience, CHOReOS Version 1.0Verification T Ownership WP2Description The Synthesis Processor MUST be able to generate the Concrete Choreography

Specification, which is an XML-based declarative description of the choreographythat specifies the inter-dependencies among concrete services participating tochoreography, Coordination Delegates, Adapters and Security Filters, and theirlocations.

Comment This requirement has a dependency with the requirement INT-F-1.Rationale The generation of the Concrete Choreography Specification is needed since it

serves to communicate to the Enactment Engine (EE) those choreography de-ployment information. It contains information that is required by the EE to cor-rectly perform the choreography deployment on the Cloud and related enactmentprocess.

Assessment The testing activity to check the correctness of the synthesis generation processwill be automated by implementing an XML parser that compare the all the inter-dependencies codified in the XML-based concrete choreography specificationwith respect to the BPMN 2.0 choreography given as input.


ID SYN-F-7 Priority HIGHSource Consortium experience, CHOReOS Version 1.0Verification I, T Ownership WP2Description A set of Eclipse plugins MUST be implemented in order to suitably interact with

all the functionalities offered by the Synthesis Processor exposed through RESTAPI.

Comment This requirement has a dependency with the requirements SYN-F-1, SYN-F-2,SYN-F-3, SYN-F-4, SYN-F-5, SYN-F-6, and INT-F-1.

Rationale The set of Eclipse plugins will offer a GUI that, through a wizard process, guidesthe CHOReVOLUTION platform user while suitably interacting (i.e., according topredefined sequential steps) with the REST API offered by the Synthesis Proces-sor. Moreover, the plugins will offer bespoke features to graphically edit, visualize,and save the artifacts generated during the synthesis process (e.g., CoordinationDelegates, Adapters, Security Filters, and the concrete choreography specifica-tion).

Assessment Visual inspection will be performed in order to verify if all the needed GUI con-trols are in place and if the generated artifacts are correctly manipulated, andvisualized. Moreover, the correct interaction with the REST API will be tested byfollowing the verification procedure of requirements SYN-F-1, SYN-F-2, SYN-F-3, SYN-F-4, SYN-F-5, SYN-F-6.

ID IDM-F-1 Priority VERY HIGHSource Consortium experience Version 1.0Verification I,T Ownership WP6, T2.1Description The Identity Manager platform MUST provide a web console.Comment This requirement has a dependency with the requirements IDM-F-2, IDM-F-3,

IDM-F-4, IDM-F-5, IDM-F-10.Rationale A web console offering an easily accessible GUI to permit end-user self-

management, and to monitor and manage concrete services and running chore-ographies is mandatory for exposing the features offered by the Identity Managerto End Users and Administrators.

Assessment Visual verification to determine if the web console offers GUI controls to: (i) man-age accounts for Service Providers and consumers; (ii) enroll new services androles; (iii) manage service status and application context; (iv) manage servicesaccess authorizations; (v) approve end-user self-operations and requests; (vi)perform end-user self-registration and self-management.Furthermore, for each one of the above features, unit testing will be performedbeing driven by aptly predefined test cases.


ID IDM-F-2 Priority HIGHSource Consortium experience, DoW Version 1.0Verification T Ownership WP6, T2.1Description The Identity Manager MUST be able to manage the life cycle of End Users and

the running choreography they are involved in. The platform MUST permit tomanage different profile for different kind of end-users.

Comment This requirement has dependencies with the requirements IDM-F-1, IDM-F-12and INT-F-5.

Rationale Managing the life cycle of End Users and choreography is required for userscredentials and service access policy management.Managing this information in a centralized way will improve security by leveragingrole attestation and security policy compliance.

Assessment JUnit framework (http://junit.org/) will be used to implement unit and in-tegration test cases to verify this requirement.The specific aim of these tests is to verify CRUD (Create, Read, Update, Delete)operations against each kind of End User. The propagation of credentials andaccess policies toward Federation Server (PIP/PRP) sub-components will be au-tomatically verified during these tests.

ID IDM-F-3 Priority HIGHSource Consortium experience Version 1.0Verification D Ownership WP6, T2.1Description The Identity Manager MUST permit Service Providers and End Users to register

to the CHOReVOLUTION platform (self-registration).It MUST be possible to specify a customizable registration approval work-flow inorder to delegate individuals to approve or reject registration requests.Self-registration and self-management operations MUST NOT be permitted toPlatform Administrators: only End Users, consumer applications, and ServiceProviders.

Comment End users, applications and Service Providers will have different profiles.End users and Service Providers will perform self-operations via web console.Consumer applications will perform self-registration via REST interface.This requirement has a dependency with the requirement IDM-F-1.

Rationale To encourage the adoption by Service Providers and End Users, the registrationhas to be as much simple as possible. Self-operations providing is required inthis sense.For security reasons, the possibility to specify different approval work-flows fordifferent users is needed to keep provisioning under the control of delegatedindividuals.

Assessment Verify the requirements performing different self-registrations for each kind of EndUser.


http://junit.org/

ID IDM-F-4 Priority VERY HIGHSource Consortium experience Version 1.0Verification D Ownership WP6, T2.1Description The Identity Manager MUST permit Service Provider to register/publish services.

The association to an existing service role is mandatory.Comment A service in the Identity Manager is not a choreography concrete service. It can

be mapped or not on a concrete one. If mapped, than a Choreography Operatorwill be able to affect the status of the concrete service.This requirement has dependencies with the requirements IDM-F-1 and SINV-F-1.

Rationale Since Service Providers have the ownership of services to be deployed into theService Inventory, it is necessary to provide them with the possibility to directlyregister, publish and manage services.

Assessment Verify the requirement logging into the web console with Service Provider cre-dentials and performing the registration of new services.Login with a different user and verify that service registration is not permitted forthat user.

ID IDM-F-5 Priority HIGHSource Consortium experience Version 1.0Verification D Ownership WP6, T2.1Description The Identity Manager MUST permit to

• enable/disable services

• force an application context for a service

• retrieve all the application contexts supported by a service

• retrieve roles played by a service

• retrieve service profile attributes including endpoints and WSDL

• retrieve global service status

• update a service into the Service Inventory

• remove a service from the Service Inventory

Service removal from Service Inventory MAY result into a concrete service dis-abling.

Comment The Choreography Operator can affect concrete service status if and only if amapping between this service and one registered into the Service Inventory ex-ists. This requirement has dependencies with the requirements IDM-F-1, IDM-F-11, IDM-F-12 and SINV-F-1.

Rationale Advanced and centralized service (concrete or not) control is required for runningchoreographies monitoring and performing rescue management.

Assessment Verify the requirement logging into the web console and performing all availableservice management operations.Login with a different user and verify that no service management operation ispermitted.


ID IDM-F-6 Priority HIGHSource Consortium experience Version 1.0Verification D Ownership WP6, T2.1Description The Identity Manager MUST synchronize service profiles published into the Ser-

vice Inventory with Concrete Choreography Specifications as deployed by theEnactment Engine (EE).As a result of a choreography deployment completion notification coming fromthe EE, the Identity Manager MUST ask for a fully completed list of deployedservices to the EE in order to upgrade all the information stored into the ServiceInventory.

Comment At run-time, the Identity Manager retrieves information on the status of servicesby querying the EE. This requirement has dependencies with the requirementsIDM-F-12 and SINV-F-1, INT-F-3 and INT-F-5.

Rationale Service profiles into the Service Inventory and access policies into the Federa-tion Server (PIP/PRP) sub-components must be kept synchronized with concreteservice profiles (especially in terms of status) during choreography execution.This requirement is needed for granting service data consistency into ServiceInventory and Federation Server (PIP/PRP) sub-components.

Assessment Verify the requirements performing a new deployment: check for notificationevent from the Enactment Engine and the resulting synchronization process firedby the Identity Manager.

ID IDM-F-7 Priority HIGHSource Consortium experience Version 1.0Verification D Ownership WP6, T2.1Description End-user credentials verification service MUST be available.CommentRationale It could be required by the Federation Server.Assessment Verify the requirements performing several credentials verifications.

ID IDM-F-8 Priority VERY HIGHSource Consortium experience Version 1.0Verification T Ownership WP6, T2.1Description Apache Syncope MUST be extended to support “ANY” object provisioning.CommentRationale It is needed because services, service roles, contexts and users have to be man-

aged by Apache Syncope.Assessment JUnit framework (http://junit.org/) will be used to implement unit and in-

tegration test cases to verify this requirement.The specific aim of these tests is to verify CRUD (Create, Read, Update, Delete)operations against custom object identities different from users and groups.


http://junit.org/

ID IDM-F-9 Priority VERY HIGHSource Consortium experience Version 1.0Verification T Ownership WP6, T2.1Description Apache Syncope MUST be extended to support multi-tenancy.CommentRationale It is needed because a multi domain platform is required.Assessment JUnit framework (http://junit.org/) will be used to implement unit and in-

tegration test cases to verify this requirement.The specific aim of these tests is to verify CRUD (Create, Read, Update, Delete)operations against object identities, including users and groups, into differentpre-configured domains.

ID IDM-F-10 Priority VERY HIGHSource Consortium experience Version 1.0Verification I, D Ownership WP6, T2.1Description The Web Console MUST provide an administration interface to be used by Plat-

form/Domain Administrators to:

• manage platform configuration

• create and update Choreography Operator profiles

• generate reports

• monitor the global status of the platform

Administration console features MUST be available for pre-authorized users only.Comment Different users can have different capabilities.

This requirement has dependencies with the requirements IDM-F-1 and SINV-F-1.

Rationale It is required to manage the whole platform.Assessment Visual inspection will be performed in order to verify whether the administration

web interface is in place or not. Then, based on user capabilities, a demonstra-tion will check whether it is possible to exploit all the features described by thisrequirements.

ID IDM-F-11 Priority VERY HIGHSource Consortium experience Version 1.0Verification T Ownership WP6, T2.1Description A ConnId connector MUST be developed for enabling suitable interaction be-

tween the Identity Manager and the choreographed services.CommentRationale It is required to affect and retrieve concrete service status.Assessment JUnit framework (http://junit.org/) will be used to implement unit and in-

tegration test cases to verify this requirement.The specific aim of these tests is to verify operations against concrete chore-ographed services like as status retrieval, enable/disable and context forcing.


http://junit.org/

http://junit.org/

ID IDM-F-12 Priority VERY HIGHSource Consortium experience Version 1.0Verification T Ownership WP6, T2.1Description A ConnId connector MUST be developed for enabling suitable interaction be-

tween the Identity Manager and the Enactment Engine.CommentRationale It is required both (i) to synchronize the Service Inventory with a Concrete Chore-

ography Specification deployed by the Enactment Engine, and (ii) to managerunning choreographies.

Assessment JUnit framework (http://junit.org/) will be used to implement unit and in-tegration test cases to verify this requirement.The specific aim of these tests is to verify operations against the EnactmentEngine like as concrete choreography specification retrieval and enable/disablerunning choreographies.

ID IDM-F-13 Priority VERY HIGHSource Consortium experience Version 1.0Verification T Ownership WP6, T2.1Description It MUST be possible to specify a different provisioning work-flow based on the

managed identity type (user, service, an so on).Comment This requirement has dependency with the requirement IDM-F-8.Rationale It is required to differentiate provisioning actions per identity type.Assessment JUnit framework (http://junit.org/) will be used to implement unit and in-

tegration test cases to verify this requirement.The specific aim of these tests is to verify every pre-defined user provisioningwork-flow by performing several CRUD (Create, Read, Update and Delete) oper-ations against different kind of users.

ID SINV-F-1 Priority VERY HIGHSource Consortium experience Version 1.0Verification T Ownership WP6, T2.1Description The Service Inventory MUST contain the description of CHOReVOLUTION-

enabled services or references to existing third-party services. The Service In-ventory MUST offer functionalities to create, update, read and list service profiles.Every service profile managed by the Service Inventory MUST be described bygeneral profile attributes such as service name, service roles, informal textualservice description, technical service description (e.g., WSDL for Web Services),service endpoints (including management interface endpoints provided by theSecurity Filter).

Comment This requirement has dependencies with the requirements IDM-F-8, IDM-F-11.Rationale It is required by service publishing, service selection, service role binding and

client application enrolments.Assessment JUnit framework (http://junit.org/) will be used to implement unit test

cases to verify this requirement.The specific aim of these tests is to verify create, read, update and list operationsagainst the Service Inventory. Every read/list operation has to be verified againstthe expected attributes to be returned.


http://junit.org/

http://junit.org/

http://junit.org/

ID SEC-F-01 Priority HIGHSource Consortium experience Version 1.0Verification T Ownership WP3, T3.2Description In the case of authentication token, the Federation server MUST offer a function

to transform this token in an usable token by the service involved in the choreog-raphy.

Comment For example to transform SAML token in Kerberos token.Rationale The legacy services are using hetergeneous authentication mechanism and it is

not possible to modify them.Assessment A test tool has to be used to validate the transformation.

ID SEC-F-02 Priority HIGHSource Consortium experience Version 1.0Verification D Ownership WP3, T3.2Description The Federation server MUST offer to Security manager, at design time, a way to

discover the different security mechanism requested by the Services provider byusing WSDL.

CommentRationale In order to anticipate the security constraints (authentication issues) of services

called inside choreographies, the Security Manager has to know them and totake them into account.

Assessment By using, at design time, the Federation Server and by checking the informationprovided in the different WSDL.

ID SEC-F-03 Priority HIGHSource Consortium experience Version 1.0Verification T Ownership WP3, T3.2Description Using the Federation server, the Security Manager MUST be able to create man-

ually accounts with Credential for services involved in choreographies and re-questing authentication.

CommentRationale For external services, specific accounts have to bo created manually by Security

Manager to access to the services.Assessment The accounts creations will be demonstrated by building the use cases.


ID SEC-F-04 Priority HIGHSource Consortium experience Version 1.0Verification T Ownership WP3, T3.2Description Using the Federation server, the Security Manager MUST be able to associate

different accounts; That means that, for an account given as input, the Federationserver MUST associate another account usable by the called service.

Comment This requirement has a dependency with the requirements SEC-F-2 and SEC-F-3.

Rationale When a service wants to call another service, it can have an initial account butthis account is not acceptable by the called service. This capability will allowto find a new account depending on the initial one and to use it for calling theservice.

Assessment The accounts mapping will be demonstrated by building the use cases.

ID SEC-F-05 Priority HIGHSource Consortium experience Version 1.0Verification T Ownership WP3, T3.2Description During the execution of the choregraphies (runtime), the Federation server MUST

be able to provide the necessary account for the called service.Comment This requirement has a dependency with the requirements SEC-F-4.Rationale To avoid security issues (authentication issues) during the choreographies exe-

cution, a way has to be proposed to fix them.Assessment The way to fix these security issues will be demonstrated by running the use

cases.

ID SEC-F-06 Priority HIGHSource Consortium experience Version 1.0Verification T Ownership WP3, T3.2Description The Security Filter MUST provide to Federation Server the account available

for the calling service (if existing) with the credential and MUST receive conse-quently the account to be used with the called service.

Comment This requirement has a dependency with the requirements SEC-F-4.Rationale Security Filters will intercept all interactions between calling services and called

services. The security interoperability has to be design in this stage.Assessment Different “test” choreographies will be used to assess this requirement.

ID SEC-F-07 Priority HIGHSource Consortium experience Version 1.0Verification T Ownership WP3, T3.2Description If a service uses specific security token, the Security Filter MUST provide to

Federation Server the existing security token available (if existing) and MUSTreceive consequently the new token to be used with the called service.

Comment This requirement has a dependency with the requirements SEC-F-1.Rationale The different services provider can use different SSO mechanisms.Assessment Different “test” choreographies will be used to assess this requirement.


ID SEC-NF-01 Priority HIGHSource Security analysis Version 1.0Verification A Ownership WP6, T6.1Description The availability of CHOReVOLUTION platform MUST be 99.9CommentRationale CHOReVOLUTION platform has to propose a high availability mechanism in or-

der to guarantee business services. This mechanism will be mainly implementedthrough Cloud architecture but the different parts developed in CHOReVOLU-TION (CD, Security Filter, adapters, ) have to be compliant with this architecture.

Assessment Analysis of architecture description.

ID EE-F-1 Priority VERY HIGHSource DoW Version 1.0Verification D Ownership WP3, T3.3Description The EE MUST provide all the necessary features to enable the deployment of

a synthesized choreography over a cloud based infrastructural layer. This im-plies the capabilities to configure physical (e.g. VM) and logical (e.g. service in-stances) resources based on the concrete choreography description provided bythe synthesis processor. Furthermore, the EE must be able to provide runtime-level interfaces to allow requests for additional resources dynamically upon needor upon capacity exhaustion.

Comment This requirement has a strong dependency from SYN-F-6, as the EE will per-form the enactment based entirely on the concrete choreography specificationprovided by the synthesis processor. Further information regarding security con-figuration might come from the Identity Manager. The EE will communicate atruntime with the deployed choreography (for run-time scalability commands) us-ing a RESTful API. A relation with SINV-F-1 is also required, as the EE will resortto the service inventory to get the specification of service templates to be de-ployed.

Rationale The choreography deployment is the main role of the EE, supporting the deploy-ment step of the choreography realization. The capabilities to request a runtime-based interaction with the cloud layer must furthermore ensure an elastic andcontinuously adapting cloud usage.

Assessment Launch the process of choreography enactment and verify that the choreographyis correctly executed (i.e., all the choreography’s services are up and running inthe underlying cloud infrastructure, and they are communicating according to thechoreography model).


ID EE-F-2 Priority MEDIUMSource Consortium experience Version 1.0Verification D Ownership WP3, T3.3Description The Enactment Engine (EE) MUST be able to shutdown a running choreography,

freeing all the used resources.Comment The EE expects to receive the shutdown choreography commend via a RESTful

call to the choreography control API. The shutdown command shall be subject tospecific levels of authorization interacting with the IDM component

Rationale The choreography shutdown should provide two degrees of action: shutdownand release. In shutdown mode the choreography components are physicallyshut down but not removed from the cloud infrastructure. In shutdown mode,a choreography can be resumed or restarted without re-deployment. In the re-lease mode all the components are removed from the cloud and, as such, It isnecessary to ensure that at the end of a choreographys lifecycle the occupiedresources are freed. In release mode the choreography is no more available,and the EE will expect a new deployment request from the synthesis processor.In cloud computing terms the shutdown mode equals to a shutdown of a VM, butnot its deletion from disk (this typically implies continuing the payment of servicefees, but at a lower price).

Assessment Starting form a running choreography, launch the shutdown process and checkthat all the occupied resources are free.

ID EE-F-3 Priority LOWSource Consortium experience Version 1.0Verification D Ownership WP3, T3.3Description The EE MUST be able to pause a choreography execution.Comment As in EE-F-2, this is a runtime feature of the EE, accessed through the EE REST-

ful API. The pause command does NOT shutdown the choreography, but it rathertakes a running snapshot and pauses the whole system. This is possible ONLYif the underlying cloud layer allows this action technically.

Rationale This feature will be useful during system troubleshooting as it allows the opera-tors to shortly stop the running choreography to analyze its coming data.

Assessment Having a running choreography, launch the pausing process and check, usingcommon networking software utilities, that the choreography’s services do notexchange messages between themselves anymore.


ID EE-F-4 Priority LOWSource Consortium experience Version 1.0Verification D Ownership WP3, T3.3Description The EE MUST be able to resume a previously stopped choreography.Comment This command is the counterpart of EE-F-2 and EE-F-3 as it allows the resume

of a shutdown or paused choreography. Only who issued the pause shall be ableto resume the choreography. Permissions for running these commands MUSTbe part of the identity profiles handled by the IDM.

Rationale This feature will be useful during system troubleshooting.Assessment Having a paused choreography, launch the resuming process and check, using

common networking software utilities, that the choreography’s services do ex-change messages between themselves again.

ID EE-F-5 Priority HIGHSource Consortium experience Version 1.0Verification T Ownership WP3, T3.3Description The EE MUST monitor the generated virtual environments at run time.Comment The EE Will monitor the running status of the system based on directly con-

trollable basic infrastructural variables (e.g. network reachability) and based onhealth checks (URLs) that MAY be defined at deployment time in the concretechoreography description (not a mandatory feature). This requirement thus hasa light dependency from SYN-F-6 as well. The EE will look for information aboutthe test URL for the deployed services, if present in the concrete choreogra-phy description; the test URL, if present in the description document and conse-quently implemented in the choreography service, SHALL provide a meaningfulresponse in XML format containing health status information

Rationale To be able to react to events happening at the underlying cloud infrastructure,the EE has to monitor the requested resources. The monitoring MAY span to theapplication layer as well, if testing URLs are implemented in the choreographyservices.

Assessment Collect, aggregate and store resource usage data (i.e., CPU, RAM, disk) comingfrom the underlying infrastructure. Compare the collected data with user-definedthresholds specified at synthesis time and generate triggers for the applicationlayer to allow for scalability decisions.


ID EE-F-6 Priority HIGHSource Consortium experience Version 1.0Verification T Ownership WP3, T3.3Description The EE SHOULD monitor resource availability.Comment The EE Will monitor the system capacity while the choreography is running. The

EE MUST be able to generate capacity alerts in specific log files to allow the restof the choreography components to take action based on these events. EE-F-7depends on this requirement to automatically handle capacity events.

Rationale The EE should know which resources are available in order to use them to enactchoreographies. Another option is to rely on the underlying infrastructure APIsthat will refuse EE’s requests in case there are no resources available: EE willthen handle this “exception” rolling back the enactment process.

Assessment Collect data about resource availability of the underlying infrastructure, periodi-cally quering the infrastructure’s controller. Prior to performing a new deploymentor a scaling operation, check the actual presence of enough resources to performthe operation.

ID EE-F-7 Priority VERY HIGHSource DoW Version 1.0Verification T Ownership WP3, T3.3Description The EE MUST be able to dinamically reconfigure the virtual environments where

the choreography’s services are running, performing vertical (more hardware re-sources) or horizontal (multiple identical instances with a load balancer on top ofthem) scaling.

Comment This requirement depends on indications provided by the synthesis processorat design and deployment time (SYN-F-6). The EE expects to have indicationsabout the auto-scaling capabilities of the choreography services. Scalability fea-tures might act vertically (if allowed by the underlying cloud layer) or horizontally,by auto deploying load balancers in front of multiple instances of a service. Re-questing a scale-up or scale-across MUST also allowed via the RESTful API.

Rationale In CHOReVOLUTION, choreographies will adapt to dynamically changing con-texts: EE therefore must react to mutated non-functional requirements (i.e., avail-ability and response time) of choreography’s services.

Assessment Starting from a running choreography, react to scalability events (either requestedby the application layer or triggered by predefined thresholds) by automaticallyassigning more or less resources following a vertical or horizontal scaling ap-proach depending on the component requesting the change.

ID EE-F-8 Priority VERY HIGHSource Consortium experience Version 1.0Verification I Ownership WP3, T3.3Description The EE MUST expose a user interface for the Choreography Operator.Comment Given EE’s nature of an infrastructural component, the user interface will be in

the form of a CLI (Command Line Interface).Rationale The Choreography Operator needs a way to interact with EE.Assessment Confirm the presence of a user interface.


ID EE-F-9 Priority VERY HIGHSource DoW Version 1.0Verification T Ownership WP6, T6.2Description The EE SHALL become an Eclipse plugin.CommentRationale This requirement derives from the CHOReVOLUTION goal of creating a user-

s/developers community.Assessment A manual test must be performed in order to ensure that the plugin is actually

compliant with Eclipse, and that the installation and configuration process can beperformed smoothly on a standard Eclipse installation.

ID VSB-F-1 Priority VERY HIGHSource Consortium experience, DoW Version 1.0Verification A, T Ownership WP3, T3.1Description The VSB MUST support interoperability (bridging) among heterogeneous Ser-

vices and Things by protocol conversion at middleware level to and from a com-mon bus protocol.

Comment This requirement has a dependency with the requirements SYN-F-6, VSB-F-2.Rationale Middleware protocol interoperability (bridging) for supporting choreographies of

heterogeneous Services and Things is the principal purpose of VSB. Employ-ment of an intermediate bus protocol applies the well-known ESB paradigm.

Assessment Analysis relying on formal models of the middleware protocol connectors andprotocol converters. Software testing that includes: specifying options for eachService/Thing and its middleware protocol as stated in the predefined unit-testplan; launching the Services/Things; and checking if the expected results of theunit-test are effectively returned.

ID VSB-F-2 Priority VERY HIGHSource Consortium experience Version 1.0Verification T Ownership WP3, T3.1Description The VSB MUST support a common interface description language and datatype

system (related to the common bus protocol) for the choreography peers (Ser-vices/Things) and other application-level components deployed on the bus.

Comment WSDL is an eligible candidate. This requirement has a dependency with therequirements SYN-F-2, SYN-F-3, SYN-F-4, SYN-F-5, SINV-F-1, VSB-F-1.

Rationale Providing a common interface description language and datatype system relatedto the common bus protocol applies the well-known ESB paradigm. This in partic-ular facilitates application developers in deploying heterogeneous Services andThings in a choreography.

Assessment Software testing that includes: specifying options for each Service/Thing regard-ing its interface and data as stated in the predefined unit-test plan; launching theServices/Things; and checking if the expected results of the unit-test are effec-tively returned.


ID VSB-F-3 Priority HIGHSource Consortium experience, DoW Version 1.0Verification D, T Ownership WP3, T3.1, T3.3Description The VSB MUST be able to dynamically manage resource allocation at the mid-

dleware level by employing the Enactment Engine.Comment This requirement has a dependency with the requirements EE-F-1, EE-F-5, EE-

F-6, EE-F-7, INT-F-8, INT-F-12, INT-F-13.Rationale Dynamic resource management at the middleware level is one of the target

CHOReVOLUTION mechanisms for supporting dynamic and adaptive chore-ographies.

Assessment Software demonstration of successful upgrading / downgrading of the cloud re-sources employed at middleware level. Software testing of the same operations.

ID VSB-F-4 Priority HIGHSource Consortium experience, DoW Version 1.0Verification D, T Ownership WP3, T3.1Description The VSB MUST be able to support dynamic bridging between choreography

peers (Services/Things), i.e., be able to add / remove bridging for a new / al-ready present middleware protocol at runtime.

Comment This requirement has a dependency with the requirement SYN-F-6, VSB-F-1,VSB-F-2.

Rationale Dynamic protocol bridging at the middleware level is one of the target CHOReV-OLUTION mechanisms for supporting dynamic and adaptive choreographies.

Assessment Software demonstration by incorporating / removing a new / already present peerand its middleware protocol at runtime. Software testing of the same operations.

ID VSB-F-5 Priority HIGHSource Consortium experience Version 1.0Verification T, D Ownership WP6, T6.2Description The VSB SHALL become an Eclipse plugin.Comment This requirement has a dependency with the requirements INT-F-14, INT-F-15.Rationale This requirement derives from the CHOReVOLUTION goal to create a users/de-

velopers community.Assessment Software testing to ensure that the plugin is indeed compliant with Eclipse, and

that the installation and configuration process can be performed smoothly on astandard Eclipse installation. Software demonstration of the plugin in function byincorporating new choreography peers through the plugin.


ID MOD-NF-1 Priority VERY HIGHSource Consortium experience, DoW, CHOReOS Version 1.0Verification A Ownership WP2, WP6Description The Choreography Modeler MUST be able to support choreography specifica-

tions conforming to the BPMN 2.0 EMF meta model.Comment The BPMN 2.0 EMF meta model is the one used by the Eclipse BPMN2 Modeler

(https://www.eclipse.org/bpmn2-modeler/).This requirement have a dependency with the requirement MOD-F-1.

Rationale Conformance to the BPMN 2.0 EMF meta model ensures internal interchange-ability of the choreography specification among the CHOReVOLUTION toolboxcomponents, and external interchangeability with existing tools (external to thetoolbox) that use the same meta model.

Assessment The definition of the BPMN 2.0 EMF meta model induces verification rules thatcan be used by analysis tools, e.g., EMF Validation Framework (projects.eclipse.org/projects/modeling.emf.validation), to automaticallycheck the conformance of the choreography specification to the BPMN 2.0 EMFmeta model.

ID IDM-NF-1 Priority HIGHSource Consortium experience Version 1.0Verification D, I Ownership WP6, T2.1Description The operations performed on the Identity Manager MUST be traceable. Audit

statements have to be available for archiving and consultation.CommentRationale It is needed because of existing legal constraints.Assessment Verify the requirements performing operation on the platform and visually inspect-

ing the produced traces and audit statements.

ID SEC-NF-01 Priority HIGHSource Security analysis Version 1.0Verification A Ownership WP6, T6.1Description The availability of CHOReVOLUTION platform MUST be 99.9Comment CHOReVOLUTION platform is the hearth of business services offered to the end

users. So its availability has to be guaranteed.Rationale CHOReVOLUTION platform shall offer a high availability mechanism in order to

offer business services. This mechanism will be mainly implemented throughCloud architecture but the different parts developed in CHOReVOLUTION (CDs,Security Filters, Adapters) have to be compliant with this architecture.

Assessment Analysis of architecture description.

ID EE-NF-1 Priority HIGHSource Consortium experience Version 1.0Verification A Ownership WP3, T3.3Description Confidentiality, integrity, and availability of EE’s operation MUST be guaranteed.CommentRationale This requirement derives from one of the main Chorevolution goals, i.e., secure

the choreographies.Assessment Analyze the code to check that all communication protocols used are secure

(i.e., HTTPS) and an authentication mechanism prevent unauthorized user fromlaunching EE’s operations. Additionally, a penetration testing of EE could beperformed





ID EE-NF-2 Priority HIGHSource Consortium experience Version 1.0Verification T Ownership WP3, T3.3Description The EE SHALL handle exceptions and faults of the underlying cloud infrastruc-

tureCommentRationale The EE has to be robust towards underlying cloud infrastructure’s faultsAssessment Artificially create several exceptions in the underlying cloud infrastructure (i.e.:

deny a VM deployment) and confirm that EE handles the exceptions (i.e.: it doesnot crash and it tries to find alternative solutions)

ID VSB-NF-1 Priority HIGHSource Consortium experience, DoW Version 1.0Verification A, D, T Ownership WP3, T3.1Description The VSB MUST provide middleware-level support for satisfying end-to-end

choreography QoS requirements, with regard to a set of QoS properties thatare going to be identified in WP3, when interconnecting heterogeneous Ser-vices/Things.

Comment Relevant QoS properties will be elicited in WP3, in close relation with theCHOReVOLUTION use cases. We will study the composability of QoS prop-erties when heterogeneous choreography peers are composed. In this regard,we will introduce a number of models and analyses on top of the elicited models,as well as related QoS assurance mechanisms. This requirement has a depen-dency with the requirement VSB-F-1.

Rationale Satisfying end-to-end choreography QoS requirements is not direct when inter-connecting heterogeneous Services/Things with different levels of a specific QoSproperty.

Assessment Analysis relying on quantitative models. Software demonstration including ex-perimental evaluation. Software testing of the middleware-level support mecha-nisms.

ID VSB-NF-2 Priority HIGHSource Consortium experience, DoW Version 1.0Verification A, D, T Ownership WP3, T3.1Description The VSB MUST provide middleware-level support for satisfying choreography

QoS requirements, with regard to a set of QoS properties that are going to beidentified in WP3, by dynamic resource management at the middleware level.

Comment Relevant QoS properties will be elicited in WP3, in close relation with theCHOReVOLUTION use cases. We will introduce a number of resource andrelated QoS models, analyses on top of the elicited models, and related QoSassurance mechanisms. This requirement has a dependency with the require-ments EE-F-1, EE-F-5, EE-F-6, EE-F-7, VSB-F-3, INT-F-8, INT-F-12, INT-F-13.

Rationale Dynamic resource management at the middleware level is one of the targetCHOReVOLUTION mechanisms for ensuring QoS of choreographies.



ID VSB-NF-3 Priority HIGHSource Consortium experience, DoW Version 1.0Verification A, D, T Ownership WP3, T3.1Description The VSB MUST provide middleware-level support for satisfying choreography

QoS requirements, with regard to a set of QoS properties that are going to beidentified in WP3, by dynamic bridging at the middleware level, i.e., by adding/re-moving interconnection for a new/already present middleware protocol at run-time.

Comment Relevant QoS properties will be elicited in WP3, in close relation with theCHOReVOLUTION use cases. We will study the replaceability of QoS prop-erties when a choreography peer needs to be substituted by another, differentpeer. In this regard, we will introduce a number of models and analyses on topof the elicited models, as well as related QoS assurance mechanisms. This re-quirement has a dependency with the requirements SYN-F-6, VSB-F-4.

Rationale Dynamic protocol bridging at the middleware level is one of the target CHOReV-OLUTION mechanisms for ensuring QoS of choreographies.




5 Integration requirements

ID INT-F-1 Priority HIGHSource Consortium experience, CHOReOS Version 1.0Verification T, I Ownership WP2Description The Synthesis Processor MUST be able to interact with internal and external

components through REST API.Comment Internal components of the Synthesis Processor are, e.g., CDs generator,

Adapter generator, Security Filters generator. External components (from thepoint of view of the Synthesis Processor) are, e.g., Service Inventory, EnactmentEngine.This requirement has a dependency with the requirements INT-F-2, INT-F-14,INT-F-15, IDM-F-16.

Rationale The adoption of REST-based APIs have been agreed at the consortium level byall partners. Main motivation are: (i) REST enables intermediate processing byconstraining messages to be self-descriptive; (ii) the interaction is stateless be-tween requests; (iii) standard methods and types are used to indicate semanticsand exchange information; (iv) uniform interfaces that do not need to be docu-mented on a per-resource or per-server basis; (v) universality of the identifiersembodied by URIs.

Assessment Inspect the APIs to confirm that all the required integration interfaces/methodsare exposed/offered and accessible.Define and run integration test cases so as to check if (i) the components to beintegrated effectively connect without raising communication errors/exceptions,(ii) output data are correctly transferred and (ii) input data are correctly received.In order to better locate possible errors, an incremental approach to test willbe adopted, i.e., the defined integration test cases will be run incrementally byinitially connecting a minimal set of components (i.e., a minimal configuration),and then adding other components, hence re-running the test cases.


ID INT-F-2 Priority VERY HIGHSource Consortium experience Version 1Verification A Ownership WP3Description The Identity Manager MUST expose a REST API providing methods to:

• retrieve a list of all services available in the inventory;

• search for specific service(s) by filtering for profile attribute values.

Every list item MUST be a fully completed service profile including played roles,supported contexts, endpoints and WSDL.

Comment This requirement has a dependency with the requirement SINV-F-1.Rationale In order to integrate the Identity Manager with the CHOReVOLUTION Synthesis

Processor component, its functionalities must be exposed through REST API.Furthermore, a REST API is required to enable client application, like as Con-sumer mobile apps, to access to Service Inventory features.

Assessment Analyse the API’s methods to confirm that the before mentioned functionality isexposed and accessible by the Synthesis Processor component of the CHOReV-OLUTION platform.

ID INT-F-3 Priority VERY HIGHSource Consortium experience Version 1Verification A Ownership WP3Description The Identity Manager MUST expose a REST API providing method to be used

by the Enactment Engine to notify asynchronously for choreography deploymentcompletion.

CommentRationale In order to integrate the Identity Manager with the CHOReVOLUTION Enact-

ment Engine component the event notification endpoint must be exposed throughREST API.

Assessment Analyse the API’s methods to confirm that the before mentioned functionality isexposed and accessible by the Enactment Engine component of the CHOReVO-LUTION platform.

ID INT-F-4 Priority VERY HIGHSource Consortium experience Version 1Verification A Ownership WP3Description The Identity Manager MUST include ConnId connectors to be able to integrate

with the Enactment Engine, concrete services (in terms of service itself or Se-curity Filter) and Federation Server in terms of policy-retrieval-point (PRP) andpolicy-information-point (PIP) sub-components.

Comment This requirement has dependencies with the requirements IDM-F-11 and IDM-F-12.

Rationale In order to integrate the Identity Manager with the other CHOReVOLUTION com-ponents suitable ConnId connectors have to be available.

Assessment Analyse available ConnId connector locations to confirm that the before men-tioned connector are available and ready to be used to communicate with theother CHOReVOLUTION components.


ID INT-F-5 Priority VERY HIGHSource Consortium experience Version 1Verification D Ownership WP3Description All the operation results about services, users and roles, from provisioning to

de-provisioning passing by any change performed during their life-cycle man-agement, MUST be made available to the Federation Server.

Comment This requirement has dependency with the requirement INT-F-4.Rationale In order to permit service access control, the Identity Manager has to propagate

to the Federation Server (policy retrieval point - PRP - and policy informationpoint - PIP) all the operations about users, roles and services performed directly,through the Identity Manager Web Console, or resulting from some internal syn-chronization process.

Assessment Perform all the available operations about users, roles and services and checkthe result into the Federation Server sub-components (PRP and PIP).

ID INT-F-6 Priority HIGHSource Security analysis Version 1.0Verification D Ownership WP6, T6.1Description All entities (human or machine) using CHOReVOLUTION platform MUST be au-

thenticated.CommentRationale In order to avoid that any external actors (hackers) interact or use the choreogra-

phies.Assessment This requirement will be demonstrated by running the use cases.

ID INT-F-7 Priority HIGHSource Security analysis Version 1.0Verification D Ownership WP6, T6.1Description The CHOReVOLUTION platform MUST log all exchanges with external entities.CommentRationale In order to know what data are received or sent by CHOReVOLUTION platform,

the information has to be logged. At system level, logs can be used by cyber-security functions to detect abnormal behaviours and to analyse potential at-tacks.

Assessment This requirement will be demonstrated with a nominal scenario (use cases).

ID INT-F-8 Priority HIGHSource Security analysis Version 1.0Verification D Ownership WP6, T6.1Description The logs of CHOReVOLUTION platform MUST be written or read only by autho-

rized people or authorized application.CommentRationale In order to have logs integrity and to avoid repudiation problems, logs must be

written only by authenticated and authorized actors (human user or Machine).Assessment This requirement will be dmonstrated with penetration test about logs.


ID INT-F-9 Priority HIGHSource Security analysis Version 1.0Verification D Ownership WP6, T6.1Description Each time the CHOReVOLUTION platform receives data through interfaces, it

MUST check their validity (format and content).CommentRationale To provide data with incorrect value could have impact on the availability of the

platform. This way is often used by hackers to take the control (cross-site script-ing attack, denial of service attack for example).

Assessment this requirement will be demonstrated with different false format and values.

ID INT-F-10 Priority HIGHSource Security analysis Version 1.0Verification A Ownership WP6, T6.1Description Each time confidential data are exchanged with CHOReVOLUTION platform, the

protocol https MUST be used.CommentRationale The confidential data (and so private data) can be shared only by authorized ac-

tors. To avoid that hackers read easily this kind data, the data must be encrypted.It is the case with https protocol.

Assessment This requirement will be checked through the design analysis.

ID INT-F-11 Priority HIGHSource Security analysis Version 1.0Verification D Ownership WP6, T6.1Description CHOReVOLUTION platform MUST manage the case where an external system

(Service providers or Things) is unable to answer in the context of a choreographyexecution.

CommentRationale Denial of Service happens when an external entity is not able to answered re-

quests coming from CHOReVOLUTION platform.Assessment This requirement will be demonstrated with interruption of data flow between

external entities and CHOReVOLUTION platform.


ID INT-F-12 Priority HIGHSource TPP Version 1Verification I Ownership WP6Description The CHOReVOLUTION testing ground will be based on an IaaS platform and

a set of automation scripts allowing for fast deployment and configuration. Toenable this overall deployment automation, the underlying cloud infrastructureMUST be equipped with an automation engine, the EE will interface with.

Comment There will be no direct interaction of the choreography services with the automa-tion engine, as the EE will abstract the engine providing the RESTful APIs. Theautomation engine usually takes description files as an input with a specific andproprietary format. The format to be used for the concrete choreography speci-fication in SYN-F-6 should be mapped as closely as possible with the syntax ofthe automation engine, to avoid an excessive abstraction.

Rationale A datacenter automation engine will allow for a rapid development of CHOReV-OLUTION choreographies. There are different degrees of automation allowed,based on the cloud layer in use. Using a datacenter automation layer ensures aproper abstraction from the type and vendor of the cloud solution. The datacenterautomation layer will also be used for status and capacity monitoring.

Assessment Ensure that a infrastructure automation engine is up and running in the cloudinfrastructure.

ID INT-F-13 Priority MEDIUMSource TPP Version 1Verification T Ownership WP6Description An automated deployment function SHALL be developed to allow an easier setup

of the choreographies underlying infrastructure at testing time.Comment Deployment plugins will be developed for the chosen IDE platform to allow an

easy provision of the CHOReVOLUTION component on the actual underlyingcloud infrastructure where they will be run.

Rationale In this way, the developers will have the possibility to develop the componentsand then launch them directly in the service cloud.

Assessment Execute the deployment plugins and confirm that the CHOReVOLUTION com-ponents are correctly deployed on the service cloud.


ID INT-F-14 Priority VERY HIGHSource Consortium experience, CHOReOS Version 1Verification A Ownership WP3Description The EE API MUST provide all the necessary primitives to offer all the enact-

ment features to the synthesis processor and to the choreography components(for runtime actions) and MUST be able to interpret the concrete choreographysynthesis document

Comment This requirement has a strong dependency from SYN-F-6. The format of theconcrete choreography description file shall be agreed. It might be in Json orXML format and shall be fed to the EE via the APIs. An additional relation iswith SINV-F-1, as the service inventory will host the information for the servicetemplates to be deployed. The requirement depends on EE-F-1.

Rationale All the EE APIs will be specified as RESTful calls, as agreed with the rest ofthe consortium. The concrete choreography specification and the responsescoming from the EE API will be in Json or XML format. Service templates, VMsor containers will be provided to the EE in the form of ready-to deploy resourcesand listed in the Service inventory.

Assessment Analyse the API’s methods to confirm that the aforementioned functionality is ex-posed and accessible by the other components of the CHOReVOLUTION plat-form.

ID INT-F-15 Priority MEDIUMSource Consortium experience Version 1Verification A Ownership WP3Description The EE’s API MUST expose the needed methods to stop a running choreography

and free the used resources.Comment Depends on EE-F-1, EE-F-2, EE-F-3 and EE-F-4Rationale All the EE APIs will be specified as RESTful calls, as agreed with the rest of

the consortium. The concrete choreography specification and the responsescoming from the EE API will be in Json or XML format. Service templates, VMsor containers will be provided to the EE in the form of ready-to deploy resourcesand listed in the Service inventory.


ID INT-F-16 Priority LOWSource Consortium experience Version 1Verification A Ownership WP3Description The EE’s API MUST expose the needed methods to pause a running choreogra-

phy.Comment Depends on EE-F-1, EE-F-2, EE-F-3 and EE-F-4Rationale All the EE APIs will be specified as RESTful calls, as agreed with the rest of

the consortium. The concrete choreography specification and the responsescoming from the EE API will be in Json or XML format. Service templates, VMsor containers will be provided to the EE in the form of ready-to deploy resourcesand listed in the Service Inventory.



ID INT-F-17 Priority LOWSource Consortium experience Version 1Verification A Ownership WP3Description The EE’s API MUST expose the needed methods to resume a previously stopped

choreography.Comment Depends on EE-F-1, EE-F-2, EE-F-3 and EE-F-4Rationale All the EE APIs will be specified as RESTful calls, as agreed with the rest of



ID INT-F-18 Priority VERY HIGHSource Consortium experience Version 1Verification A Ownership WP3Description The EE MUST collect logging data for the monitored virtual environments. The

data will be stored in the form of standard SYSLOG log files. The inner structureof the message field of the application-level log entries MUST be agreed for thechoreography services at development time. The EE will not parse, nor summa-rize the logs. It will only collect them during choreography runtime providing asyslog server resource and stop collecting at any pause or shutdown event

Comment This requirement depends on EE-F-5.Rationale All the EE APIs will be specified as RESTful calls, as agreed with the rest of


Assessment Analyse the API’s methods to confirm that the aforementioned functionality is ex-posed and accessible by the other components of the CHOReVOLUTION plat-form


ID INT-F-19 Priority VERY-HIGHSource Consortium experience Version 1Verification A Ownership WP3Description The EE’s API MUST expose the needed methods to enable the automatic re-

quest for reconfiguration of the virtual environments generated and managed byEE.

Comment Reconfiguration features will be limited to scalability request commands viaRESTful APIs, addition or removal of already specified components (as definedin the concrete choreography synthesis document). Reconfiguration of the fea-tures a running choreography will instead need a complete re-deployment of thechoreography. This requirement depends on SYN-F-6 for the re-deployment fea-ture..

Rationale All the EE APIs will be specified as RESTful calls, as agreed with the rest ofthe consortium. The concrete choreography specification and the responsescoming from the EE API will be in Json or XML format. Service templates, VMsor containers will be provided to the EE in the form of ready-to deploy resourcesand listed in the Service inventory.


ID INT-F-20 Priority HIGHSource Consortium experience Version 1.0Verification T Ownership WP3, T3.1Description The VSB MUST provide an API to application developers for the deployment

of choreography peers (Services/Things) depending on the interaction paradigmthey follow.

Comment This requirement has a dependency with the requirements SYN-F-6, VSB-F-1,VSB-F-2, VSB-F-5, INT-F-15.

Rationale Choreography peers need to be deployed on the VSB and to interact through theVSB when they employ heterogeneous interaction paradigms and protocols. ThisAPI is necessary for facilitating application developers in deploying choreographypeers.

Assessment Software testing that includes: specifying options for each Service/Thing andits middleware protocol as stated in the predefined unit-test plan; launching anddeploying the Services/Things on the VSB; and checking if the expected resultsof the unit-test are effectively returned.


ID INT-F-21 Priority HIGHSource Consortium experience Version 1.0Verification T Ownership WP3, T3.1Description The VSB MUST provide an API to middleware developers for the development

and integration into the VSB of new binding components.Comment This requirement has a dependency with the requirements SYN-F-6, VSB-F-1,

VSB-F-2, VSB-F-5.Rationale Binding components adapt the middleware protocol of a Service/Thing to the

common bus protocol of the VSB and vice-versa. A binding component for a newmiddleware protocol derives from the specialization of the binding componenttemplate proper to the related middleware paradigm. This API is necessary forfacilitating middleware developers in incorporating a new middleware technologyinto the VSB.

Assessment Software testing that includes: specifying options for the new binding compo-nent and a test Service/Thing that uses it as stated in the predefined unit-testplan; launching and deploying the binding component and the test Service/Thingon the VSB; and checking if the expected results of the unit-test are effectivelyreturned.

ID INT-NF-1 Priority VERY HIGHSource Consortium experience Version 1Verification T Ownership WP3Description Only authorized requests to Identity Managers’s API SHALL be executed.CommentRationale Only the allowed CHOReVOLUTION components should access Identity Man-

ager’s API and submit requests.Assessment Test the API implementation to confirm non authorized requests are not exe-

cuted.

ID INT-NF-2 Priority VERY HIGHSource Consortium experience Version 1Verification T Ownership WP3Description Only authorized requests to EE’s API SHALL be executed.CommentRationale Only the allowed CHOReVOLUTION components should access EE’s API and

submit requests.Assessment Test the API implementation to confirm non authorized requests are not exe-

cuted.



6 Development requirements

ID DEV-NF-1 Priority VERY HIGHSource Consortium experience, DoW Version 1Verification I Ownership WP2, WP3Description A Software Configuration Management (SCM) MUST be used as methodology

to control and manage the CHOReVOLUTION platform development process.Comment A SCM is a set of activities designed to control change by identifying the work

products that are likely to change, establishing relationships among them, defin-ing mechanisms for managing different versions of these work products, control-ling the changes imposed, and auditing and reporting on the changes made.

Rationale In order to manage and control the entire software development process inCHOReVOLUTION a distributed SCM system is required. The chosen tool is Git(https://www.git-scm.com/) since it offers the following main characteris-tics that have been considered indispensable by the consortium: (i) the Branch-ing and Merging features are flexible and efficient in that they allow for frictionlesscontext switching, role-based codelines, feature based workflow, and disposableexperimentation; (ii) each commit has an author and a committer field, whichrecord who and when created the change and who committed it; (iii) it has a verystrong and huge community.

Assessment Check that the version control system will be properly configured and correctlyused.

ID DEV-NF-2 Priority VERY HIGHSource Consortium experience, DoW Version 1Verification I Ownership WP2, WP3Description A build automation tool SHALL be used to ease the building and unit testing

phase, and to automatize the dependency management.Comment The chosen tool is Apache Maven (https://maven.apache.org/) that is a

software project management and comprehension tool. Based on the conceptof a project object model (POM), Maven can manage a project’s build, reportingand documentation from a central piece of information. It is based around thecentral concept of a build lifecycle, i.e., the process for building and distributing aparticular artifact (project) is clearly defined.

Rationale In case of multiple development teams environment as it happens in largeprojects as CHOReVOLUTION, a build automation tool can set-up the way towork as per standards in a reasonably short time. As most of the project setupsare simple and reusable, a build automation tool makes software developmentmore easy while creating reports, checks, build and testing automation setups.

Assessment Check that the chosen automatic building tool is properly configured and that theartifacts are correctly generated.


https://www.git-scm.com/

https://maven.apache.org/

ID DEV-NF-3 Priority HIGHSource Consortium experience, DoW Version 1Verification I Ownership WP2, WP3, WP6Description A tool supporting continuous integration, as a software engineering good prac-

tice, SHALL be used during the implementation phase of CHOReVOLUTION.Comment The chosen tool is Bamboo (https://www.atlassian.com/software/

bamboo) that is a continuous integration and delivery tool that ties automatedbuilds, tests and releases together in a single workflow. It works well along-side JIRA, Git and it is compliant with the OW2 Technology Infrastructure (i.e.,the infrastructure chosen by the CHOReVOLUTION). Bamboo integrates versioncontrol systems like Git, so that new branches are automatically brought underthe same continuous integration scheme as master, and any two branches in therepository can be merged automatically before each test run. Moreover Bamboooffers extensive and ever-expanding integration with JIRA in order to get relatedbuild results inside issues and the issue’s vital stats on the build result in Bamboo,and track each issue’s deployment status throughout the environments.This requirement has a dependency with the requirements DEV-NF-1 and DEV-NF-5.

Rationale Continuous integration facilities are required in order to provide rapid feedback toCHOReVOLUTION platform developers about their changes, to isolate commitsfor easy troubleshooting when the build fails, and to automatically deploy qualifiedbuilds to testing environments.

Assessment Check that the continuous integration tool is properly configured and effectivelyused.

ID DEV-NF-4 Priority VERY HIGHSource Consortium experience, DoW Version 1Verification A, I Ownership WP2, WP3Description An automatic unit test tool for Java MUST be used through all the coding phase

to automatically execute predefined unit test cases.Comment The chosen tool is JUnit (http://junit.org/) that is a simple framework

to write repeatable test cases. This requirement has a dependency with therequirements DEV-NF-3 and DEV-NF-5.

Rationale Since all the components constituting the CHOReVOLUTION toolbox will be de-veloped in Java, it is a best practice for developers to use an automatic unit testtool to automatically perform unit testing of software by writing test cases. Auto-matic unit test tools allow to create a set of unit tests that can be run automat-ically when changes are made to software; in this way, developers can ensurethat changes to the software they are creating do not break things that werepreviously functioning.

Assessment Check that tests suites are correctly written and executed periodically throughAtlassian Bamboo and related reported issues into Jira.




http://junit.org/

ID DEV-NF-5 Priority HIGHSource Consortium experience, DoW Version 1Verification I Ownership WP2, WP3, WP6Description A tool supporting the planning and tracking of the activities, as a software en-

gineering good practice, SHALL be used during the design and implementationphases of CHOReVOLUTION platform.

Comment Planning and tracking tools such as Jira (https://www.atlassian.com/software/jira) will be used.

Rationale It is necessary to track activities of the developers in order to support the devel-opment of the CHOReVOLUTION platform. Any type of artifacts must be trackedin order to meet the requirements, timely perform identified tasks, solve bugs andsatisfy requests, as well as mitigate and identify risks.

Assessment Check that the adopted tools are properly configured and effectively used. Thisrequires to check that, e.g., suitable tracker templates are suitably created andthe related workflow is configured.

ID DEV-NF-6 Priority MEDIUMSource Consortium experience Version 1Verification I Ownership WP2, WP3, WP6Description Collaborative behaviour between the partners MAYBE be supported and

boosted, especially during the implementation phase, through the use of com-munication tools.

Comment Tools supporting communication and collaboration such as Confluence (https://www.atlassian.com/software/confluence), and HipChat (https://www.atlassian.com/software/hipchat) are available.

Rationale It is necessary to foster communication between partners in order to supportintegration and collaborative work.

Assessment Check that the adopted tools are properly configured and effectively used.

ID DEV-NF-7 Priority HIGHSource Consortium experience, DoW Version 1Verification I Ownership WP2, WP3Description Code-level interoperability MUST be achieved through a platform agnostic pro-

gramming language.Comment The Java language has be chosen.Rationale CHOReVOLUTION artifacts must be platform agnostic.Assessment Check that the code is written in a platform agnostic programming language.

ID DEV-NF-8 Priority MEDIUMSource Consortium experience, DoW Version 1Verification A Ownership WP2, WP3Description The code MUST be well documented and MUST use a coding convention.Comment Coding conventions (such as Java Coding convention http://

www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html) will be adopted.

Rationale Good documentation and coding conventions are of paramount importance toensure that the code is readable and modifiable by others than the original de-veloper.

Assessment Check that the code is well documented and respect coding conventions.




https://www.atlassian.com/software/confluence

https://www.atlassian.com/software/confluence

https://www.atlassian.com/software/hipchat

https://www.atlassian.com/software/hipchat

http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html




Bibliography

[1] CHOReVOLUTION Project Team. Deliverable 4.1 - Urban Traffic Coordination Scenario Definitionand Requirements, July 2015.

[2] CHOReVOLUTION Project Team. Deliverable 5.1 - Smart Mobility and Tourism Scenario Definitionand Requirements, July 2015.

[3] Gregor Hohpe and Bobby Woolf. Enterprise Integration Patterns: Designing, Building, and Deploy-ing Messaging Solutions - Fiftheenth printing 2011. Addison-Wesley Longman Publishing Co., Inc.,Boston, MA, USA, 2004.

[4] Paola Inverardi and Massimo Tivoli. Automatic synthesis of modular connectors via composition ofprotocol mediation patterns. In Proceedings of ICSE’13, 2013.

[5] Mike Mannion and Barry Keepence. Smart requirements. SIGSOFT Softw. Eng. Notes, 20(2):42–47, April 1995.

[6] Oasis. Ws-trust 1.4 - http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html, April 2012.

[7] Suzanne Robertson and James Robertson. Mastering the Requirements Process (2Nd Edition).Addison-Wesley Professional, 2006.


http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html

http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html


Annex A Security analysis

One of the main CHOReVOLUTION objectives (OB4) defined in the DoW was to secure choreogra-phies. Choreographies belong to CHOReVOLUTION platform and, for defining the security objectivesto take into account, use cases using this platform are needed. For a use case using such platform,three parts can be considered. The first one is the external service providers, already existing, allowingdifferent interactions with external actors. These services are as is and cant be modified in this context.They have their own interfaces based on web services, rest services or proprietary interface. The sec-ond one is all applications developed specifically for the use case. It can be mobile applications andserver applications. These applications do not exist and are developed in the context of CHORevOLU-TION. The third one is the CHOReVOLUTION platform itself. This platform is developed in the contextof CHOReVOLUTION project and aims to be generic for different domains and technically agnostic.This platform offers the business layer with the choreographies implementation. For the first one, it isimportant to take into account the existing security properties. This aspect is described in the paragraphbelow about maintaining operational security condition. For the second one, the security properties andthe associated security requirements of the use cases are described in D4.1 [1] and D5.1 [2]. For thelast one, for CHOReVOLUTION platforms, a threat analysis is conducted and security requirementswere deduced. It is only the first security analysis based on the already defined design. This analy-sis will be refined later as soon as the design will be more detailed. The results are described in thefollowing paragraph.

Annex A.1. Maintaining operational security condition

Building a use case with CHOReVOLUTION platform involves integrating new development with legacyservices offered by service providers. These legacy services impose to take into account their securityconstraints. CHOReVOLUTION platform has to implement a way to manage the different securityconstraints following the security policy of the different service provider. This way is called securityinteroperability. To do that, CHOReVOLUTION platform has to offer mechanisms usable during designtime and runtime phase.

Annex A.1.1. At design time

CHOReVOLUTION platform has to:

• Offer at design time a mechanism to identify the security constraints requested by the differentservice providers.

• Store the needed information for choreographies execution regarding the security interoperability

In order to do that, a federation server will be provided and security agents will be deployed (see Chapter3 for more details). The following requirements shall be taken into account:


Req ID TitleSEC-F-01 In the case of authentication token, the Federation server MUST offer a function

to transform this token in an usable token by the service involved in the choreg-raphy.

SEC-F-02 The Federation server MUST offer to Security manager, at design time, a way todiscover the different security mechanism requested by the Services provider byusing WSDL.

SEC-F-03 Using the Federation server, the Security Manager MUST be able to create man-ually accounts with Credential for services involved in choreographies and re-questing authentication.

SEC-F-04 Using the Federation server, the Security Manager MUST be able to associatedifferent accounts; That means that, for an account given as input, the Federationserver MUST associate another account usable by the called service.

These requirements are more detailed in Chapter 4.

Annex A.1.2. At runtime time

CHOReVOLUTION platform has to:

• Offer at runtime a mechanism to provide the necessary account for using external resources(requested by the service provider)

• Dynamically convert account provided to account requested by service provider.

In order to do that, a federation server will be provided and security agents will be deployed (seeChapter 3 for more details). The following requirements shall be taken into account:

Req ID TitleSEC-F-05 During the execution of the choregraphies (runtime), the Federation server MUST

be able to provide the necessary account for the called service.SEC-F-06 The Security Filter MUST provide to Federation Server the account available

for the calling service (if existing) with the credential and MUST receive conse-quently the account to be used with the called service.

SEC-F-07 If a service uses specific security token, the Security Filter MUST provide toFederation Server the existing security token available (if existing) and MUSTreceive consequently the new token to be used with the called service.

These requirements are more detailed in Chapter 4.

Annex A.2. Threats Analysis

Annex A.2.1. Method description

In order to identify threats towards the Use Case, we have used the Microsoft Security DevelopmentLifecycle (SDL) threat modeling approach, commonly referred to as STRIDE 1. STRIDE is an acronymfor Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Priv-ilege, which constitute the main threats to computer systems. The threats have been derived from thecorresponding primary security attributes. STRIDE is a classification scheme for characterizing knownthreats according to the kinds of exploit that are used (or motivation of the attacker). This approach isalso used in the other Use Case and for the CHOReVOLUTION platform to identify the main threats.The different steps to follow are:

1STRIDE - Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilegehttp://msdn.microsoft.com/en-us/magazine/cc163519.aspx


• To draw a data flow overview with data stores, flow, boundary, processes and users/interactors.

• To identify, for each of these components, the relevant threat types to be considered.

For these 2 steps, Microsoft Threat Modeling Tool 2014 was used. The results are given in SectionAnnex A.2.2.

Annex A.2.2. Security threats

Data flow overview

Based on the Figure 3.2, the following schema was drawn (Figure Annex A.1). This schema is nottotally complete because the design of the use case is not finished. So, this schema is more genericand show the main kinds of interaction defined at this step.

Figure Annex A.1: CHOReVOLUTION Flow diagram for UTC scenario

Data storesThe data flow diagram contains three stores which are devices:

1) Public transport: it contains all data sent by the trains, tramways, bus, etc

2) Traffic lights: it contains all information sent by the different traffic lights impacting the traffic jam.

3) Navigation device SEADA Client: it contains the application developed in the context of theuse case for the end user (the Goteborg driver) and is deployed on a common device like asmartphone.

FlowsThe data flow diagram contains two primary flows:

1) Http flows: A part of external actors use http protocol to exchange information throw web servicesor with web applications.


2) Https flows: In some cases, external actors request https protocol in order to protect confidentialdata.

ProcessesIn the perimeter of the CHOReVOLUTION platform, the design is not enough mature to deduce the

different process. That is why only one large process is mentioned. As soon as the design will be moredefined, different processes could be added and the threat analysis will be refined.

Interactors/usersThe data flow diagram contains two kinds of interactors/users.

1) The first one is the different services offered by external entities to SEADA application. In thefigure above, only provider were mentioned:

1) Vsttrafic giving in real time bus location.

2) Traficverkert giving dynamic information about the traffic.

3) Gteborg Stad giving open data with, for example, the status of the bridge.

4) Google offering different kind of services like maps.

5) Waze giving traffic jam information based on data provided by a driver community.

2) The second one is the end-user using SEADA application. In this case, the user is a human.

Analysis

In this section the main threats are listed. This list was computed by the tool and, for each threat, adecision was made if the threat is applicable or not. At this stage, the threats are mainly focused onthe flows used (http and https) and on the kind of external entities, data sore or web services. As thethreats are the same for the different kind of interface, the list is simplified with the different kinds ofthreats.


Threattype

ID threat Category Description S T R I D E

T001 Spoofing the Ex-ternal Entity

Spoofing is when aprocess or entity issomething other thanits claimed identity. Ex-amples include substi-tuting a process, a file,website or a networkaddress.

The External Entity may bespoofed by an attacker andthis may lead to unautho-rized access to CHOReVO-LUTION platform. Considerusing a standard authentica-tion mechanism to identify theexternal entity.

X

T002 Potential Lack ofInput Validationfor CHOReVO-LUTION platform

Tampering is the act ofaltering the bits. Tam-pering with a processinvolves changing bitsin the running process.Similarly, Tamperingwith a data flow in-volves changing bitson the wire or betweentwo running processes.

Data flowing across HTTPmay be tampered with byan attacker. This may leadto a denial of service at-tack against CHOReVOLU-TION platform or an eleva-tion of privilege attack againstCHOReVOLUTION platformor an information disclosureby CHOReVOLUTION plat-form. Failure to verify that in-put is as expected is a rootcause of a very large numberof exploitable issues. Con-sider all paths and the waythey handle data. Verify thatall input is verified for correct-ness using an approved listinput validation approach.

X

T003 Cross Site Script-ing


The web server ’CHOReVO-LUTION platform’ could be asubject to a cross-site script-ing attack because it does notsanitize untrusted input.

X

T004 Potential DataRepudiation byCHOReVOLU-TION platform

Repudiation threatsinvolve an adversarydenying that somethinghappened.

CHOReVOLUTION platformclaims that it did not receivedata from a source outsidethe trust boundary. Con-sider using logging or audit-ing to record the source, time,and summary of the receiveddata.

X


Threattype


T005 Data Flow Sniff-ing

Information disclosurehappens when the in-formation can be readby an unauthorizedparty.

Data flowing across HTTPmay be sniffed by an attacker.Depending on what type ofdata an attacker can read, itmay be used to attack otherparts of the system or sim-ply be a disclosure of infor-mation leading to complianceviolations. Consider encrypt-ing the data flow.

X

T006 Potential ProcessCrash or Stop forCHOReVOLU-TION platform

Denial of Service hap-pens when the processor a datastore is notable to service incom-ing requests or performup to spec.

CHOReVOLUTION platformcrashes, halts, stops or runsslowly; in all cases violatingan availability metric.

X

T007 Data Flow HTTPIs Potentially In-terrupted


An external agent interruptsdata flowing across a trustboundary in either direction.

X

T008 Data FlowHTTPS Is Poten-tially Interrupted


An external agent interruptsdata flowing across a trustboundary in either direction.

X

T009 Spoofing theCHOReVOLU-TION platformAccess Controlfrom Process

Spoofing is when aprocess or entity issomething other thanits claimed identity. Ex-amples include substi-tuting a process, a file,website or a networkaddress.

CHOReVOLUTION platformmay be spoofed by an at-tacker and this may leadto information disclosure byany devices. Consider us-ing a standard authentica-tion mechanism to identify thedestination process.

X

T010 Persistent CrossSite Scripting


The web server ’CHOReVO-LUTION platform’ could be asubject to a persistent cross-site scripting attack becauseit does not sanitize data storeinputs and output.

X


Threattype


T011 Data Store Inac-cessible


An external agent preventsaccess to a data store on theother side of the trust bound-ary.

X

T012 Risks from Log-ging

Tampering is the act ofaltering the bits. Tam-pering with a processinvolves changing bitsin the running process.Similarly, Tamperingwith a data flow in-volves changing bitson the wire or betweentwo running processes

Log readers can come underattack via log files. Considerways to canonicalize data inall logs. Implement a singlereader for the logs, if pos-sible, in order to reduce at-tack surface area. Be sureto understand and documentlog file elements which comefrom untrusted sources.

X

Annex A.3. Security requirements

The threats identified previously are mapped to a set of detailed requirements in this chapter. Depend-ing on the different threats, different security properties are requested. The following table presents thelinks between STRIDE threats and security properties we want.

Threat Property we wantSpoofing AuthenticationTampering IntegrityRepudiation NonrepudiationInformation disclosure ConfidentialityDenial of service AvailabilityElevation of privilege Authorization

Only the white cells have to be used in the context of CHOReVOLUTION platform. Based on therequested properties, the following requirements are deduced.


Req ID TitleINT-F-06 All entities (human or machine) using CHOReVOLU-

TION platform MUST be authenticated by the plat-form.

INT-F-07 CHOReVOLUTION platform MUST log all exchangeswith external entities.

INT-F-08 The logs of CHOReVOLUTION platform MUST bewritten or read only by authorized people or autho-rized application.

INT-F-09 Each time the CHOReVOLUTION platform receivesdata through interfaces, it MUST check their validity.(format and content)

INT-F-10 Each time confidential data are exchanged withCHOReVOLUTION platform, the protocol httpsMUST be used.

INT-F-11 CHOReVOLUTION platform MUST manage the casewhere an external system (Service providers orThings) is unable to answer in the context of a chore-ography execution.

SEC-NF-01 The availability of CHOReVOLUTION platform MUSTbe 99.9

All these requirements will protect CHOReVOLUTION platform against the threats mentioned in An-nex A.2.2. The following table gives the traceability between the requirements and these threats.

Req ID TitleINT-F-06 T001, T009INT-F-07 T004INT-F-08 T012INT-F-09 T002, T003, T010INT-F-10 T005INT-F-11 T007, T008, T011SEC-NF-01 T006

This security analysis is at a very high level and has to be continued for taking into account newthreats depending on the design.


Documents

H2020 ICT9 Project DeliverableD6 - CHOReVOLUTION · (CEFRIEL), Marco Masetti (Softeco), Angelo Naselli (Softeco), Olivier Bouzereau (OW2) Final version ready for PMC PMC 15 July 2015