A SSERT 4S OA
Advanced Security Service cERTificate for SOA
CP - STREP - Grant No. 257351
Architecture and High-level Design
(revised 30 June 2012)
Deliverable D.6.1
Legal Notice
All information included in this document is subject to change without notice.
The Members of the
Assert4Soa Consortium make no warranty of any kind with regard to this document, including, but not
limited to, the implied warranties of merchantability and fitness for a particular purpose. The Members of
the Assert4Soa Consortium shall not be held liable for errors contained herein or direct, indirect, special,
incidental or consequential damages in connection with the furnishing, performance, or use of this material.
Project Title
Grant Number
Project Type
Title of Deliverable
Subtitle of Deliverable
Deliverable No.
Dissemination Level
Contractual
Delivery
Date
Actual Delivery Date
Contributing WPs
Editor(s)
Author(s)
Reviewer(s)
Assert4Soa - Advanced Security Service
cERTificate for SOA
257351
CP - STREP
Architecture and High-level Design
(revised 30 June 2012)
D.6.1
Consortium
30 september 2011
30 september 2011
WP 6
Antonino Sabetta (SAP)
Michele
Bezzi
(SAP),
Stefania
D’Agostini (ENG), Samuel Kaluvuri (SAP),
Antonio
Mana
(UMA),
Claudia
Pandolfo (ENG) Gimena Pujol (UMA),
Antonino Sabetta (SAP)
Antonio Mana (UMA), Howard Foster (CITY)
Executive Summary
This deliverable presents the high-level architecture of Assert4Soa. It documents
the results of our initial work towards instantiating Assert4Soa in a concrete
system. The goal is, at the same time, to demonstrate the feasibility of the project
vision through a prototype implementation, and to provide a playground to compare
and experiment with different alternative approaches to the research problems tackled
in the other technical work packages.
The document puts a special emphasis on the guiding architectural principles, in
particular with regard to those impacting architectural qualities such as flexibility
and extensibility. Following established architecture documentation best practices,
the architecture description is presented as a set of focused views, each addressing
a specific set of concerns. More precisely, the overall structure of the framework
as well as its main behavioural characterisation is described in a functional view,
where the main elements of the system are identified and represented in terms
of their responsibilities, provided and required functionalities, and key interaction
mechanisms. The data model underpinning such functional model is presented in a
separate information view, which clarifies the semantics of the concepts used in the
rest of the document, and specifies the relationships among those concepts.
Finally, having identified security as the prominent non-functional cross-cutting
concern for the Assert4Soa framework, a chapter is dedicated to discussing the
threats that the system could face, and a set of countermeasures to prevent them.
The document concludes with a brief discussion of possible deployment options
and technology solutions that could be adopted to realise the architecture; finally,
we outline the next steps that will be taken in Work Package 6, both in the short
term and in the longer term.
An appendix provides an overview of the key deliverables of the other Work
Packages, clarifying the link between the abstract elements defined in this architectural
specification and the documents that detail the internal structure and behaviour of
those elements.
Assert4Soa
Contents
1 Introduction
1.1 Overview . . . . . . . . . . . . . . . . .
Purpose and scope . . . . . . . . . . . .
Intended audience . . . . . . . . . . . .
Architecture Documentation Guidelines
1.2 Architectural primitives and principles
Plug-in based Architecture . . . . . . .
.
.
.
.
.
.
5
5
5
6
7
9
11
. . .
. . .
. . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . .
14
14
21
24
24
26
26
27
29
30
30
31
32
33
34
34
35
36
36
37
38
39
40
41
49
3 Information View
3.1 Assert4Soa Data Entities . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Information Flow Model . . . . . . . . . . . . . . . . . . . . . . . . .
Assert Management activity diagram . . . . . . . . . . . . . . . . .
52
52
58
58
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Functional View
2.1 From use cases to architectural mechanisms
2.2 Architecture overview . . . . . . . . . . . . .
2.3 Component catalog . . . . . . . . . . . . . .
Entry Point . . . . . . . . . . . . .
Query Handler . . . . . . . . . . . .
Discovery Manager . . . . . . . . . .
Registry Abstraction Layer . . . . . . .
Master Matchmaker . . . . . . . . . .
Composition Manager . . . . . . . . .
Assert-O Matchmaker . . . . . . . . .
Assert-E Matchmaker . . . . . . . . .
Assert-M Matchmaker . . . . . . . . .
Assert Verifier . . . . . . . . . . . .
Assert-O Verifier . . . . . . . . . . .
Assert-M Verifier . . . . . . . . . . .
Assert-E Verifier . . . . . . . . . . .
Preference Store . . . . . . . . . . .
Trust Manager . . . . . . . . . . . .
Consumer Agent . . . . . . . . . . .
System Administration . . . . . . . . .
System Administration Console . . . . .
Assert Issuing Tool . . . . . . . . . .
Ontology Manager . . . . . . . . . .
2.4 Assert4Soa plug-ins . . . . . . . . . . . . .
D.6.1 - Architecture and High-level Design
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
. . . . .
. . . . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 / 87
Assert4Soa
Service Discovery activity diagram .
Formulate Query activity diagram .
Compose Services activity diagram
Mach Services activity diagram . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Security Perspective
4.1 Threat analysis . . . . . . . . . . . . . . . . . . . . . .
4.2 Risk Management . . . . . . . . . . . . . . . . . . . . .
Assert Issuer . . . . . . . . . . . . . . . . . . . . . . .
Service Consumer . . . . . . . . . . . . . . . . . . . . .
Assert4Soa Management System . . . . . . . . . . .
4.3 Security features of the framework . . . . . . . . . . . .
4.4 Realising a secure architecture: overview of approaches,
and standards . . . . . . . . . . . . . . . . . . . . . . .
Access control and Client authentication . . . . . . . .
Certification infrastructures and standards . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
technologies,
. . . . . . . .
. . . . . . . .
. . . . . . . .
58
60
60
60
65
65
68
68
69
70
71
75
75
76
5 Conclusion
5.1 Component and communication technologies . . . . . . . . . . . . . .
5.2 Deployment configurations . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Conclusion and next steps . . . . . . . . . . . . . . . . . . . . . . . .
77
77
79
80
A References to the other work packages and deliverables
82
Bibliography
84
D.6.1 - Architecture and High-level Design
4 / 87
Assert4Soa
Chapter 1
Introduction
The key goal of Work Package 6 (WP6) is to design and realise an architecture to
support the Assert lifecycle, covering the issuing, management and consumption of
Asserts. This goal is pursued in practice by providing a concrete instantiation of
the Assert4Soa framework that can be used 1) to demonstrate and showcase the
project vision through a working prototype implementation; and 2) to compare
and experiment with different alternative approaches to the various underlying
theoretical and technical problems tackled in the other work packages.
Therefore, this deliverable documents the results of the initial efforts of turning
the concepts and ideas, investigated as part of the Assert4Soa research agenda,
into a concrete workbench for prototyping and experimentation.
This chapter gives an overview of the approach to architectural design and
documentation we adopted in order to achieve the intended goals of the WP.
In Section 1.1, we start by detailing the purposes and the scope of the document,
by identifying its intended audience, and by providing some background on the
architecture documentation principles adopted in this deliverable.
Section 1.2 introduces the main architectural abstractions and primitives that we
used in the high-level design of the Assert4Soa framework, and covers the approach
we followed to allow the framework to be extended with additional pluggable components.
1.1
Overview
Purpose and scope
This document aims to provide a high-level description of the Assert4Soa architecture,
presenting its main functional elements by identifying their responsibilities, interfaces
and key interactions.
The emphasis of this document is on defining how the overall architecture can
realise the Assert4Soa vision and in particular, how its realisation can support
Asserts lifecycle, including their issuing, binding to service instances, update, revocation,
negotiation, and protection [9].
This document includes a specification of the high-level interaction mechanisms
(protocols, APIs) through which the different subsystems that make up the overall
Assert4Soa infrastructure communicate among each other and with the outside
world, namely with the three types of users of the system and the backend registries,
as illustrated in Figure 1.1. The focus here is on external characterisation of
D.6.1 - Architecture and High-level Design
5 / 87
Assert4Soa
Consumer
Discovery
Service Registry
Assert Issuer
Assert
Management
Assert4Soa Framework
System
Administration
Assert Registry
System Admin
Figure 1.1: Context Diagram
components and subsystems; a detailed description of component internals is provided
independently, in the deliverables produced by work packages 1 to 5.
As part of the architecture specification, we define a reference model for the data
types used in the framework; such model is meant to capture the semantics of the
Assert4Soa-specific data items flowing across the system.
Finally, this documents contains an accurate architecture-level analysis of security
threats, identifying corresponding security mechanisms that are needed to build a
system that is itself secure from the outset.
Intended audience
This document is mainly targeted at the following classes of stakeholders: a) developers
of the components of the Assert4Soa prototype, b) anyone else interested in
instantiating the Assert4Soa architectural framework into a concrete implementation
(alternative to the prototype developed in the scope of the project), c) security
evaluators who are interested in aligning their processes and tools with Assert4Soa,
especially to express the results of their assessments using the Assert language,
d) providers of matchmaking algorithms and components who wish to provide a
pluggable matchmaking component for the Assert4Soa framework, e) providers of
software development tools who wish to Assert-enable their IDEs, f) providers of
online service directories who wish to enhance them with Assert functionalities.
Not all the stakeholders are concerned by all views, and the interests of each
class of stakeholders lie in different aspects of the architecture. Based on practical
considerations, but also given the available timeframe and the organisation of the
project, we took the decision of prioritising some facets of the architecture documentation
(and therefore of some class of stakeholders), giving precedence to the views directly
affecting the realisation of the framework. We think it is highly desirable that the
Assert4Soa architecture document could address its broader audience. At the
same we believe that this can happen in a meaningful way only after a validation
D.6.1 - Architecture and High-level Design
6 / 87
Assert4Soa
of the architectural choices described here has been performed, based on an initial
implementation of a prototype.
Architecture Documentation Guidelines
The definition of an architecture for the Assert4Soa framework has followed established
practices, as documented, e.g.,in [27, 17, 19]. Architecture definition is known to be
an intrinsically fluid process: it starts early in the project lifecycle and must cope
with the fact that the scope and the detailed requirements of the system are not yet
clear or stable.
The uncertainty naturally associated with any such process is increased in a
collaborative research project such as Assert4Soa. While the general scope and
research orientation of the project are well defined, the theoretical and technical
directions that will be taken in the individual technical work packages are only
tentatively stated at this time. Indeed, it is part of the purposes of the project
itself to investigate and explore solutions that are not known, or are only partially
defined, a-priori.
Furthermore, actors from different organizations are involved in the design (and
later in the development), which makes full methodological and technological alignment
hard to guarantee. For these reasons, it is of paramount importance, in an architecture
documentation like this, to keep the focus on the high-level architectural principles
and overall structure, delaying to a later stage any attempt of providing finer-grained
specification and detailed technical choices. In particular, this document takes a
totally technology-independent approach, in order not to constrain the detailed
design before it is necessary.
The technological foundations of the prototype will be worked out as part of the
development to be done during Year 21 , and at that point the high-level decisions
documented here will be easier to validate, and possibly to refine and correct,
through the initial development activities of a prototype implementation of the
framework. In parallel, research in the other technical work packages will have
provided further indications on the optimal choices to take for the following developments.
All along the development phases, this document will be continuously used as
a reference, ensuring that the architecture style described later in this chapter is
strictly enforced in order to maintain good architectural qualities, and in particular
to enforce loose coupling to support extensibility and evolution. At the same time,
this is meant as a “living document”, that is subject to changes and updates to
reflect further insights gained all along the development phases. Such refinements
and amendments could be released as working documents accompanying the next
prototype deliverables.
We aimed at effectively communicating architectural abstractions by using standard
design notations and proper documentation structuring. Except for the “context
diagram” at page 6, for which an informal box-and-lines notation is used, throughout
the rest of the document, we adopt UML 2 [24] as the modelling formalism to
provide an intuitive, yet sufficiently precise, visual depiction of the structures and
mechanisms that are part of the architecture specification. In particular, UML
component diagrams are used to illustrate the general structure of the architecture,
providing both a “big picture” of the overall framework and a few zoom-in views that
allow to describe subsystems in separation, thus avoiding cluttering the larger view.
1 From
October 2011 to September 2012.
D.6.1 - Architecture and High-level Design
7 / 87
Assert4Soa
The behavioural aspect of the architecture is described by sequence diagrams, which
document the interaction mechanisms among components for a representative set of
use cases. A class diagram is used to illustrate the reference data model. Finally, a
set of activity diagrams complements the behavioural and the data model, linking
the two and emphasising the data flow.
Views, viewpoints, perspectives. Capturing all functionalities and the qualities of
a system in a single model that addresses the concerns of all stakeholders is known
to be extremely hard, if not impossible, for any non-trivial system.
An established solution to this problem, is to organise the architecture description
document as a set of coordinated architectural views, each representing one or more
structural or behavioural aspects of the architecture and addressing the concerns of
one or more stakeholders. Each view provides a description of the relevant aspects,
which are defined in a corresponding viewpoint.
In addition to the facets addressed by viewpoints, there are other concerns2 ,
of which performance and security are two typical examples, that cross-cut the
viewpoints and affect aspects that are already addressed by dedicated viewpoints.
For this reason, the notion of architectural perspective is used, as a way to project a
cross-cutting concern over a set of views. This approach to architecture documentation
based on the concepts of views, viewpoints, and perspectives is visually summarised
in the model in Figure 1.2, which depicts the relationships among the different
concepts used earlier in this section.
In the literature there exist several proposals of sets of viewpoints that an architecture
description should be composed of. This multi-view approach was first advocated
by David Parnas as early as in 1974 [25]. The literature of the last decades is rich
in proposals of methodologies to structure architectural documentation as a set of
architectural views. Among the most influential works, it is worth mentioning Perry
and Wolf’s seminal paper [26], Kruchten’s ”4+1 views”, which became part of the
Rational Unified Process (RUP) [22], and Soni et al. [30] who proposed a model
similar to Kruchten’s, organised in four views (also known as the ”Siemens Four
View model”).
The work by Rozanski et al. [27] advocates using a set of six viewpoints (functional,
information, concurrency, development, deployment, and operational) as an extension
of Kruchten’s model. Another book on the subject, by Clements et al. [17] proposes
another method, called “views and beyond”, which incorporates the use of architectural
views but emphasising the notion of documentation style. In this deliverable we
follow the guidelines from the latter two books [17, 27] as well as from IEEE Std1471-2000 [19], taking a pragmatic approach which strives for clarity and conciseness,
selecting only a small set of viewpoints and perspectives.
Document structure. Following the approach described earlier, the viewpoints adopted
in this document are the following two: a functional viewpoint and an information
viewpoint, presented in Chapters 2 and 3 respectively. The former describes the
overall structure and behaviour of the architecture, explaining which are the key
components of the system, and what key interaction they engage in. The latter
provides a precise description of the conceptual model and data flow that is subsumed
by the interactions among components.
2 Sometimes
referred to as non-functional, although the use of this term is somewhat controversial
D.6.1 - Architecture and High-level Design
8 / 87
Assert4Soa
Figure 1.2: Architectural views, viewpoints, and perspectives (from [27])
Orthogonally to these viewpoints, Chapter 4 examines the security perspective,
analysing the key threats that the framework should cope with, and describing the
security mechanisms that are built into the framework to this end.
Finally, Chapter 5 concludes the document by discussing the open points and the
directions that we intend to take in terms of technical solutions to be adopted for
the prototype development that will start at Year 2 of the project.
1.2
Architectural primitives and principles
Throughout this document we rely on a few established architectural primitives that
are commonly used to describe architectures in the so called “component&connector
(C&C) style” [17]. In a C&C architecture, components are the key architectural
element: they encapsulate computation and data storage and they are associated
with a specific function in the overall architecture. Components communicate with
the surrounding environment (external world or other architectural elements) through
their interfaces3 . Components can represent a structured subsystem and therefore
may contain a hierarchical sub-architecture. Connectors, on the other hand, represent
the channel over which inter-component communications take place. There exist
many types of connectors, each describing a particular interaction style (e.g., clientserver, publish-subscribe, filters, etc.). As part of this model, connectors can be used
as an abstraction capturing the routing policies that determine how components can
send messages to each other. In sophisticated types of connectors, such as today’s
Enterprise Service Buses [15], this capability can be used to realize advanced features,
3 More precisely, components interact through ports, offering or using the operations that are part of
interfaces associated to the ports. In this deliverable, we use a simplified model, omitting ports and
considering only interfaces.
D.6.1 - Architecture and High-level Design
9 / 87
Assert4Soa
such as dynamic reconfiguration, content-based message routing, monitoring, logging,
and access control.
The way in which components and connectors are assembled may be guided
by an architectural style, which is reflected in particular in the overall architecture
topology, and in the connector configuration. An architectural style imposes certain
restrictions on the allowed configurations of the system. By adopting a style, it
is possible to guarantee a-priori that certain desired architectural qualities are
preserved in the face of changes, as long as the style is preserved. This makes
is easier to avoid the phenomenon known as architectural drift, which leads to the
infringement of architectural principles and degradation of overall quality.
The style adopted in the Assert4Soa architecture is inspired to message-oriented
layered styles, along the lines of the one originally proposed in [34], called C2.
Essentially, in our architecture components are arranged in layers. The layering
is rigid, meaning that components of one layer are only allowed to communicate
to components of an adjacent layer4 . All interactions are mediated by connectors.
Each component is only attached to a single “up” connector (to which requests are
addressed), and a single “down” connector to which notifications are sent, which
simplifies enormously the logic of components and decouples them completely from
each other.
Request messages flow from the bottom to the top of the architecture (assuming
the layers are disposed horizontally), while notification messages flow in the opposite
direction, from the top to the bottom5 . All requests are asynchronous and they
are never explicitly addressed to a particular component, but it is the role of the
connectors, using their routing model, to determine what route a particular message
should take. As an example, a simplified layered architecture of Assert4Soa is
depicted in Figure 1.3. In that figure, UML components are used to denote both
components and connectors; the distinction between the two concepts is done using
two stereotypes6 . A description of the Assert4Soa functional architecture will
follow in Chapter 2.
Such a clear separation of computation from communication makes it possible to
achieve a high degree of flexibility exploiting a feature-rich communication infrastructure
to which several supporting functions are delegated. These include security and
management functions, such as fine-grained access control, logging and auditing,
monitoring, architecture adaptation (through run-time connector configuration) and
performance management.
Differently from the original proposal of [34], in our architecture, we also allow for
different types of requests, covering send-and-forget invocation (upstream) messages
as well as request-response interactions. The latter are still realized using an underlying
asynchronous messaging infrastructure, but closely mimicking the behaviour of synchronous
method invocations.
Adopting this style ensures high scalability and better support for evolution,
extremely low coupling among components, whose interactions rely on a common
data model (see Chapter 3) but not on direct, explicitly addressed communication.
4 By
“adjacent” we mean here “that can be reached using only connectors”. In Figure 1.3, the
Entry
Point and the Registry Abstraction Layer are adjacent.
5 This bottom-up orientation may be counter-intuitive, but it is kept here to be aligned with the works
on C2 where it is consistently used.
6 This is a well-known limitation of UML, which does not fully support rich connectors. The use of a
UML extension (profile) is a commonly adopted solution to this shortcoming.
D.6.1 - Architecture and High-level Design
10 / 87
Assert4Soa
Figure 1.3: Layered “component&connector” diagram of the Assert4Soa
architecture (some components omitted)
Plug-in based Architecture
The principles of loose coupling, extensibility, and flexibility are pursued in Assert4Soa
using the concept of plug-ins. Section 2.4 identifies the components that will be
integrated into the system as plug-in units, while this section describes the main
concepts underlying a plug-in based application and highlights the advantages of
this approach.
A plug-in based platform enables the extension of a core application with new
features implemented as components that are plugged into the core at start-up time
or even at run-time. Plug-in architectures are an attractive solution for developers
since they permit them to create applications that are modular, customizable and
easily extensible. In particular, a plug-in based platform provides the following main
benefits:
• Enables to add new features in the application quickly (also by third parties);
• Provides reusable building blocks;
• Permits to isolate and solve problem easily;
• Permits to create custom versions of an application without source code modifications.
D.6.1 - Architecture and High-level Design
11 / 87
Assert4Soa
Figure 1.4: The plug-in model
• Allows end-users to disable unwanted features reducing the application’s memory
consumption and improving performance.
As described in [38], an essential principle of a plug-in architecture is that the
system extensions are made in a controlled and determinate manner. In particular,
the plug-in model introduces the following notions:
• Extension Slot: specifies how an extension should occur;
• Extension: specifies how a plug-in makes its contribution to a slot.
The slots declare the types of information a plug-in expects and the extensions
fill this information slots accordingly. Therefore, the plug-in model require two basic
entities: the plug-in host application defining the slots and the plug-in contributor
(i.e. the plug-in itself).
Generally speaking, the host can be an application, an operating system or even
another plug-in structured in such a way that certain functionalities can be provided
using external modules. The host application operates independently of the plug-ins,
making it possible for end-users to add and update plug-ins dynamically without
the need of changing the host application. The collaboration between the host
and its contributor is defined in the form of required and provided interfaces. The
host defines the required interface and the extension contributor has to provide an
implementation for it.
Therefore, a plug-in is a deployable software unit, mainly self-contained and with
limited dependencies on other components, which has explicit specifications of its
slots and extensions as depicted in Figure 1.4.
Several existing systems adopt the plug-in concepts in order to provide modularity
and extensibility. The Eclipse Platform [16] is the most prominent representative of
the existing plug-in based platforms. It is built upon a small core and all further
functionalities are provided by a set of plug-ins. In particular, an Eclipse plug-in is
written in Java and is delivered as a JAR library. Manifest files, in XML format,
declare the inter-dependencies among the plug-ins (i.e. the connections between the
extension slots and the extensions).
The NetBeans [1] development environment, the main competitor of the Eclipse
Platform, also uses plug-ins. In NetBeans, each feature can be provided by a distinct
D.6.1 - Architecture and High-level Design
12 / 87
Assert4Soa
NetBeans module, which is comparable to a plug-in. A module is a group of Java
classes (i.e. JAR library) contained in a plug-in directory within the NetBeans
environment.
In Assert4Soa, our attention is focused on Eclipse and NetBeans platforms since
their current releases rely on the OSGi Service Platform [3]. The OSGi technology
is a Java-based framework that provides a service-oriented architecture allowing
applications to be constructed from small, reusable and collaborative components
that can be dynamically discovered and deployed. As mentioned in Chapter 5, the
OSGi technology is a possible solution to be adopted in order to apply the plug-in
concepts to the Assert4Soa framework.
D.6.1 - Architecture and High-level Design
13 / 87
Assert4Soa
Chapter 2
Functional View
This chapter presents the functional view of the Assert4Soa architecture. The
functional view has been elaborated starting from the reference use cases, which are
documented in detail in Deliverable 7.1 [8]. Use cases related to Service Discovery
are treated here as one single use case. The detailed breakdown of use cases done
in D.7.1 is mostly relevant for the detailed work done on the discovery engine in the
context of WP2; for the purposes of this document, we considered sufficient to treat
them in a unified manner.
For each of these use cases, we describe how they are realized in terms of
interactions among components (Section 2.1. The responsibilities and operations of
components are systematically documented in the component catalog (Section 2.3).
The semantics of the data types used for specifying operation parameters are defined
in the Information View, in the next chapter.
2.1
From use cases to architectural mechanisms
In this document, we concentrate on the following use cases, documenting how the
user-system interactions that they represent translate into operations internally to
the system:
• Authentication
• Assert Management
• System Administration
• Service Discovery
The main flows derived from these use cases are detailed in the following and are
documented using UML sequence diagrams. Complex interactions are broken down
in interaction fragments for the sake of readability.
In particular, a separate sequence diagram is provided to describe the following
interactions:
• Consumer Query Formulation
• Service Composition
• Matchmaking
D.6.1 - Architecture and High-level Design
14 / 87
Assert4Soa
• Service Discovery
The sequence diagrams of this section are designed with the following simplifying
assumptions: messages are specified at an abstract level (as in the component
catalog), and they are not to be interpreted as implementation-level specifications.
The goal of this depiction is to provide an implementation-neutral, concise, and
informative description of the flow of control and of information among the components.
Based on the same rationale, all messages are shown as synchronous as this simplifies
the description of the scenarios. Technical considerations related to the concurrency
model, component technology, and deployment platform may suggest that some
interactions are better realised in a non-blocking fashion. While this aspect is
certainly important, the information available at this stage of the project is still
too limited to make informed decisions. As of this writing, initial discussions on
this issue are ongoing, and some tentative directions are sketched in Chapter 5.
However, the above mentioned issues (concurrency model, component technology,
deployment configurations and platform) will be addressed in depth only at a later
stage, when we start validating the architecture proposed in this document. For the
same reason, all messages exchanged between any two components are also modelled
independently of the concrete messaging mechanism that will be adopted for actually
sending and dispatching invocations, responses, and notifications. This is possible
because the architecture adopts from the outset a strict separation of concerns,
whereby all inter-components communications (and therefore, the communication
style) are delegated to connectors, as explained in Section 1.2.
Authentication
A Service Based Application invokes the Consumer Agent by using the login method
in order to initiate the authentication process and passes its user credentials to the
method. The Consumer Agent invokes the Entry Point of the Assert4Soa framework
by using the authenticateUser method and passes the user credentials. The Entry
Point performs the authentication and returns a message that contains the result
of the authentication process which is then returned back to the Service Based
Application through the Consumer Agent. This interaction is shown in Figure 2.1.
In addition to the above mentioned scenario, authentication is used in the system
administration and assert management use cases. The sequence diagrams for these
two use interactions are shown in Figure 2.2 and Figure 2.3.
Assert Management An Assert Issuer can issue, revoke, update Asserts for
services. The sequence diagram for the interactions of the Assert Issuer with the
Assert Registry through the Assert4Soa Framework is shown in Figure 2.2.
The Assert Issuer uses the login method of the Assert Issuing Tool to authenticate
with the Assert4Soa framework. The Assert Issuing Tool uses the authenticateUser
method of the Entry Point to perform the authentication process. If the authentication
is successful, the Assert Issuer uses the Assert Issuing Tool and performs an action
such as issuing, revoking or updating an Assert. The Assert Issuing Tool sends a
AssertManagementOperation message to the Entry Point of the Assert4Soa Framework
by using the manageAssert method. The Entry Point identifies the Assert Issuer
and forwards this message to the Registry Abstraction Layer using the manageAssert
method. The Registry Abstraction Layer processes this information and updates the
Assert Registry accordingly and sends a message informing the successful completion
D.6.1 - Architecture and High-level Design
15 / 87
Assert4Soa
Figure 2.1: Authentication Sequence Diagram
Figure 2.2: Assert Management Sequence Diagram
D.6.1 - Architecture and High-level Design
16 / 87
Assert4Soa
Figure 2.3: System Administration Sequence Diagram
of the operation. If there is any error at any stage in this process, the responsible
component (Assert Management Tool, Entry Point, Registry Abstraction Layer) informs
the Assert Issuer of the error.
System Administration
The Assert4Soa Framework is maintained by the System Administrator. The
interaction of the System Administrator with the Assert4Soa Framework is shown
in the Figure 2.3.
The System Administrator uses the System Administration Console to authenticate
himself to the Assert4Soa Framework by using the login method of the Entry Point.
If the authentication is successful, the System Administrator performs the System
administration tasks using the manageSystem method of the Entry Point. The Entry
Point invokes the manageSystem method of the System Administration component to
perform those administration tasks and the result of the operation is reported back
to the System Administrator.
Service Discovery The service discovery interaction presented here encompasses
the different use cases related to service discovery in [8] (such as proactive, reactive
service discovery).
The Service Based Application (SBA), uses the Consumer Agent to formulate the
query for service discovery. The Consumer Agent then sends the Consu2merQuery
to the Entry Point of the Assert4Soa Framework by invoking the method sendQuery.
The Entry Point forwards the ConsumerQuery to the Query Handler using submitQuery
method. The Query Handler processes the ConsumerQuery and sends a ServiceDiscoveryQuery
to the Discovery Manager through the findService method. The Discovery Manager
fetches the services that match the functional requirements and the Asserts associated
D.6.1 - Architecture and High-level Design
17 / 87
Assert4Soa
to them by invoking the retrieveServices method of the Registry Abstraction Layer.
The Discovery Manager performs some additional functional matchmaking (behavioural,
structural and constraint matchmaking) on the services. If no single services match
the functional requirements of the consumer, the discovery manager initiates the
composition process, and receives a list of service compositions. The Discovery
Manager starts the security matchmaking process by invoking the matchServices
method of the Master Matchmaker and passing the list of candidate services along
with the requirements and the strategy that has to be followed in performing the
matchmaking. Finally, the discovery manager invokes the Assert Verifier component
to verify the validity of the Asserts using the method verifyAssert. The ranked list
of services that have valid Asserts and match the functional, security requirements
returned back to the Consumer Agent which displays this information to the consumer.
For the sake of readability, in the service discovery sequence diagram (Figure 2.4)
some interactions have been abstracted away as referenced interactions. These
referenced interactions are presented below.
Consumer Query Formulation As shown in the sequence diagram in Figure 2.5,
a Service Based Application (SBA) can use the Preference Store to set the security
preferences using the setPreferences method. The SBA also uses the Trust Manager
component to set the trust preferences using the setTrustRelations method. The
SBA uses the Consumer Agent to authenticate with the Assert4Soa Framework
through the login method. And the Consumer Agent authenticates the user by
invoking the authenticateUser method of the Entry Point. When the SBA needs a
service, it uses the lookup method of the Consumer Agent and passes the requirements
(functional, security and trust related). The Consumer Agent fetches the preferences
of the SBA from the Preference Store by using the method getPreferences and also
the trust preferences by using the getTrustRelations method of the Trust Manager
component. It then composes a query and sends the query to the Entry Point using
the sendQuery method.
Service Composition When the Discover Manager does not find any atomic service
that matches the functional requirements or when the services that match the
functional requirements are less than the specified number, it invokes the service
composition process by calling the Composition Manager using the findComposition
method and passing the requirements as input. The Composition Manager then
invokes the fetchPatterns method to find the composition patterns that match the
functional requirements. The Composition Manager fills the patterns with actual
services by using the Discovery Manager. Finally, the discovery manager creates a
virtual assert for the composition and returns it to the Discovery Manager, which
performs the matchmaking process on these Virtual Asserts. This process is shown
in the Figure 2.6.
Matchmaking The Discovery Manager when it has a list of CandidateService[] or
CompositeService that match the functional requirements of the consumer, it has
to rank these services based on their security properties and in order to do this
it starts the Matchmaking process. The matchmaking process is initiated by the
Discovery Manager which invokes the Master Matchmaker using the matchServices
method and passing the list of CandidateService and the requirements along with
the Strategy as input. The Master Matchmaker analyses the strategy by using a
method analyzeStrategy and passes the strategy as an input. This method returns a
list of slave matchmakers that will be invoked and the order in which they must be
D.6.1 - Architecture and High-level Design
18 / 87
Assert4Soa
Figure 2.4: Service Discovery Sequence Diagram
D.6.1 - Architecture and High-level Design
19 / 87
Assert4Soa
Figure 2.5: Query Composition Sequence Diagram
Figure 2.6: Service Composition Sequence Diagram
D.6.1 - Architecture and High-level Design
20 / 87
Assert4Soa
Figure 2.7: Matchmaking Sequence Diagram
invoked and the information related on how the results from each matchmaker has
to be combined to find the overall rank of a service. Then the Master Matchmaker
invokes the corresponding slave matchmakers by using the rankServices method
and passing the candidate services that must be ranked by the respective slave
matchmaker. Finally, the Master Matchmaker invokes the Assert Verifier component
to verify the Asserts of each service. This process is shown in the Figure 2.7.
2.2
Architecture overview
There is an inherent structure emerging from the interactions described in the
previous section. Describing this structure by modular decomposition is the first
step towards defining the precise responsibilities and functionalities of the individual
architecture elements (which is done in the next section). A the highest level of
abstraction, the Assert4Soa architecture can be thought of as a composition of a
small set of modules, each related to a specific core functional area. These modules
are depicted in Figure 2.2 and are briefly described below.
Assert management Components related to the issuing, update, revocation, and
registration of Asserts.
Query Handling Components dealing with the parsing of consumer queries and
with the handling of response channels through which query results are made
available to consumers.
D.6.1 - Architecture and High-level Design
21 / 87
Assert4Soa
Service Composition Components concerned with the synthesis of service composition
and with the storage and handling of service composition patterns.
Matchmaking Components related to the matchmaking process.
Access to backend registries Components that realise an abstraction layer on
top of existing back-end service registries.
Assert verification Components enabling the verification of the validity of an
Assert.
Ontology-based reasoning Components providing access to ontologies and reasoners.
Framework management Components offering management functionalities to system
administrators, including system monitoring and configuration, performance
monitoring.
Framework protection Components dedicated to the security of the framework,
including user management, access control, and secure logging.
Main architectural functional areas
It is important to remark that the functions related to the latter two functional
modules are also supported by features provided by the connectors.
Assert
management
Query
Handling
Service
composition
Matchmaking
Access to Backend
registries
Assert
verification
Ontology-based
reasoning
Framework
Management
Framework
Protection
Figure 2.8: High-level functional decomposition of the Assert4Soa framework
11
D.6.1 - Architecture and High-level Design
Assert4Soa - Bruxelles 17 May 2011 - M6 Review
22 / 87
Assert4Soa
Figure 2.9: Architecture overview
D.6.1 - Architecture and High-level Design
23 / 87
Assert4Soa
2.3
Component catalog
This section presents a systematic description of each of the components that make
up the Assert4Soa architecture, illustrated in Figure 2.9. For each component, in
addition to a short description of its purpose, we document the expected inputs and
the outputs provided by the component, as well as, where appropriate, assumptions,
and dependencies or interactions with other components.
Describing the internal structure and behaviour of the individual components
and subsystems is beyond the scope of an architectural description, and we do not
address it in this document. The reader is refererred to the deliverables of the other
technical work packages for those descriptions. To ehnance the readability of this
document, we include a brief appendix mapping the main architectural elements
defined here onto the corresponding deliverables1 .
For the sake of completeness, all components are described here; however, those
that are specifically related to the security of the framework are discussed in more
detail in the Security Perspective (Chapter 4).
Entry Point
Any interaction with the Assert4Soa framework will be through the Entry Point.
Properties
Dependencies
Query Handler, System Administration, Registry
Abstraction
Layer,
Consumer
Agent,System
Administration Console, Assert Issuing Tool
Operations
sendQuery
It receives the query from the consumer agent and dispatches it to the Query
Handler.
Input Parameters
Name
Type
Query
ConsumerQuery
Output Parameters
Name
Type
RankedCandidateService[]
ServiceList
1 At
Description
Containing functional, security
requirements that must hold
in the services and the query
subscription information
Description
Ranked list of services and their
Asserts based on their functional
and security properties
the time of this writing, some of these deliverables have not been released to the public yet.
D.6.1 - Architecture and High-level Design
24 / 87
Assert4Soa
authenticateUser
It receives the user credentials from the Consumer Agent, Assert Issuing Tool and
System Administration Console and performs the authentication.
Input Parameters
Name
Type
UC
UserCredentials
Output Parameters
Name
Type
OpResult
OperationResult
Description
Contains the user credentials,
that can be the username token,
password digest etc
Description
Contains the
operation
result
of
the
manageSystem
Allows an authenticated system administrator to perform the administration
tasks of the framework.
Input Parameters
Name
Type
MO
ManagementOperation
Output Parameters
Name
Type
OpResult
OperationResult
Description
Operation that has to be
performed by the administrator
of the framework
Description
Contains the
Operation
status
of
the
manageAssert
Allows an authenticated Assert Issuer to perform the administration tasks on the
certificates, such as revoking, updating or issuing new certificates.
Input Parameters
Name
Type
AM
AssertManagementOperation
Output Parameters
Name
Type
OpResult
OperationResult
D.6.1 - Architecture and High-level Design
Description
Contains
the
Assert,
AssertIdentifier,
Operation
performed on the Assert such as
issue, revoke or update
Description
Contains the
Operation
status
of
the
25 / 87
Assert4Soa
Query Handler
The Query Handler is responsible to receive the complex query through the Entry
Point. It parses and checks the validity of the received query and passes the query to
the service Discovery Manager to execute the query. It also manages the subscription
of queries. It maintains a buffer of the best N ranked services returned by the
Discovery Manager and returns the first service in the buffer to the client. If the
number of services in the buffer falls below a specific threshold, it re-executes the
query.
Properties
Dependencies
Discovery Manager, Entry Point
Operations
submitQuery
Receives a query and checks its validity. Manages the query subscriptions.
Input Parameters
Name
Type
Query
ConsumerQuery
Output Parameters
Name
Type
RankedServiceCandidateService[]
List
Description
Containing functional, security
requirements
as
well
as
subscription period, mode of
subscription/consumption (push,
pull)
Description
Ranked list of services and their
Asserts based on their functional
and security properties
Discovery Manager
The Discovery Manager orchestrates the functionality offered by the other components
involved in the service discovery process. It receives complex queries and passes to
the Master Matchmaker to execute the queries. It also contacts the Registry Abstraction
Layer to retrieve the available services to be considered for match making.If the
Registry Abstraction Layer does not return any candidate service for matchmaking, the
Discovery Manager builds some new queries through patterns of service composition
(if composition is allowed by the query) and sends the new query to the Composition
Manger to find composite service.
D.6.1 - Architecture and High-level Design
26 / 87
Assert4Soa
Properties
Dependencies
Registry Abstraction Layer, Master Matchmaker,
Composition Manager,Ontology Manager,Assert Verifier,
Query Handler
Operations
findService
Executes a complex query and returns a list of candidate services returned by
the matchmaking process.
Input Parameters
Name
Type
SDQuery
ServiceDiscoveryQuery
Output Parameters
Name
Type
RankedServiceList CandidateService[]
Description
Containing functional, security
requirements
Description
Ranked list of services and their
Asserts based on their functional
and security properties
Registry Abstraction Layer
This component provides an interface that abstracts the service registries (such
as UDDI, ebXML) and Assert registries from the other components in the framework
and provides a uniform interface for them to use to find services or asserts.
Properties
Dependencies
Discovery Manager, Master Matchmaker,
Management, External Registries
Pre-conditions
An Assert Registry and a Service Registry adaptor
must be available for the registry abstraction layer
D.6.1 - Architecture and High-level Design
Assert
27 / 87
Assert4Soa
Operations
retrieveServices
Retrieve services based on the functional requirements in the query
Input Parameters
Name
Type
FnReq
FunctionalRequirement[]
Output Parameters
Name
Type
ServiceList
CandidateService[]
Description
Functional Requirements of the
consumer
Description
List of Services along with their
Asserts that match the functional
requirements
findService
Retrieve services based on the functional requirements in the query
Input Parameters
Name
Type
SRQuery
ServiceRegistryQuery
Output Parameters
Name
Type
ServiceList
Service[]
Description
The service registry query
containing
the
functional
requirements to fetch services
from a particular registry
Description
List of services that match
fetchAssert
Retrieve Asserts based on the service identifier (WSDL,Service Endpoint etc).
For a service having more than one assert, this function retrieves all the Assert.
Input Parameters
Name
Type
WebServiceURI
Identifier
Output Parameters
Name
Type
AssertList
Assert[]
D.6.1 - Architecture and High-level Design
Description
Web service unique identifier
Description
List of all the Asserts of a service
28 / 87
Assert4Soa
manageAssert
Assert Issuers use the Assert4Soa Framework to manage - register, revoke,
update - the Asserts that they issue for services.
Input Parameters
Name
Type
AM
AssertManagement
Output Parameters
Name
Type
OpResult
OperationResult
Description
Contains the Assert Identifier,
Assert, Operation performed on
the assert (update, revoke, issue)
along with the Assert issuer
identifier
Description
Contains the
operation
result
of
the
Master Matchmaker
The Master Matchmaker is responsible to evaluate the different criteria of a query
(e.g. structural, behavioural, contextual, QoS and security related criteria) against
a list of services and to compute the distance between a query and candidate.
Properties
Dependencies
Discovery Manager, Slave Matchmakers
Operations
matchServices
Executes a complex query by delegating appropriate slave match makers such as
Behavioural Matchmaker, Structural Matchmaker, Constraint Matchmaker, AssertM Matchmaker, Assert-E Matchmaker, Assert-O Matchmaker etc and orders the list of
D.6.1 - Architecture and High-level Design
29 / 87
Assert4Soa
the candidate services returned by different match makers.
Input Parameters
Name
Type
ServiceList
CandidateService[]
Requirements
Requirement[]
Strategy
Strategy
Output Parameters
Name
Type
RankedServiceList CandidateService[]
Description
List of services along with their
asserts that have to be ranked
List of Requirements of the
consumer
Strategy that has to be followed
by the master matchmaker
Description
Ranked List of services that
match the functional and security
requirements
Composition Manager
The Composition Manager is responsible to receive a query along with composition
patterns and build up compositions of services by applying the composition patterns
that satisfy the discovery query.
Properties
Dependencies
Discovery Manager
Operations
findComposition
Receives a query and compositions patterns and builds up service compositions
according to the composition patterns that satisfies the query.
Input Parameters
Name
Type
Requirements
Requirement[]
Output Parameters
Name
Type
Compositions
CompositeService[]
Description
Containing requirements of the
consumer
Description
List of Composite Services
that match the functional
requirements
Assert-O Matchmaker
The Assert-O Matchmaker is a slave matchmaker component of the Matchmaker
Subsystem. The scope of this component is to filter and rank the list of candidate
D.6.1 - Architecture and High-level Design
30 / 87
Assert4Soa
services, retrieved during the discovery process, according to their degree of fit
with the security property requested by the consumer agent. In particular, this
component uses the Assert-O certificates to discard from the list of candidate services
those that do not match the security assurance requirement and to sorts the Candidate
Services that match the security requirements according to their degree of fit.
Properties
Dependencies
Master Matchmaker, Ontology Manager
Operations
rankServices
Using Assert-O certificates, ranks the candidate services according to the degree
of fit to the required security properties.
Input Parameters
Name
Type
serviceList
CandidateService[]
SecuritySecurityRequirement[]
Requirements
Output Parameters
Name
Type
serviceList
CandidateService[]
Description
Candidate Services
Security Requirements
Description
Ranked List of services
Assert-E Matchmaker
The Assert-E Matchmaker is a slave matchmaker component of the Matchmaker
Subsystem. The scope of this component is to filter and rank the list of candidate
services, retrieved during the discovery process, according to their degree of fit
with the security requirement requested by the consumer agent. In particular, this
component uses the Assert-E certificates and discards from the list of candidate
services those that do not match the security assurance requirement and to sorts the
Candidate Services that match the security requirements according to their degree
of fit.
Properties
Dependencies
Pre-Conditions
Post-Conditions
Master Matchmaker, Ontology Manager
All service URIs are accessible during the Assert-E
matchmaking process.
The query only contains restrictions on Assert-E
certificates
A subset of the URIs given as input is returned as
output
D.6.1 - Architecture and High-level Design
31 / 87
Assert4Soa
Operations
rankServices
It is the single API exposed to the Master MM. It implements the Assert-E
matchmaker, that is, it receives a set of URIs and a query and returns a subset of
URIs in a partial order.
Input Parameters
Name
Type
serviceList
CandidateService[]
SecuritySecurityRequirement[]
Requirements
Output Parameters
Name
Type
serviceList
CandidateService[]
Description
Candidate Services
Security Requirements
Description
Ranked List of services
Assert-M Matchmaker
The Assert-M Matchmaker is a slave matchmaker component of the Matchmaker
Subsystem. The scope of this component is to filter and rank the list of candidate
services, retrieved during the discovery process, according to their degree of fit
with the security requirement requested by the consumer agent. In particular, this
component uses the Assert-M certificates and discards from the list of candidate
services those that do not match the security assurance requirement and to sorts the
Candidate Services that match the security requirements according to their degree
of fit.
Properties
Dependencies
Pre-Conditions
Master Matchmaker, Ontology Manager
ComparisonRuleSet provided - either as a JAR with
Comparators or as a small Database (e.g sqlite)
D.6.1 - Architecture and High-level Design
32 / 87
Assert4Soa
Operations
rankServices
Perform Matchmaking of required vs provided properties and return list.
Input Parameters
Name
Type
serviceList
CandidateService[]
SecuritySecurityRequirement[]
Requirements
Output Parameters
Name
Type
serviceList
CandidateService[]
Description
Candidate Services
Security Requirements
Description
Ranked List of services
Assert Verifier
The Assert Verifier is responsible to check the validity of the Asserts. In particular,
it checks that the data, common to the different types of Assert (e.g. expiration
time, digital signature etc...), are valid. This main functionality provided by the
Assert Verifier can be extended in order to verify also the information specific of the
Assert-E, Assert-M and Assert-O certificates.
Properties
Dependencies
Discovery Manager, Ontology Manager, Slave Verifiers,
Trust Manager
verifyAssert
Verify the validity of Assert
Input Parameters
Name
Type
AssertCertificate Assert
Output Parameters
Name
Type
OpResult
OperationResult
D.6.1 - Architecture and High-level Design
Description
Assert that has to be validated
Description
Result
of
operation
the
verification
33 / 87
Assert4Soa
isTrustedAssert
Check the validity of the Assert based on predefined or client-specified Trust
Preferences (Trust Roots)
Input Parameters
Name
Type
AssertCertificate Assert
TrustRelations
TrustPreferences
Output Parameters
Name
Type
OpResult
OperationResult
Description
Assert that has to be validated
The predefined or client specified
trust preferences
Description
Result
of
operation
the
verification
Assert-O Verifier
The Assert-O Verifier component is responsible to check the consistency of the
model of the services and the security property asserted in the Assert-O certificate.
Properties
Dependencies
Ontology Manager, Assert Verifier
Operations
verifyAssert
Verifies that the model of the service and the security property asserted in the
Assert-O certificates are consistent.
Input Parameters
Name
Type
assert
Assert-O
Output Parameters
Name
Type
result
boolean
Description
The Assert-O certificate
Description
The result of the AssertO verification.
True if the
verification is successful, false
otherwise.
Assert-M Verifier
The Assert-M Verifier component is responsible to check the consistency of the
model of the services and the security property asserted in the Assert-M certificate.
D.6.1 - Architecture and High-level Design
34 / 87
Assert4Soa
Properties
Dependencies
Ontology Manager, Assert Verifier
Operations
verifyAssert
Verifies that the model of the service and the security property asserted in the
Assert-M certificates are consistent.
Input Parameters
Name
Type
assert
Assert-M
Output Parameters
Name
Type
result
boolean
Description
The Assert-M certificate
Description
The result of the AssertM verification.
True if the
verification is successful, false
otherwise.
Assert-E Verifier
The Assert-E Verifier component is responsible to check the consistency of the
model of the services and the security property asserted in the Assert-E certificate.
Properties
Dependencies
Ontology Manager, Assert Verifier
Operations
verifyAssert
Verifies that the model of the service and the security property asserted in the
Assert-E certificates are consistent.
Input Parameters
Name
Type
assert
Assert-E
Output Parameters
Name
Type
result
boolean
D.6.1 - Architecture and High-level Design
Description
The Assert-E certificate
Description
The result of the AssertE verification.
True if the
verification is successful, false
otherwise.
35 / 87
Assert4Soa
Preference Store
This is the client-side component that is used by the client to store the preferences
and by the Consumer Agent to fetch them to formulate the query for lookup of
services.
Properties
Dependencies
Pre-Conditions
Consumer Agent, Service Based Application
A means to store the preferences either in the form of
a simple DB or flat file or relational DB is supposed
to be available
Operations
setPreferences
Store the preferences of the users - preferences can be either about security
properties or about the trust relationships with third parties
Input Parameters
Name
Type
pref
Preferences
Description
Consumer security
preferences
and
QoS
getPreferences
Store the preferences of the users - preferences can be either about security
properties or about the trust relationships with third parties
Output Parameters
Name
Type
Pref
Preferences
Description
Preferences of the consumer,
returns null if not set
Trust Manager
This component is used to store the trust relationships and preferences, as well
as to reason about them. This is can be used both on the consumer side (e.g., by
the Consumer Agent when formulating the query for lookup) as well as by server-side
components as explained in more detail in Chapter 4.
Properties
Dependencies
Pre-Conditions
Consumer Agent,
Assert Verifier, Service Based
Application
A means to store the preferences either in the form of
a simple DB or flat file or relational DB is supposed
to be available
D.6.1 - Architecture and High-level Design
36 / 87
Assert4Soa
Operations
setTrustRelations
Store the trust preferences of the users - trust preferences can be on the Certification
Authorities, the platform providers, the service providers and so on.
Input Parameters
Name
Type
trustpref
TrustPreferences
Description
Trust
Preferences
Consumer
of
the
getTrustRelations
retrieve the trust preferences of the consumer
Output Parameters
Name
Type
trustPref
TrustPreferences
Description
Trust
Preferences
of
the
consumer, returns null if not
set
Consumer Agent
This is the client-side component through which SBAs (or human consumers)
access the server-side framework to use its (assert-aware) discovery functions. The
Consumer Agent formulates queries, combining the request coming as its input with
the preferences persisted in a preference store.Such queries are then sent to the
server-side (entry point component).
Properties
Dependencies
Assumptions
Consumer Agent, Service Based Application
The server knows the URI to communicate with the
Agent
And the server is up and running
D.6.1 - Architecture and High-level Design
37 / 87
Assert4Soa
Operations
lookup
This is the method through which clients use the discovery feature of the framework
Input Parameters
Name
Type
requirements
Requirements
Output Parameters
Name
Type
RankedServiceCandidateService[]
List
Description
Client requirements consist of
both security and functional
aspects
Description
The list of services along with
their Asserts that is ranked
according to the degree of fit of
a service on both the functional
and security requirements of the
user
composeQuery
The consumer agent composes a query that includes the requirements, preferences
and trust preferences of the consumer.
Input Parameters
Name
Type
requirements
Requirements
pref
Preferences
trustpref
TrustPreferences
Output Parameters
Name
Type
Query
ConsumerQuery
Description
Client requirements consist of
both security and functional
aspects
Consumer security and QoS
preferences
Trust
Preferences
of
the
Consumer
Description
Containing functional, security
requirements that must hold
in the services and the query
subscription information
System Administration
All administration task of the Assert4Soa framework will be performed through
the System Administration component. These tasks include the configuration of
the system, the management of plugins, the configuration of connectors, and the
administration of users. Additionally, this component will provide monitoring functions
D.6.1 - Architecture and High-level Design
38 / 87
Assert4Soa
(e.g., performance monitoring) by collecting raw monitoring information coming
from the connectors.
Properties
Dependencies
Entry Point
Operations
manageSystem
This allows an authenticated system administrator to perform administration
tasks of the framework.
Input Parameters
Name
Type
mo
ManagementOperation
Output Parameters
Name
Type
opResult
OperationResult
Description
Contains the operation to be
performed and the information
to
perform
the
operation
successfully
Description
Result
of
the
system
administration operation
System Administration Console
The Assert4Soa Framework System Administrator maintains the framework
by using the System Administration Console.
Properties
Dependencies
Entry Point
D.6.1 - Architecture and High-level Design
39 / 87
Assert4Soa
Operations
login
This allows a system administrator to authenticate with Assert4Soa Framework.
Input Parameters
Name
Type
UC
UserCredentials
Output Parameters
Name
Type
OpResult
OperationResult
Description
Contains the user credentials,
that can be the username token,
password digest etc
Description
Contains the
operation
result
of
the
manageSystem
This allows an authenticated system administrator to perform administration
tasks of the framework.
Input Parameters
Name
Type
mo
ManagementOperation
Output Parameters
Name
Type
opResult
OperationResult
Description
Contains the operation to be
performed and the information
to
perform
the
operation
successfully
Description
Result
of
the
system
administration operation
Assert Issuing Tool
Assert Issuing Tool allows issuers to create and manage Asserts. It provides a
user friendly interface which allows Assert Issuers to create, update and revoke
Asserts.
Properties
Dependencies
Entry Point
D.6.1 - Architecture and High-level Design
40 / 87
Assert4Soa
Operations
manageAssert
This allows the Assert Issuer to manage the Asserts
Input Parameters
Name
Type
AMO
AssertManagementOperation
Output Parameters
Name
Type
OpResult
OperationResult
Description
Contains
the
Assert,
AssertIdentifier,
Operation
performed on the Assert such as
issue, revoke or update
Description
Contains the
operation
result
of
the
Ontology Manager
The Ontology Manager component is responsible for interacting with the Assert
Ontology [7] developed in the Assert4Soa framework. In particular, it provides a
set of functionalities for browsing and reasoning with the ontology in order to ensure
that the common inference problems described in [4] are considered.
The table 2.1 summarizes the inference problems achieved by the Ontology Manager
providing, for each of them, an example of the related functionality.
Inference Problem
Ontology Consistency
Ontology Entailment
Ontology Equivalence
Ontology Equisatisfiability
Class Expression Satisfiability
Class Expression Subsumption
Instance Checking
Functionality
isOntologyConsistent
isOntologyEntailed
isEquivalentClass
isClassSatisfiable
isClassExpSatisfiable
isSubClassOf
isIndividualInstanceOf
Table 2.1: The inference problems achieved by the Ontology Manager functionalities
Properties
Dependencies
Master Matchmaker, Assert Verifier, Assert Issuing Tool
D.6.1 - Architecture and High-level Design
41 / 87
Assert4Soa
Operations
isAxiomEntailed
Verifies if an axiom is entailed by the set of reasoner axioms.
Input Parameters
Name
Type
axiom
OWLAxiom
Output Parameters
Name
Type
result
boolean
Description
The axiom to check
Description
The result of the verification.
True if the verification is
successful, false otherwise
isClassDefined
Verifies if a class is defined in the ontology.
Input Parameters
Name
Type
class
OWLClass
Output Parameters
Name
Type
result
boolean
Description
The class to check
Description
The result of the verification.
True if the class is defined, false
otherwise.
isClassExpSatisfiable
Verifies if a class expression is satisfiable.
Input Parameters
Name
Type
classExp
OWLClassExpression
Output Parameters
Name
Type
result
boolean
D.6.1 - Architecture and High-level Design
Description
The class expression to check
Description
The result of the verification.
True if the class expression is
satisfiable, false otherwise.
42 / 87
Assert4Soa
isClassSatisfiable
Verifies if a class is satisfiable.
Input Parameters
Name
Type
classDescr
OWLDescription
Output Parameters
Name
Type
result
boolean
Description
The description of the class to
check
Description
The result of the verification.
True if the class is satisfiable, false
otherwise.
isDataPropertyDefined
Verifies if a data property is defined in the ontology.
Input Parameters
Name
Type
dataProperty
OWLDataProperty
Output Parameters
Name
Type
result
boolean
Description
The data property to check
Description
The result of the verification.
True if the data property is
defined, false otherwise.
isEquivalentClass
Verifies if a class is equivalent to another class.
Input Parameters
Name
Type
classA
OWLDescription
classB
OWLDescription
Output Parameters
Name
Type
result
boolean
D.6.1 - Architecture and High-level Design
Description
The description of the first class
The description of the second
class
Description
The result of the verification.
True if the first class is equivalent
to the second class, false
otherwise.
43 / 87
Assert4Soa
isEquivalentDataProperty
Verifies if a data property is equivalent to another data property.
Input Parameters
Name
Type
dataPropertyA
OWLDataProperty
dataPropertyB
OWLDataProperty
Output Parameters
Name
Type
result
boolean
Description
The first data property
The second data property
Description
The result of the verification.
True if the first data property
is equivalent to the second data
property, false otherwise.
isEquivalentObjectProperty
Verifies if an object property is equivalent to another object property.
Input Parameters
Name
Type
objectPropertyA OWLObjectProperty
objectPropertyB OWLObjectProperty
Output Parameters
Name
Type
result
boolean
Description
The first object property
The second object property
Description
The result of the verification.
True if the first object property
is equivalent to the second object
property, false otherwise.
isIndividualDefined
Verifies if an individual is defined in the ontology.
Input Parameters
Name
Type
individual
OWLIndividual
Output Parameters
Name
Type
result
boolean
D.6.1 - Architecture and High-level Design
Description
The individual to check
Description
The result of the verification.
True if the individual is defined
in the ontology, false otherwise.
44 / 87
Assert4Soa
isIndividualInstanceOf
Verifies if an individual is an instance of a class type.
Input Parameters
Name
Type
individual
OWLIndividual
type
OWLDescription
direct
boolean
Output Parameters
Name
Type
result
boolean
Description
The individual to check
The description of the class type
This is an optional parameter. If
it is true the operation verifies if
the individual is a direct instance
of the given type
Description
The result of the verification.
True if the individual is an
instance (or a direct instance) of
the given type, false otherwise.
isLoadedOntologyConsistent
Verifies if the loaded ontology is consistent.
Output Parameters
Name
Type
result
boolean
Description
The result of the consistency
verification.
True if the
verification is successful, false
otherwise.
isObjectPropertyDefined
Verifies if an object property is defined in the ontology.
Input Parameters
Name
Type
objectProperty
OWLObjectProperty
Output Parameters
Name
Type
result
boolean
D.6.1 - Architecture and High-level Design
Description
The object property to check
Description
The result of the verification.
True if the object property is
defined, false otherwise.
45 / 87
Assert4Soa
isOntologyConsistent
Verifies if an ontology is consistent.
Input Parameters
Name
Type
ontology
OWLOntology
Output Parameters
Name
Type
result
boolean
Description
The ontology to check
Description
The result of the consistency
verification.
True if the
verification is successful, false
otherwise.
isOntologyEntailed
Verifies if an ontology is entailed.
Input Parameters
Name
Type
ontology
OWLOntology
Output Parameters
Name
Type
result
boolean
Description
The ontology to check
Description
The result of the consistency
verification.
True if the
verification is successful, false
otherwise.
isSameAsIndividual
Verifies if two individuals are the same.
Input Parameters
Name
Type
individualA
OWLIndividual
individualB
OWLIndividual
Output Parameters
Name
Type
result
boolean
D.6.1 - Architecture and High-level Design
Description
The first individual
The second individual
Description
The result of the verification.
True if the first individual is equal
to the second individual, false
otherwise.
46 / 87
Assert4Soa
isSubClassOf
Verifies if a class is subclass of another class.
Input Parameters
Name
Type
classA
OWLDescription
classB
OWLDescription
Output Parameters
Name
Type
result
boolean
Description
The description of the first class
The description of the second
class
Description
The result of the verification.
True if the first class is subclass of
the second class, false otherwise.
isSubDataPropertyOf
Verifies if a data property is sub property of another data property.
Input Parameters
Name
Type
dataPropertyA
OWLDataProperty
dataPropertyB
OWLDataProperty
Output Parameters
Name
Type
result
boolean
Description
The first data property
The second data property
Description
The result of the verification.
True if the first data property is
sub property of the second data
property, false otherwise.
isSubObjectPropertyOf
Verifies if an object property is sub property of another object property.
Input Parameters
Name
Type
objectPropertyA OWLObjectProperty
objectPropertyB OWLObjectProperty
Output Parameters
Name
Type
result
boolean
D.6.1 - Architecture and High-level Design
Description
The first object property
The second object property
Description
The result of the verification.
True if the first object property is
sub property of the second object
property, false otherwise.
47 / 87
Assert4Soa
isSubTypeOf
Verifies if a data type is sub type of another data type.
Input Parameters
Name
Type
dataTypeA
OWLDataType
dataTypeB
OWLDataType
Output Parameters
Name
Type
result
boolean
Description
The first data type
The second data type
Description
The result of the verification.
True if the first data type is sub
type of the second data type, false
otherwise.
loadOntology
Loads a specified ontology.
Input Parameters
Name
Type
ontologyURI
URI
Output Parameters
Name
Type
ontology
OWLOntology
Description
The logical URI of the ontology
to be loaded
Description
The loaded ontology
loadOntologyFromPhysicalURI
Loads an ontology from a physical URI.
Input Parameters
Name
Type
ontologyURI
URI
Output Parameters
Name
Type
ontology
OWLOntology
D.6.1 - Architecture and High-level Design
Description
The physical URI of the ontology
to be loaded
Description
The loaded ontology
48 / 87
Assert4Soa
reloadOntology
Reloads an ontology.
Input Parameters
Name
Type
ontologyURI
URI
Output Parameters
Name
Type
ontology
OWLOntology
Description
The URI of the ontology to be
reloaded
Description
The reloaded ontology
removeOntology
Attempts to remove an ontology.
Input Parameters
Name
Type
ontologyURI
URI
Output Parameters
Name
Type
result
boolean
2.4
Description
The URI of the ontology to be
removed
Description
Informs if the operation has been
completed successfully
A SSERT 4S OA plug-ins
As described in Section 1.2, the plug-in approach is applied to the Assert4Soa
architecture in order to realise an extensible and dynamically configurable framework.
At this design stage, the Assert4Soa components that will be integrated into
the system as plug-in units have been identified. In particular, the components that
will be realized following the plug-in approach are:
• Matchmaking Subsystem
• Assert Verifier
• Registry Abstraction Layer
As explained in the previous section, the Matchmaking Subsystem is responsible
of filtering and evaluating the set of candidate services retrieved by the Discovery
Manager and ranks them according to their degree of fit with the security properties
requested by the consumer. The Matchmaking Subsystem is composed by a Master
Matchmaker that controls a set of Slave Matchmakers. Each slave matchmaker
ranks candidate services according to a specific dimension/domain. At the moment
three slave matchmakers are defined (i.e. the Assert-E, the Assert-M and Assert-O
Matchmakers) that provide the evaluation of services using the three different kind
of Asserts but, in general, other domain-specific slave matchmakers can be added to
D.6.1 - Architecture and High-level Design
49 / 87
Assert4Soa
Figure 2.10: Slave matchmaker s as plug-ins of the Matchmaking Subsystem
the architecture. Therefore, they are designed as plug-in units (see Figure 2.10) that
can be configured and plugged into the system at run-time. Moreover, in this way,
slave matchmakers may be provided by thirty-party and plugged into framework
seamlessly.
As an example of this mechanism, the Assert Verifier is designed as a plug-in host
(see Figure 2.11). The generic functionality provided by the Assert Verifier (check of
signature, well-formedness, expiration-time) can be extended in order to verify also
information that is specific to Assert-E, Assert-M, and Assert-O certificates.
Therefore, the realization of the Assert Verifier as a plug-in host supports the
extension of the verification process without modifying its implementation. At the
moment, the Assert-O Verifier is the component designed to extend the Assert Verifier
with the consistency checking of the Assert-O certificate. In particular, the AssertO Verifier checks if the model of the service and the property asserted in an Assert-O
certificate are consistent. If this complementary verification is required, the plug-in
unit implementing the Assert-O Verifier is activated. By using the plug-in approach
for the realization of the Assert Verifier, it is possible to extend the consistency
checking also to the aspects that are specific of Assert-E and Assert-M certificates
(deploying dedicated verification plug-ins).
D.6.1 - Architecture and High-level Design
50 / 87
Assert4Soa
Figure 2.11: Plug-ins of the Assert Verifier
D.6.1 - Architecture and High-level Design
51 / 87
Assert4Soa
Chapter 3
Information View
The Information View defines the structure and the meaning of the information
data exchanged in the Assert4Soa framework in order to provide a shareable and
organised structure of the information data. In particular, this chapter defines the
conceptual data model according to the requirements and use cases provided in the
deliverable D.7.1 [8] and describes how these data are shared and exchanged between
the Assert4Soa components.
3.1
A SSERT 4S OA Data Entities
The Assert4Soa data model describes the static structure of the information
handled in the Assert4Soa framework in terms of entities and their relationships
providing a reference model for the data types specific of the Assert4Soa context.
An entity represents a relevant object for the domain of the system while the
relationships are used to define the logical association between entities. The Assert4Soa
data model is depicted in Figure 3.1 using a UML [24] class diagram. The UML
language permits to specify the domain objects manipulated by the system through
the class, association and generalization concepts. A UML class (represented with a
box) defines the abstraction of a set of objects with their data fields (i.e., attributes)
and behavioural operations. A UML association defines the relationships between
entities; the multiplicity intervals (e.g. 1..*), shown at both ends of the association
line, indicate the cardinality of these relationships. Finally, a UML generalization
defines a taxonomic relation between two entities. It is represented with a solid
line with a hollow arrowhead that points from the subclass entity to the super-class
entity.
The entities and relationship of the Assert4Soa data model are described
below. In particular, it includes all the data types used in Section 2.2 to describe
the expected inputs and outputs of the operations provided by the Assert4Soa
components. The only data that are not depicted in this reference model are the ones
related to the Ontology Manager component, since it provides operations involving
standard data belonging to the OWL 2 Web Ontology language whose detailed
description can be found in [5].
D.6.1 - Architecture and High-level Design
52 / 87
Assert4Soa
Figure 3.1: The Assert4Soa framework Data Model
D.6.1 - Architecture and High-level Design
53 / 87
Assert4Soa
AbstractSecurityProperty
This entity represents an high-level security characteristic (e.g.
integrity, authenticity). It is identified by a name.
confidentiality,
A SSERT
This entity represents the Advanced Security Service cERTificate managed in the
Assert4Soa framework. In particular, it is a specialization of a digital Certificate
used to claim that a set of security properties hold for a given service. It is
characterised by the typical information contained in digital certificates. It is identified
by an unique identifier and it contains the information of the creation time. This
entity class is an abstract class since it can not be directly instantiated but only its
Assert-E, an Assert-M or Assert-O subtype can exist.
Relationships The Assert is related to one or more security properties asserted
in the certificate and to the service for which the properties must hold. Moreover,
it is associated to the assert issuer that have generated it and, optionally, contains
a reference to the profile from which has been created.
ASSERTAuthority
This entity represents the authoritative body responsible for the accreditation of
the assert issuer. In particular, it is a specialization of a TrustOriginator. It is
characterised by an unique identifier.
Relationships The ASSERTAuthority is related to the Certificate entity since
it must have an identity certificate.
A SSERT-E
This entity represent a kind of Assert in which the assessment of the security
properties is based on the execution of tests.
ASSERTIssuer
This entity represents the originator (i.e., the creator and signer) of the Assert.
In particular, it is a specialization of a TrustRecipient. It is characterised by an
unique identifier.
Relationships The assert issuer is associated to an accreditation authority and
related to the Certificate entity since it must have an identity certificate.
A SSERT-M
This entity represents a kind of Assert in which the assessment of the security
properties is based on a formal model.
AssertManagementOperation
This entity represents the set of information needed to manage (issue, update,
revoke) the Asserts.
D.6.1 - Architecture and High-level Design
54 / 87
Assert4Soa
Relationships The AssertManagementOperation entity is composed by the identifier
of the Assert and the Assert itself, the identifier of the assert issuer and the type
of the operation (i.e., Action enumeration) that must be performed.
A SSERT-O
This entity represents a kind of Assert in which the assessment of the security
properties is based on the concepts defined within the Assert ontology.
ASSERTProfile
This entity represents a template, specific for a given certification scheme, from
which the Assert is created.
CandidateService
This entity represents services, retrieve from the service registry, matching the
structural, behavioural and qualitative discovery criteria of a service discovery query.
The structure of this entity is characterized by the reference to the service and the
list of the Asserts associated to it.
Relationships The candidate service is associated to the service matching the given
discovery criteria.
Certificate
This entity represents a digital signed artefact conveying that the statements about
a software product are valid. It is characterized by different attributes such as the
serial number, the signature, the algorithm used to create the signature, the public
key, the validity period of the certificate.
Relationships The certificate is associated to the ValidityPeriod entity.
CompositeService
This entity represents a particular kind of service obtained from the service composition
process performed by the Composition Manager component.
Relationships The composite service consists of the instantiation (with appropriate
services) of one or more composition patterns.
CompositionPatterns
This entity represents an abstract and parametric model of service compositions
used to generate concrete compositions of services.
ConsumerQuery
This entity represents the request submitted by a consumer agent to the Assert4Soa
framework in order to discover services that satisfy functional and security requirements.
It is characterised by subscription information and by the consuming result mode
(push, pull, etc.)
Relationships It is composed by a service discovery query.
D.6.1 - Architecture and High-level Design
55 / 87
Assert4Soa
FunctionalRequirement
This entity represents a statement regarding the functional aspects that the services
must possess.
Relationships The functional requirement is associated to the ServiceRegistryQuery
entity since from a functional requirement can be defined multiple query used to
retrieve services.
ManagementOperation
This entity represents the operation performed by the administrator of the Assert4Soa
framework.
OperationResult
This entity represents a container for the result of different operations. It is characterised
by a message (e.g. successful, failed).
Preferences
This entity represents the preferences on security properties expressed by the consumer
agent.
Relationships It is related to the SecurityProperty entity.
Requirements
This entity represents the functional and security requirements used by the client to
discover the services.
Relationships It consists of both FunctionalRequirement and SecurityRequirement
entities.
SecurityProperty
This entity represents the security characteristic of the evaluated service certified by
the Asserts (i.e., the security property instance). It is characterized by an identifier
(i.e., the URI of the property) and by a version number.
Relationships The security property is associated to an high-level security concept
(i.e., AbstractSecurityProperty).
SecurityRequirement
This entity represents a statement regarding the security property that the services
must possess.
Relationships It is related to the SecurityProperty entity that asserts it.
Service
This entity represents the software system under evaluation. It is characterized by
an endpoint (i.e., the URI of the service) specifying the location for accessing it.
D.6.1 - Architecture and High-level Design
56 / 87
Assert4Soa
ServiceDiscoveryQuery
This entity represents an expression specifying functional and security requirements
of the services used by the Discovery Manager to carry out the functional and
security matchmaking.
Relationships It is composed by functional and security requirements.
ServiceRegistryQuery
This entity represents an expression used to query the service registry. It is characterised
by the functional requirements used to fetch the services.
Relationships It is related to the functional requirements and to the services.
Strategy
This entity represents the strategy used to define the list and the order of the slave
matchmakers that will be invoked during the matchmaking process.
TrustOriginator
If we represent trust relations with an arrow, like A → B, meaning that A trusts
B (in some way or for some aspect), then A is the TrustOriginator. Therefore,
the TrustOriginator is a generalization of all entities trusting some other entity.
A special case of this entity is the ASSERTAuthority. ASSERTAuthorities trust
ASSERTIssuers for issuing AssertS to represent certifications based on the certification
schemes they define.
TrustPreferences
This entity represents trust preferences of the customer (e.g. a preference on a
platform, on a particular certification authority or technology).
TrustRecipient
If we represent trust relations with an arrow, like A → B, meaning that A trusts
B (in some way or for some aspect), then B is the TrustRecipient. Therefore, the
TrustRecipient is a generalization of all entities being trusted by some other entity.
A special case of this entity is the ASSERTIssuer. ASSERTIssuers are trusted by
ASSERTAuthorities for issuing AssertS to represent certifications based on the
certification schemes they define.
UserCredentials
This entity represents the credentials used by the user during the authorisation
process of the Assert4Soa framework. It is characterised by the user name and
password.
D.6.1 - Architecture and High-level Design
57 / 87
Assert4Soa
ValidityPeriod
This entity represents the time interval during which the Assert is valid. It is
characterized by the date from which the certificate is valid and by the expiration
date.
3.2
Information Flow Model
This section describes the dynamic behaviour of the system focussing on how the
information data, defined in the Section 3.1, are exchanged among Assert4Soa
components. To this end, UML activity diagrams of the main use cases are reported
in the following. In particular, according to the notation presented in [33], the data
items (graphically represented as a rectangle) are attached to the control flow edge
connecting two activities.
A SSERT Management activity diagram
Figure 3.2 depicts the activity diagram related to the Assert Management use case
that allows the Assert Issuer to issue, update and revoke Asserts.
As shown in the diagram, the Assert Issuing Tool starts the manageAssert activity
providing the AssertManagementOperation data containing the requested action.
If a new assert must be created it performs the issue Assert action that, in turn,
is split in two possible actions depending if the assert is created from scratch (issue
Assert from scratch) or from a profile (issue Assert from profile). In the
first case, the activity that generates it (generate Assert) receives only the data
related to the new assert (e.g. the certificate information, the validity period, the
timestamp etc. ). In the latter case, also the template (ASSERTProfile) is provided.
After the generation of the new assert the Assert identifier and the Assert fields
of the AssertManagementOperation data are filled. Instead, these fields are already
set in the case one of the following actions are performed:
• update Assert action: the AssertManagementOperation data contains the
identifier of the assert that must be updated and the new assert itself);
• revoke assert action: the AssertManagementOperation data contains the
identifier of the assert that must be revoked.
Then, the Assert Issuing Tool sends the manage assert request to the Entry Point
component that identifies the Assert Issuer and forwards the AssertManagementOperation
data (with all needed fields set) to the Registry Abstraction Layer. This component
analyses the received data and updates the registry performing a store, an update or
a revoke operation accordingly with the Action field. Finally the Registry Abstraction
Layer sends to the Assert Issuing Tool a successful notification (an OperationResult
with a successful message).
Service Discovery activity diagram
Figure 3.3 depicts the activity diagram related to the Service Discovery use case.
The Consumer Agent starts the activity formulateQuery (see Figure 3.2) in order
to provide and send to the Entry Point the ConsumerQuery data type containing the
functional and security information on the services that must be discovered, along
D.6.1 - Architecture and High-level Design
58 / 87
Assert4Soa
Figure 3.2: The Assert Management activity diagram
with the information on the discovery process (subscription and consuming mode
of results). The Entry Point forwards the query to the Query Handler that verifies
the validity of the query (i.e., checkQuery). If the received ConsumerQuery data
type is valid, the Query Handler processes it (i.e., processQuery) in order to provide
a ServiceDiscoveryQuery data type used by the Discovery Manager to find the
requested services.
The findService activity performed by the Discovery Manager is composed by
different actions. First of all it retrieves the services that match the requested
functional requirements taking in input the list of FunctionalRequirement data
types contained in the service discovery query. The output of the retrieveService
action is the list of CandidateService data that match the functional requirements
(including also behavioural, structural and constraint requirements). If no candidate
services are retrieved, the Discovery Manager starts the composeServices activity
D.6.1 - Architecture and High-level Design
59 / 87
Assert4Soa
(see Figure 3.5) in order to provide composition of services applying composition
patterns. Then, the list of CandidateService, along with the list of Requirements
contained in the service discovery query and the Strategy data type are passed
to the matchServices activity (see Figure 3.2). During this activity, the list of
CandidateService is evaluated and ranked according to the security requirements.
Finally, the asserts contained in the list of candidate services are verified, removing
from the list all services whose asserts are not valid.
Formulate Query activity diagram
Figure 3.2 describes the formulateQuery activity depicted in the Service Discovery
activity diagram.
The Consumer Agent receives the Requirements data type and retrieves the security
and trust preferences of the customer (i.e., Preferences and TrustPreferences
data types). Finally, the Consumer Agent performs the composeQuery action that
combines Requirements, Preferences and TrustPreferences data in order to
provide the ConsumerQuery.
Compose Services activity diagram
Figure 3.5 describes the composeServices activity depicted in the Service Discovery
activity diagram.
The Composition Manager, using the Requirements data, retrieves the list of the
CompositionPatters that, consequently, are filled with actual services (i.e. fillPatters).
Then, the Composition Manager creates the virtual asserts that must be associate to
the services and provides in output a list of CompositeService data types, returned
to the Discovery Manager in order to perform the matchmaking process.
Mach Services activity diagram
Figure 3.2 describes the matchServices activity diagram depicted in the Service
Discovery activity diagram.
The Master Matchmaker analyses the Strategy data type received in input in order
to decide which are the slave matchmakers that must be called and the order of
the calling. Then, it passes to the slave matchmaker the list of CandidateService
data types and the list of SecurityRequirement according to which each slave
matchmaker has to perform the ranking of services based on its specific assert
certificate (i.e., ASSERT-M, ASSERT-E and ASSERT-O certificate). The lists
of candidate services, partially ordered by each slave matchmaker (i.e., mCSList,
eCSList and oCSList), are then evaluated by the Master Matchmaker providing a
fully ordered list of the candidate services (i.e., csOrderedList).
D.6.1 - Architecture and High-level Design
60 / 87
Assert4Soa
Figure 3.3: The service discovery activity diagram
D.6.1 - Architecture and High-level Design
61 / 87
Assert4Soa
Figure 3.4: The Formulate Query activity diagram
D.6.1 - Architecture and High-level Design
62 / 87
Assert4Soa
Figure 3.5: The Compose Services activity diagram
D.6.1 - Architecture and High-level Design
63 / 87
Assert4Soa
Figure 3.6: The Match Services activity diagram
D.6.1 - Architecture and High-level Design
64 / 87
Assert4Soa
Chapter 4
Security Perspective
Assert4Soa provides a framework for handling Advanced Security Service cERTicates
(Assert). Logically, a very important point is the security of the framework
components. Therefore, providing an appropriate treatment of security and privacy
issues in order to avoid risks will becomes essential for ensuring the necessary
trust. To achieve this, we need to ensure that privacy is adequately protected,
and Assert4Soa processes are not vulnerable to security attacks.
The rest of the chapter is organized as follows: Section 4.1 presents an identification
and analysis of possible threats and attack of the framework, projecting the security
aspect onto the information model of Chapter 3 and in particular on the behavioural
specification expressed in the activity diagrams of that chapter. Based on the
threats and attacks identified, we performed a systematic risk assessment whose
outcome is documented in Section 4.2. Section 4.3 describes the corresponding
security mechanisms included in the framework to address the risks identified. Such
mechanisms are projected onto the security-relevant components that are part of the
architecture (and that are also described in the Component Catalog, in Chapter 2).
We conclude the chapter by presenting a brief overview of technologies and standards
related to the security of service-oriented systems, that may be adopted in the
realisation of the security mechanisms of the Assert4Soa framework.
4.1
Threat analysis
The purpose of this section is identify and analyse the possible framework threats
and how should be addressed. This is the first step in designing a security solution;
its importance lies since a good threat analysis facilitates the next step, the risks
management, and in the end the appropriate choice of security solutions.
After having performed an analysis of the potential threat and attacks that can
violate the framework Assert4Soa, the following threat and attacks have been
identified:
1. Selection of a service that is not the best with regards to the needs of
the client. This is the main threat that we have to face in Assert4Soa. This
threat may be implemented in several ways through different attacks, including
the following:
(a) Creation of fake certificates. A malicious service provider may try to create
D.6.1 - Architecture and High-level Design
65 / 87
Assert4Soa
a fake Assert to state false properties about a service. This attack has
two variants:
i. Creating a fake Assert certificate
ii. Creating a fake Assert Issuer
i.) can affect the issue Assert state, while ii.) can affect the identify
ASSERT Issuer state in the Assert Management activity diagram (Figure 3.2).
(b) Association of legitimate certificates to a different service. In this case,
the malicious provider does not attempt to create a false certificate, but
to associate a certificate issued to another service to its own service. This
attack can be carried out by associating powerful certificates to the service
of the attacker or by associating weak certificates to the services of the
competitors. This attack can affect the machServices state in the Service
Discovery activity diagram (Figure 3.3).
(c) Attacks to the Assert4Soa ontology. In this case, the malicious user
alters the ontology so that the reasoning mechanisms conclude that the
Assert of the malicious service is equivalent to more powerful ones.This
attack can affect the matchServices state in the Service Discovery activity
diagram (Figure 3.3).
(d) Attacks to the Assert4Soa reasoning mechanisms. As in the previous
case, the idea is not to associate a powerful Assert to the malicious
service, but to influence the reasoning mechanisms in a way that increases
the chances of that service being selected. This attack can affect the
matchServices state in the Service Discovery activity diagram (see Figure 3.3).
(e) Attacks to the Orchestration Pattern system. The basic goal in this attack
is to introduce malicious Orchestration Patterns or to modify existing ones
so that the malicious service is included in the orchestration. This attack
can affect the composeServices state in the Service Discovery activity
diagram (Figure 3.3).
(f) Attacks by malicious service platforms. In this case, a malicious service
platform behaves incorrectly in order to favour the selection of certain
services. This is a general attack that can affect all the Service Discovery
states.
(g) Attacks to the Assert4Soa Queries. The malicious user alters the queries
so that the reasoning mechanisms conclude that the Assert of the malicious
service is equivalent to more powerful ones. This attack can affect the
formulateQuery state in the Service Discovery activity diagram (Figure 3.3).
(h) Association of invalid certificates to a service. In this case a malicious
provider try to associated a service with an Assert that expired, unreliable
or false. This attack can affect the verifyAsserts state in the Service
Discovery activity diagram (Figure 3.3).
2. Denial of service. This is another important threat. The goal in this case is
to make the system or part of it unavailable, normally, with the ultimate goal
of forcing clients to use alternate means for selecting services.
3. Attacks on communications. A weak point is communication between
the different components and they become more vulnerable if this system is
D.6.1 - Architecture and High-level Design
66 / 87
Assert4Soa
distributed. A malicious attack can compromise the confidentiality of transmissions
and integrated of them.
4. Attack on the privacy of the queries. The queries can give information
about clients. This may be a weak point that allows copying this information
to a malicious user.
There are other threats that do not apply in all cases. Among these, we
highlight the following ones:
5. Privacy attacks. In cases in which the information contained in the Asserts
include privacy sensitive information; malicious users may try to gain access
to this information with different purposes.
6. Client impersonation. In cases in which the access to the services is restricted
to certain clients, or the service selection depends on the client credentials, or
in cases in which access to services requires payment, malicious clients may try
to impersonate legitimate ones.
D.6.1 - Architecture and High-level Design
67 / 87
Assert4Soa
4.2
Risk Management
In the process of designing the security of a system, the next step is risk management.
So in a second stage we perform a risk analysis according to the environments of the
Assert4Soa Framework and as and threat affecting them. We have identified three
environments: (i) Assert Issuer: It is responsible for management of Asserts; (ii)
Service Consumer: Is the client-side and requests to the server-side for services that
fulfil certain security properties and (iii)Assert4Soa Management System: The
manager of registering services, dynamic service discovery manages and uses the
ontology, among others. The following tables contain the threat/attack (described
in the previous section), a short risk description, and the impact in the system and
a proposal of mitigation measure.
A SSERT Issuer
Threat/Attack
Risk Description
Mitigation Measures
Impact
Threat/Attack
Risk Description
(3)Attacks on communications
Violate the confidentiality and integrity of
communications between the Assert Issuing Tool
component and the external items
Mechanisms to guarantee a secure communications
channel (with the Assert4Soa Management
System, Assert Ontology, to Online Assert
repositories, Trust Manager
Medium
Impact
(5) Privacy attacks
Compromise the integrity of Online Assert
repositories
Mechanisms to guarantee the security of the Online
Assert repositories such as Digital Signature
High
Threat/Attack
Risk Description
Mitigation Measures
Impact
(1.a.ii) Creating a fake Assert Issuer
Sign an Assert using a false identity
Sign the Assert with a trusted digital certificate
High
Threat/Attack
Risk Description
Mitigation Measures
(1.a.i) Creating a fake certificate
Create Assert with fake data
Sign the Assert with a trusted certificate of the
Assert Issuer
Medium
Mitigation Measures
Impact
Threat/Attack
Risk Description
Mitigation Measures
Impact
(1.a) Creation of fake certificates
Associate a certificate issued to another service to
its own service
Solutions that provide robust binding between the
Assert and the Service
High
D.6.1 - Architecture and High-level Design
68 / 87
Assert4Soa
Service Consumer
Threat/Attack
Risk Description
Mitigation Measures
Impact
Threat/Attack
Risk Description
Mitigation Measures
Impact
Threat/Attack
Risk Description
Mitigation Measures
Impact
Threat/Attack
Risk Description
Mitigation Measures
Impact
(3)Attacks on communications
Violate the confidentiality and integrity of serverclient communications
Mechanisms to guarantee a secure communications
channel
Medium
(1.h) Association of invalid certificates to a service
Deceive on the trust of an Assert
Availability of automated tools to verify the
trustworthiness of an Assert Authorities (Trust
Manager)
High
(1.h) Association of invalid certificates to a service
Deceive on the time validity of an Assert
Availability of automated tools to verify the time
validity: The Assert validity period is in time.
(Assert Verifier)
High
(1.h) Association of invalid certificates to a service
Deceive on the validity (Invalid signature) of an
Assert
Availability of automated tools to verify the
Signature (Assert Verifier)
High
D.6.1 - Architecture and High-level Design
69 / 87
Assert4Soa
A SSERT 4S OA Management System
Threat/Attack
Risk Description
Mitigation Measures
Impact
Threat/Attack
Risk Description
Mitigation Measures
Impact
Threat/Attack
Risk Description
Mitigation Measures
Impact
Threat/Attack
Risk Description
Mitigation Measures
Impact
Threat/Attack
Risk Description
Mitigation Measures
Impact
Threat/Attack
Risk Description
Mitigation Measures
Impact
(6) Client impersonation
Compromise the user authentication by using false
Identity
Mechanisms to guarantee the client authentication
(in those scenarios as needed)
Medium
(1.c) Attacks to the Assert4Soa ontology
Compromise the authenticity and integrity of
Assert Ontology
Mechanisms to guarantee security for ontology such
as digital signature
High
(1.g) Attacks to the Assert4Soa Queries
Compromise the authenticity, and integrity of Query
language
Guarantee authenticity, and integrity of the query
using mechanisms such as sign the queries
Medium
(1.e , 6)Attacks to the Orchestration Pattern system
, Client impersonation
Compromise the privacy of Query language
Protect the privacy of the queries using methods
designed for this purpose, such as encryption
Medium
(1.f) Attacks by malicious service platforms
Compromise the correct execution of the framework
processes
Availability of automated tools to process the
System Monitoring information
Medium
(1.h) Association of invalid certificates to a service
Deceive on the trust of an Assert
Availability of automated tools to verify the
trustworthiness of an Assert Authorities (Trust
Manager)
Medium
D.6.1 - Architecture and High-level Design
70 / 87
Assert4Soa
Threat/Attack
Risk Description
Mitigation Measures
Impact
Threat/Attack
Risk Description
Mitigation Measures
Impact
Threat/Attack
Risk Description
Mitigation Measures
Impact
4.3
(1.h) Association of invalid certificates to a service
Deceive on the time validity of an Assert
Availability of automated tools to verify the time
validity: The Assert validity period is in time.
(Assert Verifier)
High
(1.h) Association of invalid certificates to a service
Deceive on the Assert validity (Invalid signature)
Availability of automated tools to verify the
Signature (Assert Verifier)
High
(2) Denial of service
System that forcing clients to use alternate means
for selecting services
Use of tools to mitigate such attacks as a proxy
High
Security features of the framework
Providing an appropriate treatment of security and privacy in order to avoid risks
is an important issue of almost any computational framework. In our case, as the
main goal of the Assert4Soa framework is to support the security-based selection
of services, ensuring the security of the framework becomes crucial for its practical
success.
In this section, we describe a first overview of the Assert4Soa framework
security mechanisms based on the threat analysis summarized in the previous section.
In order to ensure that privacy is adequately protected and Assert4Soa processes
are not vulnerable to security attacks Figure 4.3 shows (coloured in green, yellow and
red) the main components that need to incorporate specific security mechanisms.
Components that provide security functionalities to the framework are
marked in green.
The Assert Trust Manager is responsible for creating and managing the trust
relationships established between different Assert Authorities and Assert Issuers.
Optionally, it can also be extended to provide additional information (such as
reputation) of Assert Authorities and Issuers. The functionalities that the Assert
Trust Manager provides are the following:
• Create a trust relationship:
– One of the cornerstones of the project is to create a chain of trust that
allows guarantee that a service fulfils one or more security properties. The
Assert is only the first link in the chain, since it an Assert Issuer certifies
that a service fulfils a specific security property, but we have to extend this
chain of trust between the Assert Issuer and the ASSER Authority, and
that is the mission of this component. In this particular case, it creates a
D.6.1 - Architecture and High-level Design
71 / 87
Assert4Soa
link in the chain of trust between a specific Assert Authority and Assert
Issuer declaring that whenever there is this relationship going to trust her.
– Expected input: Trust originator (normally an Assert Authority); Trust
recipient (normally an Assert Issuer)
– Provided output: Trust proof (digital proof of the trust relationship between
the originator and the recipient).
– Dependencies/interactions with other functionalities (provided by other
components): The Assert Verifier is responsible for verifying Asserts and
needs to verify the corresponding trust relationships.
– Pre-conditions, post-conditions: Trust originator and recipient must have
identity certificates.
• Revoke a trust relationship:
– This component performs the inverse operation than the component before.
Decouple an Assert Authority and Assert Issuer, breaking the link
Figure 4.1:
mechanisms
Tentative Architecture - components including specific security
D.6.1 - Architecture and High-level Design
72 / 87
Assert4Soa
of trust. This may be due to a broken part of this relationship or the
relationship has been created by a certain time and this has expired .
– Expected input: Trust originator (normally an Assert Authority); Trust
recipient (normally an Assert Issuer); Trust proof.
– Provided output: Digital proof of the revocation of the Trust proof.
– Dependencies/interactions with other functionalities (provided by other
components): The Assert Verifier is responsible for verifying Asserts and
needs to verify the corresponding trust relationships.
– Pre-conditions, post-conditions: Trust originator and recipient must have
identity certificates. Trust proof must exist and be valid.
• Assess the reliability of the Assert Authority:
– This component creates a link in the chain of trust in a more general
sense, establishes that a Assert Authority is trustworthy for any Assert
ISSUER. This is very useful when incorporated into the framework authorities
widely recognized.
– Expected input: Assert Authority identification information
– Provided output: Information on the reliability of the Assert Authorities
– Dependencies/interactions with other functionalities (provided by other
components): The Assert Verifier is responsible for verifying Asserts and
needs to verify the corresponding trust relationships.
– Additional constraints: This feature is not necessarily used in all scenarios.
The Assert verifier provides functionalities to assess the validity of Asserts.
Essentially, this entails checking the temporal validity, the digital signature and
the trustworthiness of the Assert Issuer. For this purpose, it interacts with the
Trust Manager to obtain information about the trust and reliability of the Assert
Authorities.
The functionality provides are:
• Check the validity of the Assert based on predefined trust roots:
– The Assert contains various parameters that grants validity, some of
the standard parameters are: the signature of the Assert ISSUER, the
period of validity, trust of Assert Authority. Can also define other specific
parameters in the trust roots. This component is responsible for checking
all these faces and tell the system if one is valid Assert.
– Expected input: Assert
– Provided output: Information about the Assert validity (YES / NO, plus
the reason why in this latter case).
– Dependencies/interactions with other functionalities (provided by other
components): Trust Manager creates the trust relationships that are to be
checked by this component. Assert Issuing Tool creates the Asserts that
are to be verified.
• Check the validity of the Assert, given the Assert along with client-specified
trust roots:
D.6.1 - Architecture and High-level Design
73 / 87
Assert4Soa
– Component is equivalent to the above; check those parameters that guarantee
the validity of the certificate but the client side.
– Expected input: Assert, Client-specified trust roots.
– Provided output: Information about the Assert validity (YES / NO, plus
the reason why in this latter case).
– Dependencies/interactions with other functionalities (provided by other
components): Trust Manager creates the trust relationships that are to be
checked by this component. Assert Issuing Tool creates the Asserts that
are to be verified.
Another component of the framework that provides security functionalities is the
Server Entry Point, which provides Client Authentication functionality. The clients
of the framework are service consumers that request services that possess certain
security properties certified by Asserts. Depending on the scenario in which the
Assert4Soa framework is used, the authentication of clients can be an important
security requirement to be provided by this component.
Continuing with the analysis of the security-related components of the framework,
marked in yellow are the security-crucial components. While these components
do not offer security functionalities as such, guaranteeing their security is crucial for
the security of the whole framework.
The Assert4Soa Ontology (and thus the Ontology Manager tool and the Matchmaking
Subsystem) are indeed security-crucial components. The main security requirements
for these components are the trustworthiness of the Ontology contents and the
privacy of the information contained in the queries to the Ontology. The Ontology
Manager tool must therefore support the mechanisms that will ensure the secure
operation of the Assert4Soa Ontology. The complete details about the security
requirements for the Assert4Soa Ontology are contained in Deliverable D3.1 [7].
Another component in this category is the Assert Issuing tool. This component
allows issuers to create and manage Asserts. The most important requirement for
this tool is the ability to securely create (in particular, to sign) Asserts. The tool
must be capable of securely erasing the keys used for the signature each time these
are used in the computer memory, and ideally to use secure hardware devices (such
as smart cards) for creating the digital signatures.
Security-relevant components are marked in red in the figure. These are also
worth mentioning here because their operation is also subject to security considerations,
although a failure in their security is not likely to affect the whole framework
operation.
The first of these is the System Administration component, is responsible for
auditing the functioning of the framework and for reporting any anomalous or
incorrect operation of the framework. The security mechanisms must interact with
this tool to ensure the correct functioning of all processes. In particular, this
represents a limitation to the security mechanisms of the monitored components,
because they have to provide the information required by the monitoring components.
Finally, the components related to the discovery process (Query Handler,
Discovery Manager and Composition Manager) are at the heart of the whole Assert4Soa
framework. It is therefore essential to provide adequate security to these components.
As stated in D2.1, the main threat that the Assert4Soa framework faces is that
malicious users can force the selection of a service or a composition of these that is
D.6.1 - Architecture and High-level Design
74 / 87
Assert4Soa
not the best with regards to the needs of the client. This is indeed closely related
to the discovery process. When a client requests a service it sends a query to
the Assert4Soa framework, the framework has to provide a reply indicating the
services that are available and in particular, those that fulfil the security requirements
specified in the query. If the process is not correct or fair, the client might be
prevented to choose the service that best fitted its needs. Likewise, the process is
subject to other threats like those related to the privacy of the information contained
in queries, etc. The specific requirements for this components are described in
Deliverable D2.1 [6].
4.4
Realising a secure architecture: overview of approaches,
technologies, and standards
As introduced in Chapter 1, the approach followed in this architecture description
document is purposely technology-neutral and as a consequence we do not commit
here to any specific standard, language or technology. However, in order to provide
useful guidelines for the realisation of the Assert4Soa architecture, in this section
we briefly review the state of art of the existing approaches to securing service-based
systems, with special emphasis on the aspects that are more strictly related to the
security mechanisms that will be used in the Assert4Soa framework.
Access control and Client authentication
One of the most important topics is access control and authentication of clients. In
the background there are several proposals for (distributed) access control systems
targeting different application domains. One of the main design features of those
systems is splitting the server role into two: an application server and an authorization
server, to decouple access control logic from application logic and possibly distribute
the access control component. One of the earliest works was proposed by Woo and
Lam [40, 39]. Other access control proposals are Adage system [44] and Akenti [35].
The first offers centralized security administration and modular authorization and
the second is an authorization systems based on digital certificates. Akenti uses three
types of certificates: X.509 user identity certificates for authenticating users, usecondition certificates for specifying the conditions that must be met by a user to get
access to a resource, and attribute certificates, stored on trusted servers, attesting
that a user possesses specific attributes. A widely cited access control system is
PERMIS [13, 14]. PERMIS adopts X.509 certificate standard supporting identity
and attribute certificates. Architecturally, it consists of two main subsystems: the
privilege allocation and the privilege verification subsystem. Finally we highlight
trust negotiation base access control [36, 37]. This is a promising technique that
was proposed for authorization and access control in open environments where any
entity could be malicious. The sequence of credential exchange during a negotiation
process is controlled by negotiation strategies. One can define variety of negotiation
strategies and privacy settings [42, 29, 43, 32, 10] depending on credential sensitivity,
on familiarity with the remote opponent or domain, type of resources being accessed,
and so on. Recently, only few policy-driven trust negotiation approaches have been
successfully developed and deployed as authorization systems, such as TrustBuilder [23],
Protune [12], Trust-X [11], and iAccess [21]. The approach [23] employs trust
D.6.1 - Architecture and High-level Design
75 / 87
Assert4Soa
negotiation in Grid using existing negotiation mechanisms and protocols such as
those of TrustBuilder and Trust-X.
Certification infrastructures and standards
Another major topic for Assert4Soa framework is Certification Infrastructures. A
Public Key Infrastructure (PKI) [20] provides a framework for managing identity
information in a decentralized and open environment. At the core of PKI is the
notion of a pair of keys (a public and a private one). Each pair of keys belongs to a
unique individual and this individual keeps the private part of the key pair secret. A
key holder therefore has the unique capability of encrypting data using the private
part of a key pair. The public part of the key pair allows any third party to verify
that data have been encrypted with the corresponding private key. A public-key
certificate is a digitally signed document certifying that a particular individual owns
a certain public key. A public-key certificate has a special data structure and is
digitally signed by a third party called the Certificate Authority (CA). A public-key
certificate serves to bind a public key to an individual holding the corresponding
private key, and the correctness of the binding is guaranteed by the CA [18]. A
third party trusting the CA that issued the public key certificate can assume the
correctness of the identity information and can verify if an individual is the owner
of the corresponding private key.
Currently, only few PKI/PMI compliant implementations have reached a very
broad deployment states. The most widely used such standards today are X.509 [41],
SPKI [31] and SAML [28]. They all support expression of identity and of attribute/value
information. X.509 Public Key Certificate is the most widely used certification
standard on the Internet today, supported by all browsers. SPKI, on the other
hand, has gained mostly academic interest, and though implemented by several
commercial products, it is not as widely accepted as X.509.
SAML defines an XML framework for exchanging security information such
as authentication, attributes, or authorization between online partners. The core
SAML specification defines the structure and content of assertions that carry information
about the party to which the attribute refers (and called a principal in this context).
In addition to document representation, SAML specifies a protocol for requesting
and responding to requests about assertions. We take these technologies as a starting
point to create the structure of the Assert4Soa, although this is novel approach,
is compatible with current standards.
D.6.1 - Architecture and High-level Design
76 / 87
Assert4Soa
Chapter 5
Conclusion
In this document we presented a multi-view description of the high-level architecture
of the Assert4Soa framework. We concentrated on a small set of relevant aspects,
namely the functional view, the information view, and the security perspective.
We emphasised the high-level elements and mechanisms of the framework, while
purposely delaying detailed design and technical decisions until a later time. Those
decisions will be taken when an initial validation of the architecture will start as
part of the development phase; at that time, the architecture will also be evaluated
against concrete demonstration scenarios, whose identification is the objective of
Task 7.2, and which will provide more precise insights as to which technical choices
are optimal.
Even at this stage, however, there are some tentative technical directions that
are emerging as the natural choices for realizing the mechanisms described earlier
in the document. With regard to security, Section 4.4 in the previous chapter gave
a general overview of possible approaches, languages, and standards that could be
applied to securing the Assert4Soa framework.
In addition to that overview, in this chapter, we briefly discuss some additional
points related to technologies that match well the architectural style chosen for
Assert4Soa and which appear to be particularly well suited for being adopted in
the next developments of the architecture (Section 5.1).
Before concluding, Section 5.2 presents some of the possible alternative deployment
options for the architecture.
Finally, Section 5.3 outlines the next steps that will be taken in Work Package 6.
5.1
Component and communication technologies
The notions of component and connector are central in our architecture; in this
section we give examples of some technologies and solutions that can be adopted to
realise those architectural abstractions.
The OSGi Service Platform [3], whose specifications are maintained by the OSGi
Alliance [2], is a Java-based and service-oriented technology for deploying and managing
coarse-grained components. This technology provides the standardized primitives
allowing applications to be constructed from small, reusable and collaborative components
that can be dynamically installed, started, stopped, updated and uninstalled without
requiring a reboot.
D.6.1 - Architecture and High-level Design
77 / 87
Assert4Soa
All the components in the Assert4Soa framework could be packaged and deployed
as OSGi bundles. A bundle is a unit of modularization for the OSGi technology
(a tightly-coupled collection of classes, jars, and configuration files). The OSGI
bundles abstract away the internals of a function and communicate through well
defined services. This would go hand in hand with the event-based architecture
style that is adopted where functionality and communication is separated. Another
advantage is that OSGI bundles can be updated on the fly; this, not only would
support the dynamic nature of the framework, but would also enhance the security
of operation by allowing the framework to get the latest updates with security fixes
without having to restart, reinstall or reconfigure the whole system.
A natural choice for realising the concept of a connector (as described in Section 1.2),
is the adoption of an Enterprise Service Bus (ESB). An ESB provides a standardbased integration platform that combines messaging, web services, data transformation
and intelligent routing in a event-driven Service Oriented Architecture (SOA) [15].
The main capability of an ESB are:
• Integration capabilities: it acts as a lightweight integration broker connecting
heterogeneous systems using, among other issue, open standards;
• Data Transformation capabilities: it manages the interaction between services
across heterogeneous data structure and transport protocols; transformation
services ensure that messages and data received by any component is in the
format it expects;
• Endpoint discovery capabilities: it hosts services as a lightweight service container
supporting the discovery, localisation and binding of services, also considering
QoS properties enabling the client to select the best endpoint at run-time;
• Message Routing capabilities: it provides the virtual channels to route messages
to the recipients using content and complex routing mechanisms; the services
do not need to understand how messages are routed to other services, they
simply receive a message from the bus as an (asynchronous) event and process
this message; moreover the ESB permits to filter, aggregate and re-sequence
messages ensuring reliable messaging delivery;
• Security Capability: it provides security model (authentication, credential
management and access control) in order to guarantee security requirements
between the services and the ESB and even between the ESB nodes themselves.
• Management and Monitoring: it permits to monitor the capacity and performance
of the services by inspecting the activities that takes place via the bus.
An ESB can connect and coordinate services in a loosely-coupled and distributed
fashion. In particular, it facilitates the development of infrastructures that are
flexible, extensible and easily scalable; moreover, the separation of the business
logic from specific protocols and message formats ensures a faster and streamlined
development.
Given these characteristics, the ESB technology is well matched with the architectural
principle defined Section 1.2. In particular, this approach is consistent with the
objective to develop a flexible and extensible architecture in which the interaction
model between the components is realised through messaging-based connectors.
However there exist a gap between the implementation of a component as a provider
D.6.1 - Architecture and High-level Design
78 / 87
Assert4Soa
Figure 5.1: Component wrapper
of functionalities (those described in the component catalog), and the implementation
of a component that is also capable of communicating with the surrounding environment
through connectors (as opposed, e.g., through synchronous method invocation).
In order to fill this gap, and to provide a full separation between the communication
and computation aspects, we will provide Component Wrapper s, exposing a simple
but powerful communication API that the core component can use to talk to connectors
(see Figure 5.1). Component developers can use such wrappers to encapsulate
their “core” component into a bundle that is able to take full advantage of the
communication infrastructure of the Assert4Soa architecture.
When the component needs to communicate with some other component in
the framework, the component wrapper takes care of encapsulating the data as
a message, that it then sends to the appropriate connector. The wrapper also
listens to the messages coming from the connectors to which it is attached, and
receives incoming messages. Ultimately, the wrapper is responsible of marshalling
and unmarshalling messages from/to data types that are understood by the core
component implementation. This enhances the separation of concerns, distinguishing
between the design and operation of the messaging infrastructure from the payload
conceptual model (which will be based on the model of Chapter 3).
Finally, in addition to the communication API, the wrapper is effectively responsible
for packaging the core component implementation as an OSGI bundle. This gives
component developers the freedom to implement their components as they prefer
and yet seamlessly integrate them with the rest of the framework.
5.2
Deployment configurations
The overall organisation of the architecture, as exposed in Chapter 2, is somewhat
biased towards a specific assignment of components to the nodes of a typical clientserver deployment platform.
In this section we try to challenge and to extend this view, by providing an
initial discussion of possible deployment alternatives. A better evaluation of these
deployment choices will be possible when the architecture is confronted with the
more realistic application scenarios that will be elaborated in the course of the
project. In particular, not only the deployment configuration themselves will be
D.6.1 - Architecture and High-level Design
79 / 87
Assert4Soa
validated, but also their implications on the architectural qualities and non-functional
aspects will become clearer (especially, w.r.t. security and performance).
Client-server The basic deployment envisaged is that of a client-server (or “thin
client”) configuration. The consumer uses the client side component to store his
security and trust preferences and formulate a query to fetch services from the
Assert4Soa discovery engine. The client module in this scenario, does not have
any other additional functionality and hence is referred to as a “thin client”.
This deployment model assumes that the consumer trusts the Assert4Soa
service discovery system (on the server side) and the components involved in the
matchmaking process. To support this assumption the Assert4Soa framework aims
to address the security and privacy threats as explained in the previous chapter. The
integrity of the Assert4Soa framework is one of the core security requirements [8].
The confidentiality of the information provided by the consumer is also to be protected
and is again a core security requirement of the framework.
The Assert4Soa framework uses slave matchmakers to perform the matchmaking
of services and these slave matchmakers can be either internal to the framework or
provided by external providers as explained in section 2.4.
However, in a scenario where a consumer may not want to disclose her security
preferences to external matchmakers or cannot trust the external matchmakers to
perform the matchmaking, this deployment model may not be adequate.
Thick Client When the consumer does not want to disclose their security requirements
to external slave matchmakers or even to the Assert4Soa service discovery engine,
an alternate deployment model of a “thick client” can be adopted. In this model,
the client-side deployment includes components related to the matchmaking process.
The consumer could query the Assert4Soadiscovery engine for some generic constraints
on the services and perform additional matchmaking with additional (possibly,
confidential) security requirements, using the matchmaking system that is replicated
on the client side. Consumers may be allowed to plug dedicated, additional clientside proprietary matchmakers that perform the matchmaking in a customised way.
Client-side service discovery (single-domain deployment) The “Thick client” deployment
model is not suitable in the scenario where a consumer prefers to have the complete
service discovery system under control.
In order to cater to the requirements of such consumers, the “thick” client side
component can be further extended to deploy the full Assert4Soa framework on
one single node1 that is under the control of the consumer. This “degenerated”
deployment model may be required when particular restrictions apply to the trust
relationships between the consumer and the other actors of the system (e.g., the
provider of the Assert-enabled directory).
5.3
Conclusion and next steps
The goals of WP6 include the architecture definition and detailed design (Task 6.1),
the development of a prototype implementation of the Assert4Soa framework
1 Or
any number of nodes, provided the consumer has control over them.
D.6.1 - Architecture and High-level Design
80 / 87
FP7-ICT-2009-5
Grant agreement no: 257351
ASSERT4SOA
ICT-2009.1.4: Trustworthy ICT
Collaborative project (STREP)
In order to support developers of applications that use certified services to manage the ASSERT certificates.
The WP7 will also define an API and produce a library to parse and manage ASSERTs. Complementary, we
will provide example applications illustrating the
use of the library in different contexts.
Assert4Soa
Description of work and role of participant
We will embrace an Iterative and Incremental development as software development process. This
approach will enable to take advantage of what will be developed on other activities and to quickly provide
initial release of the software. At each iteration, design modifications and prioritisations will be made and
Figure 5.2: Scheduling of WP6 tasks and deliverables
new functional capabilities will be added. The duration of the life cycle analysis–design–implementation will
be initially based on 4 months starting at M12 with 2 major milestones at M24 and M36.
Detailed
Architectureof
(Leader:
SAP, M1-M24):
(Task
Task6.1:6.2
), andDesign
the and
integration
modules
developed in the context of the other
The
design
activity
will
mainly
provide
a
detailed
software
architecture to be used as a basis for the
technical work packages (Task 6.3).
development
in
Task
6.2.
This
architecture
will
explicit
the
technologies
will describe
existing
The scheduling of these tasks is visually illustrated used,
in Figure
5.3 the
(from
the
components that will be reused, and will provide an abstract representation of the critical software
“Description
of
Work”
[9]).
classes/functions. The initial focus will be the definition of APIs and protocol extensions. A particular
This will
deliverable
theof initial
resultsdesign
achieved
as part
of Task
(M1attention
be dedicatedpresented
to the security
the architectural
to address
our concerns
with6.1
respect
of
the potential
threats
theto
ASSERT4SOA
framework.
M24),
whose
goalto is
define the
architecture of the Assert4Soa framework and
to
produce
a design(Leader:
documentation
that is detailed enough as to guide the concrete
Task
6.2: Development
SAP, M13-M36):
realization
of awill
prototype
demonstrating
As results
the work
The work on task
start as soon
as a first release the
of theAssert4Soa
design documentconcept.
based on WP1
and
refined into
Task
6.1 task
will become
available.
It is through
foreseen that
the development
will start with
production
related
this
is only
halfway
(Task
6.1 will terminate
atthe
month
24),
of acontents
mockup, inoforder
verify the interfaces
and considered
the general architecture
of the
system. We
then
the
thistodocument
are to be
as an initial
attempt
to will
capture
produce a sequence of releases of the tool, which will progressively cover larger portions of the ASSERTs
the
high-level elements and mechanism of the Assert4Soa framework. While
lifecycle. The development effort will follow the principles of modern software engineering methodologies,
the
objective
ofthe
this
document
is from
to provide
useful
the development
taking into account
advantages
deriving
a development
cycleguidance
producing ato
continuous
sequence of
phase
is about
to use
start,
it is natural
to expect
that when
confronted
releases,that
supported
by the
of modern
configuration
management
and versioning
tools. with
The
development
activity
will
be
documented
and
the
partners
will
insure
that
coding
best
practices
will
be
used
the concrete issues that normally arise in software development, it will need to be
to minimizeand
the vulnerabilities
of the
ASSERT4SOA
framework.
updated
amended to
reflect
the more
accurate perception attained of both the
Task
6.3:
Integration
of
modules
(Leader:
Eng,
M19-M36):
problem domain and of the solution space.
TheThe
work WP6
on this roadmap
task will mainly
in providing
support
WP3,4 and 5Immediately
to implement the
abstract
for consist
the coming
year
is asto follows.
after
the
definition of mechanisms to match, compare and check ASSERTs and to achieve the integration of the
delivery
of
this
document,
Task
6.2
will
start.
As
part
of
this
task,
we
will
start
dedicated mechanisms in the generic framework.
validating the component organisation and interfaces described here; to this end,
a set of mock-ups will be developed. The technical realisation of these mock-ups
will be documented in a working document (WD.6.1) to be released at month 16.
Gradually these mock-ups will evolve into fully functional components, incorporating
functionality developed by the other technical work packages. Starting at month
18, the integration work will begin as Task 6.3. Deliverable D.6.4, containing the
guidelines
for plug-in development, will be released at month 21. Finally,
at month
17.05.2010
Page 50 of 124
24, Task 6.1 will conclude, the architecture design will be complete at that time, and
Deliverable D.6.2 will be released in the form of an initial prototype implementation
of the architecture. Development and integration will continue until the end of the
project.
D.6.1 - Architecture and High-level Design
81 / 87
Assert4Soa
Appendix A
References to the other work
packages and deliverables
In order to provide a clearer overview of the overall framework organization, this
appendix collects references to the key deliverables that have been (or will be)
produced in the other Work Packages. In particular, we link the most important
abstract architecture elements defined in this document with the deliverables that
specify the internal structure and operation of those elements, or that present the
conceptual or theoretical foundations on which those components are built1 . The
month of delivery of each deliverable is reported between parentheses.
Query Handler, Discovery Manager, Matchmaking subsystem These elements
are collectively referred to as the Discovery Engine, and are developed in
WP2. The internal organisation of the Discovery Engine and the A-Serdiquel
query language are described in D.2.1 (M12); an initial implementation of
the Discovery Engine, both as a stand-alone systems and as a (simplified)
integrated element of the overall architecture is part of D.2.3 and D.6.2 respectively
(M24). D.2.3 also includes refinements and improvements to the initial ASerdiquel specification. The Matchmaking subsystem includes the slave matchmakers,
each of which is developed in a different work package (see below).
Composition Manager The operation of this component and the underlying concepts
and algorithms are described in D.2.2 (M18) and were, to some extent, introduced
in D.5.1, Chapter 6 (M9).
Slave Matchmakers The approach and algorithms used internally to the Assert-E
matchmaker are described in D.4.1 (M12) and D.4.2 (M24). Concerning the
Assert-O matchmaker, the relevant deliverables are D.3.1 for the state of the art
on ontological reasoning and requirements (M12), D.3.2 (M18) which presents
the first version of the Assert ontology. From a more technical perspective,
the Assert-O matchmaker is part of D.6.2 (where an initial version of the
component is used for the first integration phase). The deliverables that
present the conceptual framework underlying the Assert-M matchmaker are
D.5.1 (M9), which introduced the SeMF formalism and Assert-M model, and
D.5.2 (M24). Simplified versions of the three types of matchmakers are part
1 It should be noted that at the time of this writing, not all the referenced deliverables are publicly
available.
D.6.1 - Architecture and High-level Design
82 / 87
Assert4Soa
of D.6.2 (M24), although they are mostly used as placeholders to validate the
communication mechanisms and data model.
Assert Verifier, Assert Issuing Tool Together with the Assert language, these
elements are realised in the context of WP1. The Assert Issuing Tool (later
renamed to Assert Management Tool to reflect the larger scope it targets) is
part of D.1.2, appendix B (M24). Also relevant to these components are all
the deliverables presenting the Assert Language (D.1.1, D.1.3, D.1.2).
Ontology Manager As for the Assert-O matchmaker, the relevant deliverables are
D.3.1 (M12) and D.3.2 (M18).
Other components, such as the Entry Point, the Registry Abstraction Layer and
the underlying registries, the technical communication infrastructure (CAPI), the
refinements of the Assert Data Model, as well as component technology adopted for
the realisation of the architecture are covered in D.6.4 (M21) and D.6.2 (M24).
D.6.1 - Architecture and High-level Design
83 / 87
Assert4Soa
Bibliography
[1] NetBeans project. http://www.netbeans.org/index.html.
[2] OSGi Alliance website. http://www.osgi.org/Main/HomePage.
[3] About the OSGi service platform. http://www.osgi.org/wiki/uploads/
Links/OSGiTechnicalWhitePaper.pdf, June 2007.
[4] Owl 2 web ontology language direct semantics. w3c recommendation. http:
//www.w3.org/TR/owl2-direct-semantics, October 2009.
[5] OWL 2 Web Ontology Language structural specification and functionalstyle syntax. w3c recommendation.
http://www.w3.org/TR/2009/
REC-owl2-syntax-20091027, October 2009.
[6] Assert4SoaConsortium. Deliverable 2.1 - Asserts Aware Service Query
Language and Discovery Engine.
[7] Assert4SoaConsortium. Deliverable 3.1 - Requirements for an ontology
supporting certificates interoperability.
[8] Assert4SoaConsortium. Deliverable 7.1 - Framework Requirements.
[9] Assert4SoaConsortium. Assert4Soa- Description of Work, 2010.
[10] Sabrina Baselice, Piero A. Bonatti, and Marco Faella. On interoperable trust
negotiation strategies. In Proceedings of IEEE International Workshop on
Policies for Distributed Systems and Networks (POLICY’07), pages 39–50.
IEEE Computer Society, June 2007.
[11] E. Bertino, E. Ferrari, and A. C. Squicciarini. Trust-X: A peer-to-peer
framework for trust establishment. IEEE Transactions on Knowledge and Data
Engineering, 16(7):827–842, 2004.
[12] Piero A. Bonatti and Daniel Olmedilla. Driving and monitoring provisional
trust negotiation with metapolicies. In Proceedings of the 6th IEEE Workshop
on Policies for Distributed Systems and Networks (POLICY-05), pages 14–23.
IEEE Computer Society, 2005.
[13] David W. Chadwick and Alexander Otenko. The PERMIS X.509 role-based
privilege management infrastructure. In Seventh ACM Symposium on Access
Control Models and Technologies, pages 135–140. ACM Press, 2002.
D.6.1 - Architecture and High-level Design
84 / 87
Assert4Soa
[14] David W Chadwick, Gansen Zhao, Sassa Otenko, Romain Laborde, Linying
Su, and Tuan Anh Nguyen. PERMIS: a modular authorization infrastructure.
Concurrency and Computation: Practice and Experience, 20(11):1341–1357,
August 2008.
[15] David A. Chappell. Enterprise Service Bus. O’Reilly Media, 2004.
[16] E. Clayberg and D. Rubel. Eclipse: Building Commercial-Quality Plug-ins.
Pearson Education, 2006.
[17] Paul Clements, David Garlan, Len Bass, Judith Stafford, Robert Nord, James
Ivers, and Reed Little. Documenting Software Architectures: Views and Beyond.
SEI Series in Software Engineering. Pearson Education, second edition, October
2010.
[18] N. Ferguson and B. Schneier. Practical Cryptography. Number ISBN 0-47122357-3. Wiley, 2003.
[19] IEEE Computer Society. Recommended practice for architectural description IEEE Std-1471-2000, October 2000.
[20] ITU-T. The directory: Authentication framework - 08/05, 2005. ITU-T
Recommendation X.509, available at http://www.itu.int/rec/T-REC-X.509200508-I.
[21] Hristo Koshutanski and Fabio Massacci.
Interactive access control for
autonomic systems: from theory to implementation. ACM Transactions on
Autonomous and Adaptive Systems (TAAS), 3(3), August 2008.
[22] P.B. Kruchten. The 4+1 view model of architecture. Software, IEEE, 12(6):42
–50, nov 1995.
[23] Adam J. Lee, M. Winslett, and Kenneth J. Perano. TrustBuilder2: A
reconfigurable framework for trust negotiation. In Proceedings of the 3rd IFIP
WG 11.11 International Conference on Trust Management. Springer, 2009.
[24] Object Management Group. UML superstructure specification v2.1.1. OMG
Document Number formal/07-02-05 [Online]. Available: http://www.omg.org/
cgi-bin/apps/doc?formal/07-02-05.pdf. [Accessed: Sep. 9, 2011], 2007.
[25] David Lorge Parnas. Software engineering or methods for the multi person construction of multi - version programs. In Clemens Hackl, editor,
Programming Methodology, volume 23 of Lecture Notes in Computer Science,
pages 225–235. Springer, 1974.
[26] Dewayne E. Perry and Alexander L. Wolf. Foundations for the study of software
architecture. SIGSOFT Softw. Eng. Notes, 17:40–52, October 1992.
[27] Nick Rozanski and Eóin Woods. Software Systems Architecture: Working With
Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional,
2005.
[28] SAML.
Security
Assertion
http://saml.xml.org/saml-specifications.
D.6.1 - Architecture and High-level Design
Markup
Language
(SAML).
85 / 87
Assert4Soa
[29] K. Seamons, M. Winslett, and T. Yu. Limiting the disclosure of access control
policies during automated trust negotiation. In Proceedings of the Network and
Distributed System Security Symposium, April 2001.
[30] Dilip Soni, Robert L. Nord, and Christine Hofmeister. Software architecture
in industrial applications. In Proceedings of the 17th international conference
on Software engineering, ICSE ’95, pages 196–207, New York, NY, USA, 1995.
ACM.
[31] SPKI. SPKI certificate theory, 1999. IETF RFC 2693.
[32] A. Squicciarini, E. Bertino, Elena Ferrari, F. Paci, and B. Thuraisingham. PPtrust-X: A system for privacy preserving trust negotiations. ACM Transactions
on Information and System Security, 10(3):12, 2007.
[33] Harald Störrle. Semantics and verification of data flow in uml 2.0 activities.
Electronic Notes in Theoretical Computer Science, 127:35–52, 2005.
[34] R.N. Taylor, N. Medvidovic, K.M. Anderson, E.J. Whitehead Jr., J.E. Robbins,
K.A. Nies, P. Oreizy, and D.L. Dubrow. A component-and message-based
architectural style for gui software. Software Engineering, IEEE Transactions
on, 22(6):390–406, 1996.
[35] Mary Thompson, William Johnston, Srilekha Mudumbai, Gary Hoo, Keith
Jackson, and Abdelilah Essiari. Certificate-based access control for widely
distributed resources. In Proceedings of Eighth USENIX Security Symposium
(Security’99), pages 215–228, August 1999.
[36] W.H. Winsborough, K.E. Seamons, and V.E. Jones.
Automated trust
negotiation. In Proceedings of DARPA Information Survivability Conference
and Exposition (DISCEX), volume 1, pages 88–102. IEEE Press, 2000.
[37] Marianne Winslett. An introduction to trust negotiation. In First International
Conference on Trust Management (iTrust’03), volume 2692 of LNCS, pages
275–283. Springer, 2003.
[38] Prähofer H. Ms̈senbc̈k H. Wolfinger R., Dhungana D. A component plug-in
architecture for the .net platform. Lecture Notes in Computer Science, 4228,
2006. Proceedings of 7th Joint Modular Languages Conference, JMLC 2006
Oxford, UK, September 13-15.
[39] T. Y. C. Woo and S.S. Lam. Designing a distributed authorization service. In
Proceedings of Seventeenth Annual Joint Conference of the IEEE Computer and
Communications Societies. INFOCOM, volume 2, pages 419–429. IEEE Press,
1998.
[40] Thomas Y. C. Woo and Simon S. Lam. A framework for distributed
authorization. In Proceedings of the 1st ACM conference on Computer and
communications security, pages 112–118, 1993.
[41] X.509. The directory: Public-key and attribute certificate frameworks, 2005.
ITU-T Recommendation X.509:2005 | ISO/IEC 9594-8:2005.
D.6.1 - Architecture and High-level Design
86 / 87
Assert4Soa
[42] Ting Yu, Xiaosong Ma, and Marianne Winslett. Prunes: an efficient and
complete strategy for automated trust negotiation over the internet. In
Proceedings of the 7th ACM conference on Computer and communications
security (CCS ’00), pages 210–219. ACM, 2000.
[43] Ting Yu, Marianne Winslett, and Kent E. Seamons. Supporting structured
credentials and sensitive policies through interoperable strategies for automated
trust negotiation. ACM Transactions on Information and System Security
(TISSEC), 6(1):1–42, 2003.
[44] M.E. Zurko, R. Simon, and T. Sanfilippo.
A user-centered, modular
authorization service built on an RBAC foundation. In Proceedings of the IEEE
Symposium on Security and Privacy, pages 57–71. IEEE Press, 1999.
D.6.1 - Architecture and High-level Design
87 / 87