Reference Architecture for eAuthentication and

Transcription

Reference Architecture for
eAuthentication and eAuthorisation
Brigitta Lange (NEC), Dieter Sommer (IBM), Frederic Motte (THA),
Shiping Chen (CSO), Daniel Pletea (PRE), Felix Gomez Marmol (NEC),
Stefan Thaler (TU/e), Koel Ghorai (NSW), Maarten Kluitman (BIC),
Tanya Ignatenko (TU/e), Chun Ruan (MQ), Saeed Sedghi (PRE),
Peter Bertok (RMI), Vijay Varadharajan (MQ),
Alfredo Rial (IBM), Daniel Kovacs (IBM), Paul Koster (PRE)
This project has received funding from the
European Union’s Seventh Framework Programme for research, technological development and demonstration under grant agreement no: 611659
FP7-ICT 611659 AU2EU
October 27, 2014
Deliverable D1.4.1
Reference Architecture for eAuthentication & eAuthorisation
2
Deliverable D1.4.1
Project Information
Authentication and Authorisation for Entrusted Unions
Project number:
611659
Strategic objective:
ICT-2013.1.4.e
Starting date:
2013-12-01
Ending data:
2015-11-30
Website:
http://au2eu.eu/
Document Information
Title:
ID:
D1.4.1
Type: R
Dissemination
PU
level:
Month: M10
Release date:
27. October 2014
Deliverable Description
D1.4.1 Reference Architecture for eAuthentication & eAuthorisation provides the description of the joint
reference architecture for eAuthentication and eAuthorisation, including components functionalities
and interfaces. Identifies and presents the missing elements required to achieve the research and practical goals of this project.
Contributors, Editor & Reviewer Information
Contributors (person
(partner): sections)
Editor (person/partner)
Reviewer (person/
partner)
October 27, 2014
Brigitta Lange (NEC): Sections 1, 2, 3, 4, 4.2, 4.3, 4.4, 4.6, 5, 8.2.3, 9, 10
Dieter Sommer (IBM): Sections 3, 5,6, 7
Frederic Motte (THA): Sections 5, 7,Appendix B
Shiping Chen (CSO): Sections 3.1, 4.1, 8.1.1
Daniel Pletea (PRE): Sections 4, 4.3, 4.4, 8.1.3, 8.1.4, Appendix C
Felix Gomez Marmol (NEC): Sections 8, 8.1, 8.1.2, 9, 9.4
Stefan Thaler (TU/e): Section 4.5.1, 4.5.2, 4.5.3
Koel Ghorai (NSW): Section 8.2
Maarten Kluitman (BIC): Section 4.6.1
Tanya Ignatenko (TU/e): Section 8.1.5
Chun Ruan (MQ): Section 9.1
Saeed Sedghi (PRE): Section 9.2
Peter Bertok (RMI): Section 9.3
Alfredo Rial (IBM): Appendix A
Daniel Kovacs (IBM): Appendix A
Paul Koster (PRE): Appendix C
Brigitta Lange/NEC
StefanThaler/ TU/e
Peter Bertok/RMI
Vijay Varadharajan/MQ
3
October 27, 2014
Deliverable D1.4.1
4
Deliverable D1.4.1
Release History
Release
number
1.0
1.1
1.2
Date issued
Milestone*
03.09.2014
24.10.2014
27.10.2014
Proposed
Revised
Released
SVN version
Release description / changes made
Release for Internal Review
Revised based on Reviews
Final Revision
* The project uses a multi-stage internal review and release process, with defined milestones. Milestone names include abbreviations/terms as follows:
1. PCOS = ”Planned Content and Structure” (describes planned contents of different sections)
2. Intermediate: Document is approximately 50% complete – review checkpoint
3. External For release to commission and reviewers
4. proposed: Document authors submit for internal review
5. revised: Document authors produce new version in response to internal reviewer comments
6. approved: Internal project reviewers accept the document
7. released: Project Technical Manager/Coordinator release to Commission Services
October 27, 2014
5
Deliverable D1.4.1
AU2EU Consortium
Full Name
Technische Universiteit Eindhoven
Philips Electronics Nederland B.V.
Bicore Services B.V.
NEC Europe LTD
IBM Research GMBH
Deutsche Rotes Kreuz
Thales Communications & Security SAS
Commonwealth Scientific and Industrial
Research Organisation
Edith Cowan University
Royal Melbourne Institute of Technology
University of New South Wales
Macquarie University
Abbreviated Name
TU/e
PRE
BIC
NEC
IBM
DRK
THA
Country
Netherlands
Netherlands
Netherlands
United Kingdom
Switzerland
Germany
France
CSO
Australia
ECU
RMI
NSW
MQ
Australia
Australia
Australia
Australia
Table 1 Consortium Members
October 27, 2014
6
Deliverable D1.4.1
Table of Contents
Release History ....................................................................................................................................... 5
AU2EU Consortium ................................................................................................................................. 6
Table of Contents .................................................................................................................................... 7
List of Figures ........................................................................................................................................ 11
List of Tables ......................................................................................................................................... 12
1
Executive Summary ....................................................................................................................... 13
2
About this Document .................................................................................................................... 14
3
2.1
Role of the Deliverable.......................................................................................................... 14
2.2
Relationship to other AU2EU Deliverables ........................................................................... 14
2.3
Relationship to other Versions of this Deliverable ............................................................... 14
2.4
Structure of this Document .................................................................................................. 14
Introduction .................................................................................................................................. 15
3.1
4
Approach ............................................................................................................................... 17
Requirements of the AU2EU Use Cases ........................................................................................ 19
4.1
Biosecurity Incident Response Use Case Analysis................................................................. 22
4.1.1
Step 1 - Map the Requirements to Security Components and Functionalities............. 22
4.1.2
Step 2 - Consolidation with Existing Reference Architectures ...................................... 28
4.1.3
Step 3 - Design of the Required Components ............................................................... 29
4.2
eHealth/AAL Use Cases Analysis ........................................................................................... 30
4.2.1
Functional Security Requirements Mapping................................................................. 30
4.2.2
Non-Functional Requirements ...................................................................................... 34
4.2.3
Consolidation with Existing Reference Architectures ................................................... 35
4.3
Translational Research Use Case Analysis ............................................................................ 35
4.3.1
Functional Requirements .............................................................................................. 35
4.3.2
4.3.3
Translational Research Use Case Requirements Mapping ........................................... 36
4.4
PACS Use Case Analysis ......................................................................................................... 37
4.4.1
4.4.2
4.4.3
PACS Use Case Requirements Mapping ........................................................................ 38
4.5
DNA Data Management in Clinical Trials Use Case Analysis ................................................. 39
4.5.1
4.5.2
4.5.3
DNA Use Case Requirements Mapping ......................................................................... 40
4.6
Legal and Business Requirements Analysis........................................................................... 40
October 27, 2014
7
4.6.1
5
General Design and Deployment Aspects ..................................................................... 41
Functionality ................................................................................................................................. 43
5.1
eAuthentication .................................................................................................................... 44
5.1.1
Authentication with Identity Federation ...................................................................... 44
5.1.2
Authentication with Single Sign-On Functionality ........................................................ 44
5.1.3
Authentication Methods ............................................................................................... 44
5.2
6
Deliverable D1.4.1
eAuthorisation ...................................................................................................................... 44
5.2.1
Authorisation based on User Attributes ....................................................................... 44
5.2.2
Privacy of User Attributes ............................................................................................. 45
5.2.3
Multi-Organisational Context ....................................................................................... 45
5.2.4
Break-the-Glass ............................................................................................................. 46
Architecture .................................................................................................................................. 47
6.1
Towards AU2EU .................................................................................................................... 47
6.2
Section Outline...................................................................................................................... 47
6.3
Authentication ...................................................................................................................... 47
6.3.1
Third-Party-Certified User Attributes............................................................................ 47
6.3.2
Plurality of Issuers Certifying User Attributes ............................................................... 48
6.3.3
Parties and Roles ........................................................................................................... 48
6.3.4
Identity Relationships ................................................................................................... 49
6.3.5
User Agent..................................................................................................................... 53
6.3.6
User Consent ................................................................................................................. 53
6.3.7
Privacy ........................................................................................................................... 53
6.3.8
Security ......................................................................................................................... 54
6.3.9
Generic Support of Multiple Authentication Technologies .......................................... 54
6.3.10
TDL and ABC4Trust........................................................................................................ 57
6.4
Authorisation ........................................................................................................................ 57
6.4.1
Privacy Issues of the Traditional XACML Architecture .................................................. 57
6.4.2
AU2EU Architecture ...................................................................................................... 58
6.4.3
Using the Cloud ............................................................................................................. 58
6.4.4
AU2EU Integration with Legacy and New Applications ................................................ 58
6.4.5
Architecture .................................................................................................................. 58
6.4.6
Discussion...................................................................................................................... 60
6.5
Ontologies ............................................................................................................................. 60
6.5.1
Open Systems................................................................................................................ 60
6.5.2
Bridging Domains .......................................................................................................... 61
6.6
Assurance .............................................................................................................................. 64
October 27, 2014
8
6.7
Traditional Approach .................................................................................................... 64
6.7.2
Cloud-Based Approach .................................................................................................. 65
6.7.3
Access Control ............................................................................................................... 66
Legacy Integration................................................................................................................. 66
6.8.1
Attribute Sources .......................................................................................................... 67
6.8.2
Authentication .............................................................................................................. 68
6.9
Overview of Deployment of an AU2EU System in Real-World Settings ............................... 68
6.10
Building on and Leveraging Existing Architectures ............................................................... 69
6.11
Trust Management ............................................................................................................... 69
6.12
Conclusions ........................................................................................................................... 70
Components .................................................................................................................................. 71
7.1
Authentication ...................................................................................................................... 71
7.1.1
Parties ........................................................................................................................... 71
7.1.2
Authentication Libraries................................................................................................ 72
7.2
8
Cloud Deployment ................................................................................................................ 64
6.7.1
6.8
7
Deliverable D1.4.1
Authorisation ........................................................................................................................ 73
7.2.1
The Local Administration Point ..................................................................................... 73
7.2.2
Policy Administration Point........................................................................................... 73
7.2.3
Local Mapper ................................................................................................................ 73
7.2.4
Local Policy Validator .................................................................................................... 74
7.2.5
Federal Administration Point ........................................................................................ 74
7.2.6
Policy Repository ........................................................................................................... 74
7.2.7
Policy Decision Point ..................................................................................................... 74
7.2.8
Policy Enforcement Point .............................................................................................. 75
7.2.9
Policy Information Point ............................................................................................... 75
Challenges of Large Dynamic Cross-Domain Collaborations ........................................................ 76
8.1
Challenges based on the AU2EU Use Case Analysis ............................................................. 76
8.1.1
Biosecurity Incident Response Use Case Challenges .................................................... 76
8.1.2
eHealth/AAL Use Case Challenges ................................................................................ 76
8.1.3
PACS Use Case Challenges ............................................................................................ 77
8.1.4
Translational Research Use Case Challenges ................................................................ 78
8.1.5
DNA Data Management in Clinical Trials Use Case Challenges .................................... 78
8.2
Challenges from a Legal and Business Perspective ............................................................... 79
8.2.1
Legal Challenges ............................................................................................................ 79
8.2.2
Legal Challenges Specific to the eHealth/AAL Pilot Use Cases ..................................... 80
8.2.3
Outlook.......................................................................................................................... 80
October 27, 2014
9
9
Deliverable D1.4.1
Extensions to the joint eAuthentication and eAuthorisation Framework .................................... 81
9.1
Assurance of Claims .............................................................................................................. 81
9.2
Policy Enforcement ............................................................................................................... 82
9.3
Trust Indicators ..................................................................................................................... 82
9.4
Processing Encrypted Information ........................................................................................ 82
10
10.1
Conclusion ................................................................................................................................. 84
Outlook ................................................................................................................................. 84
Glossary ................................................................................................................................................. 85
Bibliography .......................................................................................................................................... 88
A. Appendix:
ABC4Trust Reference Architecture Building Blocks .................................................. 90
B. Appendix:
TAS3 Reference Architecture Building Blocks ........................................................... 94
C. Appendix:
TDL Reference Architecture Building Blocks ........................................................... 100
October 27, 2014
10
Deliverable D1.4.1
List of Figures
Figure 1 The AU2EU Concept ............................................................................................................... 15
Figure 2 eAuthentication Framework – Claims-based Architecture .................................................... 16
Figure 3 eAuthorisation Framework – Attribute-based Authorisation................................................ 16
Figure 4 The Joint AU2EU Reference Framework and Extensions ....................................................... 17
Figure 5 Approach towards AU2EU Reference Architecture ............................................................... 18
Figure 6 Reference Architecture (general)........................................................................................... 20
Figure 7 Reference Architecture (detailed) ......................................................................................... 20
Figure 8 Problem of Authenticating in Today’s Communication Networks ........................................ 47
Figure 9 Solution for Authentication in Today’s Communication Networks ....................................... 48
Figure 10 Identity Relationships ........................................................................................................... 50
Figure 11 Authentication Message Flow............................................................................................... 52
Figure 12 Parties Involved in Generic Authentication .......................................................................... 55
Figure 13 Generic Authentication Architecture of AU2EU for Two Parties .......................................... 55
Figure 14 Vocabulary Mapping ............................................................................................................. 61
Figure 15 Flow ....................................................................................................................................... 63
Figure 16 Traditional Architecture ........................................................................................................ 65
Figure 17 Cloud-based Architecture ..................................................................................................... 65
Figure 18 Main Components of AU2EU Parties .................................................................................... 71
Figure 19 Extensions to the Joint eAuthentication and eAuthorisation Framework ........................... 81
Figure 20 Entities and Interactions Diagram of ABC4Trust .................................................................. 90
Figure 21 Overview of the ABC4Trust Architecture on the User Side .................................................. 91
Figure 22 Presentation of a Token ........................................................................................................ 92
Figure 23 Issuance of a Credential ........................................................................................................ 93
Figure 24 TAS3 Main Components........................................................................................................ 95
Figure 25 TAS3 Authorisation Infrastructure ........................................................................................ 97
Figure 26 TAS3 Authorisation Workflow............................................................................................... 98
Figure 27 Overview of TDL .................................................................................................................. 100
Figure 28 TDL Architecture Overview ................................................................................................. 102
October 27, 2014
11
Deliverable D1.4.1
List of Tables
Table 1
Table 2
Table 3
Table 4
Table 5
Table 6
Table 7
Table 8
Table 9
Table 10
Table 11
Table 12
Table 13
Table 14
Table 15
Table 16
Table 17
Table 18
Consortium Members ............................................................................................................. 6
Building Blocks of ABC4Trust, TAS3 and TDL ........................................................................ 19
Biosecurity Incident Response Use Case - Mapping of Participant Management................ 23
Biosecurity Incident Response Use Case - Mapping of Infrastructure Requirements .......... 23
Biosecurity Incident Response Use Case - Mapping of EAD Response Management .......... 28
Biosecurity Incident Response Use Case - Reference Architecture Consolidation ............... 28
Biosecurity Incident Response Use Case - Component Design............................................. 29
eHealth/AAL Use Cases - eAuthentication Requirements Mapping ..................................... 31
eHealth/AAL Use Cases - eAuthorisation Requirements Mapping ....................................... 32
eHealth/AAL Use Cases - Mapping of Identities, Attributes and Credentials ....................... 32
eHealth/AAL Use Cases - Security of Data Transmission, Storage and Processing ............... 33
eHealth/AAL Use Cases - Security of Mobile Device ............................................................. 34
eHealth/AAL Use Cases - General Requirements Mapping................................................... 34
eHealth/AAL Use Cases - Mapping of Non-Functional Requirements .................................. 35
Translational Research Use Case - Requirements Mapping .................................................. 37
PACS Use Case - Requirements Mapping .............................................................................. 38
DNA Data Management in Clinical Trials Use Case - Requirements Mapping ...................... 40
Functionalities required by the AU2EU Use Cases ................................................................ 43
October 27, 2014
12
Deliverable D1.4.1
1 Executive Summary
This document provides the core element of the AU2EU project, i.e. the consolidated joint reference
architecture for eAuthentication and eAuthorisation.
Starting with the existing reference architectures for eAuthentication and/or eAuthorisation
ABC4Trust, TAS3, and TDL, complex cross-domain collaboration scenarios are analysed with respect
to security and privacy requirements. Based on these results the joint eAuthentication and eAuthorisation framework is developed for secure and trusted handling of sensitive information which will
enable efficient collaborations and delivery of services in complex business environments.
October 27, 2014
13
Deliverable D1.4.1
2 About this Document
2.1 Role of the Deliverable
This deliverable (D1.4.1) is a core deliverable of the AU2EU Project. It describes the joint reference
architecture for eAuthentication and eAuthorisation that is designed to fulfil the security, privacy,
and trust requirements of the distributed, dynamic AU2EU collaboration use cases. Furthermore, it is
consolidated based on the existing eAuthentication and eAuthorisation architectures ABC4Trust [1],
TAS3 [2], and TDL [3].
2.2 Relationship to other AU2EU Deliverables
Deliverable D1.4.1 relies on the results of deliverable D1.1.1 (Detailed Descriptions of Use Cases) [4]
and deliverable D1.2.1 (Requirements Specification) [5] each providing the necessary prerequisites
for analysing, describing and consolidating the joint reference architecture. Within WP1, D1.4.1 is
also mutually dependent on deliverable D1.3.1 (Business & Legal Analysis) [6].
The consolidated reference architecture forms the underlying basis for nearly all deliverables of
AU2EU WP2-WP7. Deliverable D1.4.1 has direct impact on the following:
•
•
•
•
•
•
•
D2.1.1 Requirements and architecture for cloud-based authentication services;
D3.1.1 Tools for semantic mapping of attributes;
D3.2.1 Administration mechanisms for unifying authorisations;
D4.1.1 Techniques for assurance of claims;
D4.2.1 Cryptographically enforced access control;
D4.3.1 Attack and countermeasure model;
D4.4.1 Techniques for storing processing and accessing information under encryption;
2.3 Relationship to other Versions of this Deliverable
This document is the proposed deliverable D1.4.1 released for internal review. It replaces all prior
and intermediate versions.
2.4 Structure of this Document
This document analyses, describes and consolidates the joint reference architecture for eAuthentication and eAuthorisation and is structured as follows:
First, an analysis of the security requirements of the AU2EU use cases and Pilots and their mapping
towards the reference architectures is given. Then the necessary eAuthentication and eAuthorisation functionalities of the AU2EU use cases are extracted and described as a prerequisite for the
design of the joint AU2EU reference architecture. Subsequently, the AU2EU reference architecture is
described and related to other architectures. Thereafter, an overview of the high-level architecture
components of the AU2EU reference architecture is provided. Next, challenges for the design and
deployment of an integrated eAuthentication and eAuthorisation framework by large dynamic crossdomain collaborations across jurisdictions are presented. Finally, an outlook on extensions and advancements of the AU2EU reference architecture is given.
In the Appendix of this document, building blocks of reference architectures considered for the consolidation (i.e. ABC4Trust, TAS3 and TDL) are presented.
October 27, 2014
14
Deliverable D1.4.1
3 Introduction
Figure 1 The AU2EU Concept
The AU2EU reference architecture is a generic high-level view on the AU2EU technical architecture.
The reference architecture has been derived from the use case requirements (see also Figure 1),
particularly from the two AU2EU pilot use cases as well as prominent requirements for authorising
access to Web-based services in the everyday interactions of people on the Web.
This document presents the AU2EU use case requirements and from those derives the functionalities for the reference architecture before presenting the architecture itself. The reference architecture thereby can capture a large fraction of today’s use cases for privacy-preserving eAuthentication
and eAuthorisation. However, it is unrealistic to assume that a single architecture can address all use
cases. For this reason, we define how the reference architecture can be extended with further building blocks resulting from research in AU2EU to cover additional use cases (refer to sections 4, 8 and
9).
In a nutshell, the AU2EU reference architecture discusses privacy-preserving authentication and
authorisation based on authenticated attribute assertions. That is, it captures the subset of use case
requirements that are related to privacy-preserving authentication and authorisation. The architecture comprises an authentication part which is integrated in a way that preserves the privacy properties of the authentication party with an authorisation part.
October 27, 2014
15
Deliverable D1.4.1
Figure 2 shows the abstract architecture for privacy-preserving authentication using privacyrespecting attribute-based credentials (privacy-ABCs).
Figure 2 eAuthentication Framework – Claims-based Architecture
Figure 3 shows the abstract architecture for privacy-preserving authorisation, where the authorisation decision is based on authenticated attributes.
Figure 3 eAuthorisation Framework – Attribute-based Authorisation
October 27, 2014
16
Deliverable D1.4.1
Details to the authentication and authorisation parts of the reference architecture will be given in
section 6.3 and section 6.4. These sections will comprise details on the functionalities as well as
components and their interaction.
Readers who are familiar with the TDL [3], ABC4Trust [1], and TAS3 [2] architectures will recognise
aspects of those architectures for their privacy-preserving capabilities.
Figure 4 The Joint AU2EU Reference Framework and Extensions
3.1 Approach
We expect our reference architecture to be generic enough to reflect common requirements for
security and privacy in various applications, and at the same time sufficiently practical to address
security and privacy issues in real applications. As a result, we adopt a scenario-driven approach to
design the reference architecture for eAuthentication and eAuthorisation, as shown in Figure 5.
October 27, 2014
17
WP1.D1.1.1
Use Cases
Deliverable D1.4.1
AAL
BIR
WP1. D1.2.1
Requirements
DNA
PACS
TR
Detailed description of functional &
non-functional requirements
Security vs. Application
Requirements
Application-Specific
Requirements
Security Requirements
Common Security
Components &
Artifacts
…...
ID
Policies
PDP
Consolidate with
the Existing
Architectures
Security Components in the Existing 3 Architectures
New/Extended
Components
Joint Reference
Architecture for
eAuthentication &
eAuthorisation
Figure 5 Approach towards AU2EU Reference Architecture
In particular, first, we select and filter relevant security and privacy requirements from the ones that
have been derived from the AU2EU use cases (D1.2.1 [5]). Then we consolidate the existing authentication and authorisation architectures (TAS3 [2], ABC4Trust [1], TDL [3], etc.) to decide whether existing components can be reused or new ones should be introduced. Finally, we combine these security components to the AU2EU joint reference architecture for eAuthentication and eAuthorisation.
October 27, 2014
18
Deliverable D1.4.1
4 Requirements of the AU2EU Use Cases
This section describes the first step towards the consolidation of the joint reference architecture.
Following the overall AU2EU concept and approach (Figure 1, Figure 5) for all AU2EU use cases we
will analyse how the joint reference architecture for eAuthentication and eAuthorisation meets the
security requirements derived from D1.2.1 [5]. Based on this use case analysis we identify high-level
building blocks and functionalities that are needed to design and consolidate the reference architecture.
Since the consolidation of the reference architecture is based on existing authentication/authorisation architectures, i.e. ABC4Trust, TAS3, and TDL ( [1], [2], [3]), first the AU2EU use
case requirements are mapped to general building blocks (components and functionalities) of these
architectures (refer to sections 4.1 – 4.5). An overview of building blocks already provided by these
architectures is presented below (see Table 2).
Authentication/Authorisation Architectures
Authentication
Authorisation
ABC4Trust
Verifier
Credential
Store
Identity
Provider
Credential
Store
Identity
Provider
Verifier
Collaboration
Administration
TAS3
Identity Provider
Id Mapper
Id Aggregator
Trust and
Reputation
Credential and
Policy Negotiator
Authorisation
Ontology Handler
Delegation Service
TDL
Identity
Provider (IdP)
Attribute
Provide (AtP)r
Common
Identity
Provider
(IdP)
Attribute
Provider
(AtP)
Attribute
Provider
User Identity
Agent (UIA)
Validator
(RP,CP)
Authorisation
Token
Verification
Ontology Mapper
Key
Management:
Encryption Keys
Credential
Store
(internal)
Life-Cycle
Management:
Credential; Key;
Data
Auditing,
Logging
Credential
Life Cycle
New
Policy
Synchroniser/
Extractor
(for consistency
tracking)
Collaboration
Administration
Key
Management
System
(PACS)
Trust and
Reputation
Policies
Id Life Cycle
Auditing Bus
Event Monitoring
Compliance Testing
Monitoring
Functions for
Accountability
Billing
Table 2 Building Blocks of ABC4Trust, TAS3 and TDL
In Table 2 the existing building blocks of ABC4Trust, TAS3, and TDL are categorised into authentication and authorisation functionalities. They are also associated to categories relevant for enabling
trusted, dynamic, cross-domain collaboration scenarios (e.g. collaboration administration, encrypOctober 27, 2014
19
Deliverable D1.4.1
tion key management, life-cycle management, as well as auditing and logging). In addition to building blocks common to all these architectures also new ones have been identified.
A comprehensive specification and overview of the ABC4Trust, TAS3, and TDL architectural building
blocks and components can be found in the appendix A, B and C respectively.
Figure 6 depicts a high-level representation of a joint reference architecture composed from the
common building blocks provided by the existing architectures (see Table 2 above) and illustrates its
application to a collaboration scenario.
Figure 6 Reference Architecture (general)
Figure 7 shows a more detailed graphical representation of the general reference architecture (presented in Figure 6) with respect to the authorisation building blocks (described in Table 2 above) and
illustrates an integration of the key management building block for privacy enhanced access to data
in a cloud-based collaboration scenario.
Figure 7 Reference Architecture (detailed)
The use case analysis will start with the two AU2EU Pilot use cases (i.e. the Biosecurity Incident Response use case and the eHealth/AAL use cases), followed by the Translational Research use case.
Then the PACS use case and the DNA Data Management in Clinical Trials use case will be analysed.
For each use case general functional as well as non-functional security requirements are classified
and matched with the architectural building blocks of the existing reference architectures (Table 2)
October 27, 2014
20
Deliverable D1.4.1
Furthermore new building blocks and functionality as required by the individual use cases will be
identified.
Finally some general requirements to be considered from the legal and business analysis perspective
are presented.
In the second step towards the design and consolidation of the joint reference architecture, a summary and specification of the functionalities required by all AU2EU collaborative use cases with respect to eAuthentication and eAuthorisation is presented in section 5.
October 27, 2014
21
Deliverable D1.4.1
4.1 Biosecurity Incident Response Use Case Analysis
Biosecurity Incident Response (BIR) is a real use case derived by CSIRO to show how multiple government agents collaborate with each other once an animal disease incident occurs in Australia (for
details refer to [4]). Following the approach discussed in Section 3.1, we identify the required security components by analysing and filtering out all the requirements derived from the Biosecurity Incident Response use case. Then, we consolidate with the existing security reference architectures to
classify the components in terms of their functionalities and relationships with these existing architectures. Finally, we provide a high-level design for each component that needs to be integrated into
our reference architecture.
4.1.1
Step 1 - Map the Requirements to Security Components and Functionalities
4.1.1.1 Participant Management
No. Requirement
1 The system can add, modify and delete
organisations that may participate in
CCEAD meetings.
2 AHA can specify its members from the
organisations listed in the system.
3 An organisation can define the roles in
this organisation.
4 Organisations need to agree with AHA
EADRA and agree to follow the
AUSVETPLAN recommendations in case
of an EAD before they are accepted
into the system.
5 An individual from an organisation
listed in the system can register with
full contact details: name, organisation,
role, e-mail address, mobile and desk
phone number.
6 The system can check whether an individual participant is able to correctly
login to their respective organisations
information system.
7 AHA member organisations can subscribe a federated identity scheme to
allow access from their own respective
organisations.
8 CCEAD Secretariat Officer (CSO) maintains all participants CCEAD Identity for
an EAD.
9 A CCEAD meeting member can share
his identity across multiple EAD cases.
10
Domain
Security
Application
Application
Application
Security
ID Management/ Update ID
Authentication
Security
Login/
Authentication
Login Monitor/Auditing
Security
Authentication
ID federation
ID Management/
Authentication
ID can be reused for multiple concurrent collaborations
Login
Assis-
Application
Security
If a participant fails to login for a CCEAD Security
October 27, 2014
Component
Functionality
ID Management/ Create/
Authentication
Update/
Delete ID
Login/
22
Deliverable D1.4.1
meeting, the system first checks
whether the participant still has a valid
identity in the corresponding organisation. If still valid, then the system can
issue a temporary login credential;
otherwise, the participant is prevented
from attending the meeting.
Authentication
tant
Table 3 Biosecurity Incident Response Use Case - Mapping of Participant Management
4.1.1.2 Infrastructure Management
No. Requirement
1 High speed network connectivity is needed to
connect CCP units.
2 The networked servers for
control messages and
shared workspaces are in
place for CCEAD meetings.
3 All inside and outside CCP
units can connect to each
other with video conferencing and access all
workspace servers (i.e.,
with firewall rules configured properly).
4 Instruments within AAHL
are able to be connected
to the network from the
CCEAD meeting.
5 All CCP units can access to
the documents storage
maintained by the Agriculture Department if
allowed.
6 Other conferencing systems, such as Skype, can
connect to CCP units.
Domain
Infrastructure
Component
Functionality
PDP/
Authorisation
Decide if allowing to
access
documents
(resources)
Application
Infrastructure
Application
Security
Application Software
Table 4 Biosecurity Incident Response Use Case - Mapping of Infrastructure Requirements
4.1.1.3 EAD Response Management
No.
1.1
Requirement
Domain
Anyone can notify a sus- Security
pect EAD through the system, hence creating a new
EAD case to be managed
October 27, 2014
Component
ID management/
Authentication
Functionality
Get contacts
23
1.2
1.3
1.4
1.5
2.1
2.2
2.3
2.4
2.5
with the system. The system needs the full contact
details of the person, who
is creating this new EAD
case.
The relevant States Chief
Veterinary Officer (CVO)
gets notified about a new
EAD by
the system.
The CVO creates a task in
the system to organise
veterinary field officers to
investigate the suspect
EAD.
Veterinary field officers
submit a formal report
about the investigation
task to the system.
CVO can record in the system the decision made
according to the report. If
the EAD is conformed, this
EAD case moves to Alert
phase, otherwise this case
is terminated.
The CVO of the affected
state (CVO-A) submits a
notification on the new
EAD case to
the Australian CVO (ACVO)
and the NMG chair within
24 hours after this new
EAD case enters into the
Alert Phase.
The CVO-A is warned if the
EAD case is not notified
within 24 hours.
The Australian CVO (ACVO)
and the NMG chair get a
notification to review the
new EAD case.
All AHA members listed in
the system, other than the
ACVO and NMG chair, also
receive the notification for
advisory purposes
The CVO-A, ACVO and the
NMG Chair determine
October 27, 2014
Deliverable D1.4.1
Application
Application
Application
Application
Application
Application
Application
Application
Application
24
2.6
3.1
3.2
3.3
3.4
3.5
3.6
3.7
whether a response needed for this EAD case. All
AHA members listed in the
system are notified of the
decision.
If a response is needed,
the EAD response case
enters into the Preliminary
Phase; otherwise, the case
is terminated.
The ACVO advises the initial members for forming
the CCEAD meeting for this
new
EAD case from the AHA
member listed in the system.
The ACVO can determine
whether the video and
audio of the CCEAD meetings for an
EAD case should be recorded.
The CCEAD Secretariat
Officer
(CSO)
records
whether an initial CCEAD
member has been notified
by phone.
An initial CCEAD member
can login to the system to
confirm the membership
and attendance of relevant
staff from its organisation;
the system checks whether
this member has informed
the respective organisation
about his or her attendance.
The member can also nominate a delegate if she or
he cannot attend.
The CSO can check the list
of initial CCEAD members
who can or cannot attend
the
CCEAD meeting.
The initial CCEAD members
who can attend the CCEAD
meeting are added by the
system to an access con-
October 27, 2014
Deliverable D1.4.1
Application
Application`
Application
Application
Security
Login/Authentication
Login
Security
Login/Authentication
ID Delegation
Collaboration Admin
ACL/Policy
Generation
Application
Security
25
3.8
4.1
4.2
4.3
4.4
4.5
4.6
4.7
trol list, so that they can
access all information in
the CCEAD meeting; the
CSO has the veto rights.
After receiving confirmation from all initial members, the system enters
into
the
Operational
Phase; the CSO can change
the system into the Operational phase if not all initial
members provide conformations.
CVO-A and CSO are required to submit an EAD
response plan (EADRP).
The NMG chair approves
the EADRP and finalise the
cost-sharing response arrangements; and then the
system notifies all CCEAD
members that the EADRP
is now initiated and legally
binding within the jurisdiction of the affected state.
The system allows the
CVO-A to raise a dispute,
which should be approved
by the Department of Agriculture and then forwarded to the ACVO.
All CCEAD members can
submit documents related
to this EAD case.
The CSO checks each submitted document before
releasing it to all CCEAD
members; the system records the check result (release or not release).
All CCEAD members can
read the released documents related to this EAD
case. Only the CSO can
read unreleased documents.
CCEAD members must
register their use of CCP
units into the system (e.g.,
who is sitting in front of a
October 27, 2014
Deliverable D1.4.1
Application
Application
Application
Application
Application
Application
Security
PDP/Authorisation
Access
control to
released &
unreleased
document
Security
PDP/Authorisation
To join a
collaboration
26
4.8
4.9
4.10
4.11
5.1
5.2
CCP unit and their location). The system will approve this use of CCP in a
CCEAD meeting based on
the access control list.
Note that only one member in one location needs
to authenticate to a CCP
and all members in the
location must register.
Before starting a CCEAD
meeting, the system asks
the CSO to confirm that he
or she has checked whether all participants sitting
before each CCP are those
who registered (i.e. roll call
is performed). An unregistered individual should
leave the meeting room
before the meeting starts.
A CCP can access a shared
workspace if its registration is approved.
The CSO can record the
contents discussed in a
CCEAD meeting into the
system.
The
CSO
can
create/maintain/delete
a
CCEAD meeting schedule
and the system can remind
participants of a due meeting.
CVO-A changes the state of
the EAD case into STANDDOWN with the declaration that this phase has
been nominated in CCEAD
meeting.
The CSO confirms this state
change and the system
sends all CCEAD members
a notification that the EAD
in this case is no longer
active. Alternatively, the
CSO rejects this state
change and the system
remains in the operational
phase.
October 27, 2014
Deliverable D1.4.1
Application
Application
Application
Security
PDP/Authorisation
Access
Control
Data
to
Application
Application
27
5.3
5.4
6.1
6.2
6.3
The CSO can change the
members of CCEAD for this
EAD case.
In this phase, CVO-A needs
to submit a negative emergency report, which is distributed to all CCEAD
members. This EAD case
enters into the Terminated
Phase.
The CSO removes all members of the CCEAD meetings for this EAD case from
the access control list except him/herself.
The CSO archives all workflow, provenance, meeting
records, discussions into
the Department of Agriculture data store.
The CSO terminates the
process for this EAD case.
Deliverable D1.4.1
Application
Application
Security
Collaboration Admin
Update/
Remove
Policies
Application
Application
Table 5 Biosecurity Incident Response Use Case - Mapping of EAD Response Management
4.1.2
Step 2 - Consolidation with Existing Reference Architectures
Component
ID Management
Authentication
Functionality
Create/Update/Delete
ID
ID Federation
Authentication



Collaboration
Administration

Authorisation
Login
Login Assistant
Login Auditing
Create a policy on
the fly
 Update a policy
 Remove a policy
Access control to resources, i.e. conference/document
TAS3
IdP
ID Mapper
Pseudonymous
Linking Identity
Selector (LIS)
Auditing Bus
Event Monitoring
Compliance Testing
ABC4Trust
IdP
TDL
New
IdP
User Identity
Agent (UIA)
Provider
Attribute-Based
Authentication
Monitoring
Functions for
Accountability
Billing
Collaboration
Admin
Master PDP
Security Token
Verification
Credentialbased access
control
Table 6 Biosecurity Incident Response Use Case - Reference Architecture Consolidation
October 27, 2014
28
4.1.3
Deliverable D1.4.1
Step 3 - Design of the Required Components
Component in UML
Interface
Port
Dependence
CreateAccount
UpdateAccount
DeleteAccount
Web
SOAP
REST
POJO
ID Database
or
ID LDAP
IsValidUser
SOAP
REST
POJO
ID Database
or
ID LDAP
or
rd
3 Party
SAML Service
CreatePolicy
GetPolicy
UpdatePolicy
StopPolicy
DeletePolicy
Web
SOAP
REST
POJO
Persistent Storage
Web
SOAP
REST
TelConfInfra
DocRepository
PAP
SetupConf
JointConf
StartConf
StopConf
RemoveConf
UploadDoc
ViewDoc
DownloadDoc
DeleteDoc
Table 7 Biosecurity Incident Response Use Case - Component Design
October 27, 2014
29
Deliverable D1.4.1
4.2 eHealth/AAL Use Cases Analysis
In the following sections an analysis of the functional and non-functional security requirements of
the AU2EU eHealth/ AAL use cases (described in deliverable D1.1.1 [4]) is presented. The objective
of this analysis is to show how the security requirements map to the general building blocks of the
reference architectures for eAuthentication and eAuthorisation described above, and to indicate
what kind of general main functionalities the reference framework would have to provide in order to
fulfil these requirements.
Furthermore, this analysis gives evidence on additional functionalities and points out where new
building blocks are needed in order to enable a deployment of the collaborative eHealth/AAL use
cases with the required level of security, privacy and trust.
The analysis is based on the functional and non-functional security requirements of the eHealth/AAL
use cases as described in deliverable D1.2.1 [5]. The focus is on the essential security requirements
that equally or at least similarly apply to both use cases, i.e. the Efficient Care Coordination use case
(ECC) and the Customer Registration use case (CR).
The home-emergency call centre of the German Red Cross (DRK) in Heidelberg provides 24/7 homeemergency care and ambient assisted living services to home-based customers/patients. The DRK
collaborates with different regional home- and health-care service providers.
Depending on the customer requirements, the operator of the DRK home-emergency centre selects
an appropriate home/health-care service provider, and requests this service provider to provide
immediate care to the patient.
The collaborating home/health-care service provider then dispatches an actual care giver (e.g. a
doctor, a nurse, a driver of an ambulance) and sends this care giver to the patient’s home. The care
giver needs information about the patient, e.g. the patient’s health/home care record.
In the Efficient Care Coordination use case the care giver, requests access to the patient’s data on a
mobile device. The DRK home emergency call centre administrates the patient’s data and provides
the care giver temporary access (limited time-wise and content-wise) to its patient’s data for the
duration of the care actions.
In the Customer Registration use case a field representative of the DRK home emergency call centre
requests remote access to the customer data base from his mobile device in order to register service
relevant customer data into the data base (for a detailed description of these use cases refer to [4]).
4.2.1
Functional Security Requirements Mapping
4.2.1.1 eAuthentication Requirements
No. Requirement
Building Block
Functionality
1
Authentication
Identity
Provider;
Attribute
Provider
Authentication
with Identity
federation
Trusted
Execution
Environment
Smart Card
Authentication
2
eHealth/
AAL
Use Cases
The Care Givers/Field Represent- ECC & CR
atives needs to be authenticated,
in order to guarantee that access
is given only to data relevant to a
given event. The authentication
will be based on a unique Smartcard and user credentials (PIN
code).
The Smart Card acts as trusted ECC & CR
hardware anchor, thus it needs to
be guaranteed (certified) that the
October 27, 2014
30
3
4
5
used Smart Cards satisfy the security requirements (e.g., private
keys of the Smart Card never
leave the device, secure storage
and other).
Each Smart Card is unique and ECC & CR
cannot be cloned, copied and
other Smart Cards cannot impersonate it.
Only the desired Care Giver (e.g., ECC & CR
the doctor that is sent to the
patient) is in possession of the
Smart Card and PIN.
The Care Coordinator server (i.e., ECC & CR
the server that is providing the
customer data) needs to be authenticated to the Care Giver’s
mobile device, so that it can be
guaranteed that only valid and
true information is transmitted.
Deliverable D1.4.1
(new)
Key
Management
System
Trusted
Execution
Environment
(new)
Authorisation
(PEP)
Audit Logging
(Remote
Attestation)
Smart Card
Authentication
Authentication
with Identity
Federation
Authentication
with Identity
Federation
Authorisation
(PEP)
Table 8 eHealth/AAL Use Cases - eAuthentication Requirements Mapping
4.2.1.2 eAuthorisation Requirements
No. Requirement
Building Block
Functionality
6
eHealth/
AAL
Use Cases
Only the Care Giver that is sent to ECC & CR
the patient (in addition to the
emergency-handling personnel at
the Care Coordinator/AAL Server
site) is allowed to access the patient’s relevant data. No additional communication entity is
authorised to access the data.
Authentication
Identity
Provider;
Attribute
Provider
Access to data is only allowed in a ECC & CR
specific timeframe. After handling an emergency (home emergency call event), all patient data
is sent back to the server and
deleted from the Care Giver’s
mobile device. If not deleted
from the mobile device, the data
is guaranteed to be inaccessible
(e.g., deleting the decryptionkey).
The system provides fine-grained ECC & CR
Trusted
Execution
Environment
(new)
Authentication
with Identity
Federation;
Certified
Attribute
Provider;
Access Control
based on
Personal
Attributes
Access Control
based on
Environmental
Attributes
Authorisation
(PEP)
Protection of
User Attributes
7
8
October 27, 2014
Life-Cycle
Management
Authorisation
Predefined
31
Deliverable D1.4.1
authorisation-policies, based on
the type and privacy-level of patient data and Care Giver.
(PDP)
9
The system provides the possibil- ECC & CR
ity to revoke access to data.
Authorisation
(PDP, PAP)
10
Authorisation policies have to be ECC & CR
bound to each specific Care Giver
(e.g., a doctor might have access
to patient medication, other
people might not).
Trusted
Execution
Environment
(new)
Level of Privacy
User Consent
about Personal
Attributes
Propagation
Access Control
based on
Environmental
Attributes
Access Control
based on
Personal
Attributes
Authorisation
(PDP)
Table 9 eHealth/AAL Use Cases - eAuthorisation Requirements Mapping
4.2.1.3 Identities, Attributes and Credentials
No. Requirement
eHealth/
AAL
Use Cases
The Care Giver’s identity has to ECC & CR
be stored in a Smart Card (i.e.,
credentials that uniquely identify
the Care Giver to the system),
and the card is not transferable.
Building Block
Functionality
11
Identity
Provider
Attribute
Provider
Smart Card
Authentication
Trusted
Execution
Environment
(new)
12
The Smart Card of the Care Giver ECC & CR
can only be accessed with a given
PIN number, only known by the
Care Giver. Credentials are equivalent to the PIN number. Additional passwords can be added
optionally.
Trusted
Execution
Environment
(new)
Authentication
Certified
Attribute
Providers
Access Control
based on
Personal
Attributes
Smart Card
Authentication
Certified
Attribute
Providers
Table 10 eHealth/AAL Use Cases - Mapping of Identities, Attributes and Credentials
October 27, 2014
32
Deliverable D1.4.1
4.2.1.4 Security of Data Transmission, Storage and Processing
No. Requirement
Building Block
Functionality
13
eHealth/
AAL
Use Cases
The data has to be transferred ECC & CR
using secure communication
channels, so that no potentially
malicious third party can get access to Patient’s data.
Life-Cycle
Management
The system must guarantee the ECC & CR
integrity of Patient data transferred to the Care Giver’s mobile
device.
Trusted
Execution
Environment
(new)
Protection of
User Attributes
Access Control
based on
Environmental
Attributes
Protection of
User Attributes
14
15
16
17
Authenticity of patient data must ECC & CR
be guaranteed.
Data stored on the Care Giver’s ECC & CR
mobile device has to be stored
securely (by using cryptographic
protocols). I.e., all data needs to
be encrypted automatically.
After handling the emergency ECC & CR
event and reporting the results,
Patient data has to be deleted
from the Care Giver’s mobile
device.
Audit Logging
Authentication
Trusted
Execution
Environment
(new)
Trusted
Execution
Environment
(new)
Life-Cycle
Management
Life-Cycle
Management
Protection of
User Attributes
Protection of
User Attributes
Protection of
User Attributes
Table 11 eHealth/AAL Use Cases - Security of Data Transmission, Storage and Processing
4.2.1.5 Security of Mobile Device
No. Requirement
Building Block
Functionality
18
eHealth/
AAL
Use Cases
The Care Giver’s mobile device is ECC & CR
able to perform security tasks
efficiently (encryption, decryption, signing, hashing, and other).
Trusted
Execution
Environment
(new)
Access Control
based on
Environmental
Attributes
19
The Smart Card is considered to ECC & CR
Audit Logging
Trusted
Certified
October 27, 2014
33
be secure and tamper resistant.
20
The Smart Card is capable to per- ECC & CR
form computations independently and is considered to be fully
trusted.
Deliverable D1.4.1
Execution
Environment
(new)
Trusted
Execution
Environment
(new)
Attribute
Providers
Certified
Attribute
Providers
Table 12 eHealth/AAL Use Cases - Security of Mobile Device
4.2.1.6 General Requirements
No. Requirement
Building Block
Functionality
21
Audit Logging
Protection of
User Attributes
22
eHealth/
AAL
Use Cases
The System provides a reliable ECC & CR
auditing service (logging), so that
each access to patient data can
be traced and reproduced afterwards.
The Smart Card can be a contact ECC & CR
or contactless device.
Trusted
Execution
Environment
(new)
Trusted
Execution
Environment
(new)
Access Control
Based on
Environmental
Attributes
Table 13 eHealth/AAL Use Cases - General Requirements Mapping
4.2.2
Non-Functional Requirements
No. Requirement
Building Block
1
Audit Logging
2
3
4
eHealth/
AAL
Use Cases
The Care Givers must be aware of ECC & CR
privacy issues and handle the
Patient data with proper care.
They need to be educated in data
handling and relevant laws.
It is assumed that the Care Giver ECC & CR
never reveals his Smart Card PIN
code to anyone.
The Smart Card and mobile de- ECC & CR
vice should be stored away from
each other to prevent loss of
both at the same time.
It is assumed that the Care Giver ECC & CR
reports a lost or stolen Smart
Card immediately, so that the
Smart Card can be declared invalid immediately.
October 27, 2014
Functionality
Key
Management
System
Audit Logging
Audit Logging
34
5
All processing of data or applica- ECC & CR
tions should be done on a legal
basis.
Deliverable D1.4.1
Audit Logging
Table 14 eHealth/AAL Use Cases - Mapping of Non-Functional Requirements
4.2.3
Consolidation with Existing Reference Architectures
From the analysis of the security requirements and their mapping to building blocks of the existing
reference architectures above (refer to sections 4.2.1 and 4.2.2) we have identified an additional
building block that is required for establishing trust and securing the access to confidential and sensitive data in dynamic, cross-domain, collaborative home/health-care service scenarios. The new
building block is specific to the secure deployment of cloud-services in the mobile services sector.
In both of the eHealth/AAL Pilot use cases, i.e. the Efficient Care Coordination and the Customer
Registration use case, collaborating health/home-care service providers deal with remote access to
highly sensitive information (e.g. home-based patient’s health/care records or daily activity patterns)
from their mobile devices (i.e. tablet computers, smart-phones).
The Trusted Execution Environment (TEE) is a new building block to the eAuthentication and eAuthorisation reference architecture: it enables the protected execution of authorised trusted applications, enforces access rights, integrity and confidentiality of the data on the mobile device. The
Trusted Execution Environment will provide end-to-end security; it ensures that mobile care givers
can access confidential and sensitive data in a safe and trusted environment.
The design, integration and deployment of building blocks and functionalities necessary for the
eHealth/AAL Pilot use cases will be performed as part of the integrated AU2EU eAuthentication and
eAuthorisation platform development within WP2 and WP3.
4.3 Translational Research Use Case Analysis
This section analyses the Translational Research (Movember) use case as described in D1.1.1 [4] and
D1.2.1 [5]. It presents the general main requirements and their mapping to the reference architecture building blocks (Table 2) and identifies the new building blocks required for this collaborative
use case.
The Movember Global Action Plan 3 on active surveillance of prostate cancer aims to construct a
sustainable worldwide database for clinical, marker-related, and imaging data for scientific analyses
and improvement of clinical guidelines.
Given that the Movember project must deal with very sensitive data, accessed from different organisations (Research Institutes and University Medical Centres) and by different users (biostatisticians,
technicians or radiologists) in a distributed system, it is of paramount importance to ensure proper
user authentication and authorisation, data protection, consent management and enforcement and
information trustworthiness (reliability).
4.3.1
Functional Requirements
4.3.1.1 Authentication
1. Federation of identities: The Translational Research (Movember) users MUST be able to login into the Translational Research (Movember) system using the credentials from their organisation.
October 27, 2014
35
Deliverable D1.4.1
4.3.1.2 Authorisation
2. Demilitarised Zone (DMZ):
a. The DMZ MUST be divided in landing zones, each of which being assigned to an organisation uploading anonymised data.
b. An access control policy MUST be present at the level of the DMZ. (multiple actors
can interact with the DMZ)
i. The research institutions MUST be able to write data only in their DMZ partitions.
ii. The research institutions MUST be forbidden to read data from DMZ, in order for disclosure of incorrectly anonymised data to be avoided.
iii. The Quality Checker MUST be forbidden to write data in the DMZ.
iv. The access control policy of the DMZ MUST forbid the organisations to have
access to any other part of the DMZ, except their DMZ landing zone.
3. Data sensitivity: The granularity of the access control MUST be at study level.
4. Members from one organisation MAY NOT have the same access privileges to the “Globally
accessible shared translation research database”.
5. Access to the “Globally accessible shared translation research database” MUST be limited to
the people who have statistical analysis knowledge.
4.3.1.3 Anonymisation
6. A component which automatically checks the correctness of the anonymisation SHOULD be
provided. (We name this component Quality Checker)
a. The Quality Checker MUST reject the incorrectly anonymised data.
b. The Quality Checker MUST communicate any incorrectly anonymisation of the data
to the research institute owner of this data.
4.3.2
7. All the system’s security solutions MUST be a balance between the best solution and the solution that affects system’s performance the least.
8. All the system’s studies MUST comply with the Good Clinical Practice (GCP) requirements.
9. The organisations MUST have the patients’ consent in order to use their data in translation
research.
10. The DMZ part of the data upload from the organisations (Research Institutes and University
Medical Centres) to the “Globally accessible shared translational research data” MUST affect
the least the total duration of the data upload (performance requirement).
11. The DMZ MUST respect all data protection regulations and laws from all 5 Movember regions (Australasia, Europe, UK, Canada, and USA).
4.3.3
Translational Research Use Case Requirements Mapping
Requirement Building Block
Number
1
Identity Provider, Attribute Provider
2
DMZ (Demilitarised Zone, new)
October 27, 2014
36
3
4
5
6
7
8
9
10
11
Deliverable D1.4.1
Authorisation (Policies granularity)
Authorisation (PIP, Attribute Provider)
Anonymisation Quality Checker (new)
All Building Blocks (efficiency)
All Building Blocks (Good Clinical Practice compliance)
Authorisation (PAP, Policies)
All Building Blocks (laws compliance)
Table 15 Translational Research Use Case - Requirements Mapping
New architectural building blocks for the Translational Research use case are the Demilitarised Zone
and the Anonymisation Quality Checker. Furthermore mechanisms which are able to provide flexibility for the granularity of the access control have to be in place. These mechanisms should support
study level access control. In the Translational Research use case the data that has to be protected is
grouped in research studies. These research studies are scoped towards certain goals.
4.4 PACS Use Case Analysis
This section analyses the Picture Archiving and Communication System use case (PACS use case), as
described in the AU2EU deliverables D1.1.1 [4] and D1.2.1 [5]. It presents the general main requirements and functionalities of this collaborative use case that will have to be fulfilled by the eAuthentication and eAuthorisation reference architecture.
PACS (Picture Archiving and Communication System) is a medical imaging technology that provides
storage of, and convenient access to, images from multiple modalities.
Given that PACS must store and transmit sensitive data, accessed from different organisations (hospitals) and by different users in a distributed system, it is of paramount importance to ensure proper
user authentication and authorisation. In order to comply with legislation, patient permissions to
access data must be properly regulated (patient digital consent management).
This section describes the functional as well as non-functional requirements of the collaborative
PACS use case and maps them to the corresponding building blocks of the eAuthentication and eAuthorisation reference architectures (Table 2) and identifies the need for new building blocks.
4.4.1
1. Federation of Identities: The Collaborative PACS users MUST be able to login in the Collaborative PACS system using the credentials from their organisation.
2. Data Sensitivity:
a. The system MUST support access control policies for data with different sensitivity
levels.
b. The access control policy SHOULD support various levels of granularity aligned with
data granularity (e.g. up to very fine grained such as database cells).
3. Geolocation: The geographical localisation of the user who wants to access the data MUST
be used in authorisation enforcement.
October 27, 2014
37
Deliverable D1.4.1
4. The patient’s consent MUST be collected before any patient data lands in the PACS database.
5. Patient’s consent must be enforced every time an attempt is made to access patient data.
6. The policies in different domains must be synchronised.
7. Modifications of the policies must be reflected immediately (5 seconds) in all the hospital
brokers.
8. Not all users belonging to the same hospital will necessarily have the same access privileges
to the patients’ data.
4.4.2
9. All the system’s security solutions MUST be balanced between the best solution and the solution that affects system performance the least.
10. The collaborative scenario SHOULD not degrade the PACS system’s performance by more
than 10%.
4.4.3
PACS Use Case Requirements Mapping
Requirement
Number
1
2
3
4
5
6
7
8
9
10
Building Block
Identity Provider, Attribute Provider
Authorisation (support for data sensitivity (new))
Authorisation (PIP, geolocation (new)), Collaboration Administration (Attributes)
Collaboration Administration (policies synchronisation)
Authorisation (PDP, Policies)
Authorisation (Policies, Attribute Provider)
Table 16 PACS Use Case - Requirements Mapping
The Geolocation building block is a new architectural building block related to the PACS use case.
This building block should provide the location of the user based on IP and/or leveraging other
mechanisms. The output of this building block should be used as the location attribute in decisions
regarding user authorisation. The Geolocation building block might be connected with the Policy
Information Point (PIP).
Support for data sensitivity is a requirement which might create new internal building blocks in the
more broaden Authorisation building block. The sensitivity of the data must be used in or next to
Policy Enforcement Point (PEP) and/or Policy Decision Point (PDP) building blocks. The way the sensitivity of the data is expressed/stored might create new internal building blocks like sensitivity storages.
October 27, 2014
38
Deliverable D1.4.1
4.5 DNA Data Management in Clinical Trials Use Case Analysis
In this section the DNA Data Management in Clinical Trials use case (DNA use case) described in
D1.1.1 [4] and D1.2.1 [5] will be analysed with regards to functional requirements and their mapping
to the respective building blocks of the reference architectures (Table 2). Furthermore a new building block essential for the DNA Data Management in Clinical Trials will be introduced.
This use case deals with the management of distributed DNA archiving systems for the realisation of
clinical trials by collaborating parties (i.e. sponsors, expert clinical investigators, healthcare providers, researchers) in order to test the safety and efficacy of a treatment, based on genetic information and biomarkers of patients. A detailed description of this use case can be found in [4].
4.5.1
1. Federation of identities: The users of the organisations participating in the clinical trial MUST
be able to login in the DNA management system by using the credentials from their organisation.
2. DNA Repository:
a. An access control policy MUST be present for each clinical trial:
i.
An investigator MUST only be able to query DNA sequences for the purpose
specified in the clinical trial.
ii.
An investigator MUST not be able to write any data to the DNA repository.
iii.
An investigator MUST not be able to read any data from the DNA repository.
iv.
The inclusion criteria MUST be checked on encoded DNA sequences.
v.
The DNA management system MUST only return to the investigator the
pseudo-IDs of the patients satisfying the inclusion criteria and the corresponding healthcare provider.
vi.
The sequencing company MUST be able to write encoded DNA data in the
DNA repository.
vii.
The sequencing company MUST write DNA data only in the fields associated
with the DNA pseudo-ID.
viii.
The sequencing company MUST not be able to read any data from the DNA
repository.
ix.
A researcher MUST be able to perform post-clinical trial analysis on the encoded DNA data.
x.
A researcher MUST only be able to perform post-clinical trial analysis on the
DNA data of the patients participating in the clinical trial.
xi.
A researcher SHOULD only be able to analyse the DNA data for the purpose
specified in the clinical trial.
xii.
A researcher MUST not be able to write any data to the DNA repository.
xiii.
A researcher MUST not be able to read any data from the DNA repository.
3. Different organisations participating in the clinical trials SHOULD have different access privileges.
4. Different members from an organisation participating in a clinical trial SHOULD not have the
same access privileges to the data in the DNA management system.
5. Post-clinical analysis on DNA data MUST only be performed by qualified researchers.
4.5.1.3 Storage
6. DNA sequences MUST be stored in an encoded way.
October 27, 2014
39
Deliverable D1.4.1
7. DNA data records SHOULD be annotated with pseudo-IDs of patients.
8. DNA data records SHOULD contain a reference to the healthcare provider that has treatment relationships with the corresponding patient.
4.5.2 Non-Functional Requirements
9. The organisations MUST have the patients’ consent in order to use their data in a clinical trial.
10. Reliable analysis of clinical data SHOULD be feasible to perform on the encoded DNA sequences (usability requirement).
4.5.3
DNA Use Case Requirements Mapping
Requirement Building Block
Number
DNA 1
Authentication (Attribute Provider, Identity Provider)
DNA 2
Authorisation (PDP, Policies),
DNA Repository (new)
DNA 3
DNA 4
DNA 5
DNA 6
DNA 7
DNA 8
DNA 9
All Building Blocks (patients consent)
DNA 10
Table 17 DNA Data Management in Clinical Trials Use Case - Requirements Mapping
A new architectural building block for the DNA use case is the DNA Repository. It should be able to
store DNA data in an encoded way, restrict read and write access depending on the provided identity. Furthermore, it should protect patients’ privacy by using pseudo-IDs to annotate DNA data. Finally, it allows reliable analysis of clinical data on encoded DNA sequences.
4.6 Legal and Business Requirements Analysis
A profound legal and business analysis of the joint eAuthentication and eAuthorisation reference
architecture with respect to its applicability to the AU2EU use cases is entirely within the scope of
D1.3.1 [6].
Nevertheless, there are interdependencies. Namely, the design of the consolidated joint reference
architecture is partially influenced by requirements from the legal and business analyses.
From the analysis of the AU2EU use cases presented above, already some relevant legal requirements (e.g. compliance with data protection legislation) have been categorised which not only influence the design of the AU2EU Reference Architecture but also impact potential future business cases, markets and revenue streams.
In the following section (section 4.6.1) we will present a selection of general requirements and deployment aspects mentioned by T1.3 (D1.3.1 [6]) being mutually relevant for consideration in the
design as well as for the future deployment of the AU2EU reference architecture.
October 27, 2014
40
Deliverable D1.4.1
Some of these aspects discussed below will also be addressed in the sections describing the functionality, design and components of the high-level AU2EU reference architecture.
Other relevant aspects in a business and legal context in particular the T1.3 legal analysis of the eAuthentication and eAuthorisation architecture deployment to the eHealth/AAL use cases will be outlined in section 8.2 as part of the challenges and gap analysis.
4.6.1
General Design and Deployment Aspects
Authenticate Data:
Data in the database needs to be authenticated. For example, data can be confirmed by checking the
data with validated external sources (government database, insurance database, etc.). Data can also
be authenticated based on proof, or based on the analysis of attributes.
Authenticate Users:
The ePlatform needs to provide a stringent authentication process. Therefore, two-factor authentication should be used based on the following three, commonly used independent authentication
factors:
 Something only the user knows (e.g., password, PIN, pattern);
 Something only the user has (e.g., ATM card, smart card, mobile phone); and
 Something only the user is (e.g., biometric characteristic, such as a fingerprint).
On the short term smart cards (NFC cards) can be provided. On the long term mobile phones can be
used as an authentication factor next to a password.
Interface with other cloud services:
The ePlatform needs to be able to interface with a wide variety of cloud services and databases.
Flexible way to authorise people:
Authorising people (internal and external) can be done in a flexible way. This means that the scope
of the data (visible fields, history, …) and the permissions (view, edit, none) can be configured in a
flexible way. For example, this could be role-based with the possibility to include exceptions. For the
administrator of the ePlatform it also needs to be clear who is authorised to see what. This could be
set-up from a user perspective or from a data perspective.

Control access to anonymised / non-anonymised data set:
The ePlatform can be linked to a data set that is anonymised by an anonymisation engine.
The development and piloting of this engine is out of scope for this project. However, it is
possible to link the ePlatform to different data sets (anonymised / non-anonymised) where
the authorisation levels for people may differ over different data sets. For example, a data
analyst has full access to the anonymised data set, but no or limited access to the original
data set.

Configuration possibilities
In order to match unique business needs, the ePlatform should be easily configurable (enable/disable options and features). Different configurations can also be used to market different “editions” with their own price tags.

Determine authorisation level in a smart way
In some cases authorisation levels can be role-based, but in some cases the level of authorisation may also depend on the situation. For example, does a doctor need to see your com-
October 27, 2014
41
Deliverable D1.4.1
plete health record when you go for a regular check-up? It needs to be investigated how access to data is currently managed.
October 27, 2014
42
Deliverable D1.4.1
5 Functionality
The reference architecture is driven by the AU2EU use cases, pilots, and standard use cases. The
following table summarises the different functionalities required by the different use cases based on
the requirements expressed in the D.1.2.1 document of AU2EU [5] (just eAuthentication and eAuthorisation functionalities are described).
AU2EU Use Cases
DNA Data
eHealth/
Translational Biosecurity
PACS Management
AAL
Research
Incident
in Clinical
Customer
(Movember) Response
Trials
Registration
Functionalities
eHealth/
AAL
Efficient Care
Coordination
eAuthentication
authentication with
identity federation
*
*
*
*
smart card
authentication
*
*
device authentication
*
single sign-on
*
*
*
eAuthorisation
certified attribute
providers functionality
*
*
*
*
*
*
access control based on
personal attributes
*
*
*
*
*
*
access control based on
environmental attributes
*
*
*
*
*
*
user consent about
personal attributes
visibility/propagation
*
*
*
*
*
*
*
protection of user
attributes (encryption)
*
*
"break-the-glass"
mechanism
*
*
predefined level
of privacy
policy synchronisation
between domains
*
no attribute propagation
without anonymisation
*
Table 18 Functionalities required by the AU2EU Use Cases
October 27, 2014
43
Deliverable D1.4.1
Regarding the table above, the following main functionalities (around eAuthentication and eAuthorisation) must be taken into account by the reference architecture described later in this document.
5.1 eAuthentication
Around the eAuthentication functionality, the following key requirements have emerged:
5.1.1 Authentication with Identity Federation
In all the use cases, authentication of the user is required in order to access a service. In many cases,
this authentication is realised using an identity provider or issuer that is in charge of vouching for a
user's attributes. The user then can use those attributes to authenticate to relying parties. The authentication to a relying party can be done either by the identity provider issuing a token or credential to the user which can then be used at the user's discretion to authenticate attribute contained
therein to relying parties or by the identity provider generating an authentication proof which represents the authentication of attributes to a relying party. In a multi-organisational infrastructure, organisations and users need to be able to interoperate in order to understand each other’s vocabularies used for expressing policies, credentials, or identity statements. The authentication based on
attribute information from identity providers under user control forms the main part of the eAuthentication infrastructure of AU2EU.
The identity provider is responsible for vouching for attribute information about the user which may
be personal data. These attributes may be validated by the identity provider by any suitable means
and may differ between identity providers.
5.1.2 Authentication with Single Sign-On Functionality
The user can use Single Sign-On (SSO) functionality as a special kind of (legacy) technology in order
to facilitate authentication to protected services. After the user has authenticated to its organisation, the user can access to some services provided by its organisation or by another without a new
authentication phase.
5.1.3 Authentication Methods
Following the requirements, different kind of authentication methods supported by the user for
authenticating to entities such as an identity provider or a user identity agent must be taken into
account. The most-used one is the login with username and password, however, regarding the different use cases, other methods must be take into account, as for example:


Smart Card Authentication
The user can use a smart card in order to realise the authentication with her device, her user
identity agent or identity provider.
Device Authentication
In some particular situations, the authentication of a user can be realised, as additional authentication factor, through the authentication of the device used by this user. Based on the
characteristics of this device, the authentication mechanism must validate the device specification and then the user credentials in order to grant the authentication.
5.2 eAuthorisation
In the domain of the eAuthorisation functionalities, we can extract the following requirements:
5.2.1 Authorisation based on User Attributes
In the AU2EU context, the accessed services are controlled by the eAuthentication framework in
charge of granting access based on attributes (user or environment attributes). Regarding the inforOctober 27, 2014
44
Deliverable D1.4.1
mation provided, access to the service is granted or denied. Different approaches already exist,
among them Attribute-Based Access (ABAC) control aims to replace the previous approaches like
Identity-Based Access Control (IBAC) and Role-Based Access Control (RBAC). While RBAC relies on
the current roles of a user to grant or deny access to a resource, ABAC provides a more flexible
mechanism based on the attributes of the user. In the RBAC model, a user is pre-assigned a set of
roles, with ABAC permissions can be acquired dynamically by virtue of the user’s attributes.
Attributes used in an ABAC model can be provided not only by the user but also obtained from the
environment:
 Subject (user, application and process) that defines the characteristics of the subject (e.g.
role, site membership, localisation, job title, authentication method…),
 Resource (The resource that the user wants to achieve),
 Environment that describes the operational, technical or situational environment or the
context in which the information access has occurred (date/time, network classification, current threat level, state of a system…).
Based on the ABAC model, policies describe when authorisation to access a service should or should
not be granted to access a resource. Often a combination of policies must be evaluated for this.
Regarding the user attributes themselves, the eAuthentication framework must grant the user attributes provided during the service access. Trust between the eAuthentication framework in charge
to evaluate the user information and the eAuthentication framework in charge to provide user information is fundamental. Specific mechanisms must be put in place in order to guarantee this trust
between the different parties and the security of the exchanged data.
5.2.2 Privacy of User Attributes
The privacy of user attributes is a key requirement, and guaranteeing it presents a big challenge for
access control based on these same user attributes.
The user needs and wants to control the visibility and the usage of his personal information (especially, in a multi-organisational context) in order to control their privacy. However, the user must
provide information to the service about itself in order to validate the access to this service. The
central feature of the AU2EU reference architecture is to require just the least amount of information about the user or minimal proof that user attributes have specific characteristics (e.g., the
age of a user is over 18 years) in order to grant the access to a service. Combining possibilities, the
user should be able to select which kind of information they want to reveal regarding all their personal information and thus protect their privacy.
5.2.3 Multi-Organisational Context
Each organisation manages its own set of policies in order to control access to services inside this
organisation. These policies are based on a data model specific to the organisation. In order to be
able to validate a request coming from external users, the organisation must understand the user
attributes and map them into its internal data model. Similarly, a mapping of attributes must be
performed between organisations in order to enable sharing of services with external users while
controlling access to those services.
Regarding the challenges associated with such mapping, new functionalities must be included in the
reference architecture such as:

The ability for each organisation to share its internal data model with other organisations in
order to share attribute concepts.
October 27, 2014
45

Deliverable D1.4.1
The ability to translate external attributes coming from another organisation in its internal
data model.
This translation must be used
o
o
when the eAuthorisation framework requests personal information from the user.
The user must translate the required attributes in order to understand which personal attributes must be revealed for gaining access to the requested service;
when the eAuthorisation framework has received information from the user. The
eAuthorisation framework must translate the attributes coming from the user into
its known data model in order to be able to grant or deny the access using its own
access control policies.
5.2.4 Break-the-Glass
In some cases, it is important to be able to override access control in a controlled manner. A usual
example is when a patient's health is at risk. But the critical issue here is who determines this risk.
In a Break-the-Glass scenario an operation would only be authorised if it is justified to be a legitimate imperative need; furthermore additional auditing may need to be enabled to record the details
of the break the glass operation itself.
October 27, 2014
46
Deliverable D1.4.1
6 Architecture
In this section we present the reference architecture of the AU2EU project, motivate the underlying
design decisions, and relate it to other architectures.
6.1 Towards AU2EU
Let us begin our discussion of the AU2EU architecture with an example, namely, a user who intends
to access a resource at a relying party. This simple scenario, which is at the core of AU2EU and many
practical real-world use cases, is illustrated in Figure 8. As mentioned in the introduction, using unauthenticated user-claimed attributes for making an authorisation decision or using password-based
authentication to an account comprising the user’s attributes often is not a good solution from both
a security and a privacy point of view. The aim of AU2EU is to provide a solution to the problem of
users authenticating in a privacy-preserving manner.
authenticate
User
Service
Provider
Figure 8 Problem of Authenticating in Today’s Communication Networks
Realising such scenario requires not only privacy-enhancing authentication but also an authorisation
that maintain those privacy properties. In this document, we elaborate on these two aspects and on
how they play together. We will also look at additional aspects related to either of them or both.
6.2 Section Outline
First, we present the authentication architecture in Section 6.3, and then in Section 6.4 the architecture for authorisation. In Section 6.5, we show how the AU2EU architecture addresses interoperability between parties in open systems such as entrusted unions or the Internet. A brief discussion on
the assurance of authentication follows in Section 6.6. We then discuss the option of a cloud-based
deployment of the platform in Section 6.7. In Section 6.8, we look at how the AU2EU architecture
can be integrated with legacy technology and deployments. We briefly discuss how existing legacy
infrastructures are leveraged for AU2EU deployments in Section 6.10, and present a high-level discussion of trust management in AU2EU in Section 6.11. We conclude this section on the reference
architecture in Section 6.12.
6.3 Authentication
We begin our discussion with the authentication platform and present its architecture in a generic
way in this subsection.
6.3.1 Third-Party-Certified User Attributes
To illustrate the short-comings of the above setting, we introduce a third party, the so-called issuer,
whose job (role) it is to vouch for the attributes of a user towards relying parties. The issuer is responsible for verifying the attributes it vouches for in a suitable manner before vouching for them
towards a relying party. The relying party is typically a service provider from whom the user intends
to consume a service, and it relies on the certification of attribute information through the issuer –
hence the name of its role. The technical approach for implementing the process of authenticating
issuer-certified attributes towards relying parties is crucial for achieving a privacy-friendly system.
October 27, 2014
47
Deliverable D1.4.1
A system may have an arbitrary number of issuers offering the service of certifying attributes of users. The relying party trusts that the attributes of the issuer it vouches have been properly validated.
Note that in order to be able to use the attribute information for access control and business process
purposes, a relying party must know the strength of validation of the attributes of an issuer it trusts.
We also refer to the issuer as identity provider, attribute provider, or certifier.
certify attributes
Issuer
authenticate
User
Relying
Party
Figure 9 Solution for Authentication in Today’s Communication Networks
Many existing solutions offering issuer-based authentication do so in a privacy-unfriendly way because either the issuers can establish substantial profiles of users’ authentications or the relying
parties learn excessive information, depending on which legacy technology is used. One of the key
purposes of the reference architecture is to describe how a user can authenticate attribute assertions to a relying party in a privacy-preserving manner based on attributes certified by one or more
parties acting as issuers. The overall AU2EU architecture is defined to facilitate such authentications
in a privacy-preserving and open way as well as to integrate with existing legacy technologies. We
will refer to the privacy-preserving authentication offered by the architecture as AU2EU authentication, credential-based authentication or privacy-ABC-based authentication (because of the technology of privacy-preserving attribute credentials, or privacy-ABCs, being used).
Of course, in the architecture also other kinds of authentication without any privacy properties will
be used between certain pairs of parties, e.g., a user and their user agent, as a means to realise
AU2EU authentication. The openness of the architecture in terms of such other authentication technologies and its integration with legacy technology and deployments will be discussed later in this
section.
6.3.2 Plurality of Issuers Certifying User Attributes
For large-scale deployment in real-world scenarios, we envision for the AU2EU architecture, much
like TDL and ABC4Trust do, that a plurality of issuers is available and certifies user attributes. Not
only can different users choose from this large set of issuers, but also a single user will have multiple
issuers endorsing different attributes. This setting is natural in the sense that different organisations
hold different (sets of) user attributes in validated form and thus are able to certify them.
This setting is much more privacy friendly and realistic in real-world scenarios than assuming a single
issuer vouching for all attributes of a user. For example, the user’s bank will know about the user’s
creditworthiness; thus it is the proper party to act as issuer for attributes related to creditworthiness. For privacy reasons, it is better to have the bank act as issuer in that scenario because a thirdparty issuer would in addition learn the attribute information (creditworthiness). Effectively, this
approach reduces the information being learnt by a single issuer about the user, and thus further
substantially strengthens privacy of the user.
6.3.3 Parties and Roles
The parties involved in basic authentication interactions are users, relying parties, and issuers. In
more advanced federation scenarios using privacy-ABCs, additionally revocation authorities and
inspectors can be deployed. More precisely, all those roles can be assumed by different parties, but
also a single party can take on multiple roles. For example, an issuer can be the relying party when
receiving authenticated attributes from a user for establishing a new relationship, and then assume
the issuer role and certify those attributes.
October 27, 2014
48
Deliverable D1.4.1
6.3.3.1 User
The user is the party that intends to interact with other parties, specifically, with service providers
that act as relying party, and thereby have to authenticate attribute information so that the user
becomes authorised to access services of the service providers. The user often acts in the role of
requestor, that is, a party requesting a service and needing to authenticate in this capacity. Considering only the authentication context, the role of the user when authenticating is in general that of
an authenticator. In the context of claims-based architectures, this is often referred to also as claimant. However, the concept of claimant is more general than that of authenticator, as the latter is a
claimant confined to the context of authentication.
6.3.3.2 User Agent
The user agent provides functionality for executing authentication protocols with other parties on
behalf of the user as well as for rendering user interfaces towards the user or for providing data related to user interactions to external rendering components, e.g., a web browser. A user agent can
be run by a third party as a service to users or by users themselves either locally or as a cloud-based
service. Any of this is transparent to the other parties.
6.3.3.3 Relying Party
The relying party is the role of a party that receives third-party-certified authentications of attribute
statements about users (i.e., authenticators) and that based on these attributes, authorises access to
a service. A service in this context can be very generic – it can range from any web-based service
users may want to consume to the service of issuing credentials offered by issuers in the system.
Note that we denote a party as relying party only in the context of receiving authentications of issuer-certified attribute assertions. In the case of non-issuer-backed authentications, e.g., a user authenticates with a password to a party, the party is not a relying party, but has the more generic role
of authenticatee.
Also, a relying party may often be referred to as verifier, as it verifies claims made by the authenticator.
6.3.3.4 Issuer
A party in the role of issuer certifies attribute information of users. The certified attribute information can be used by users to authenticate attribute statements towards relying parties. Achieving
such authentications and using them for computing access control decisions are the key focus of this
project.
6.3.4 Identity Relationships
For leveraging issuer-certified attributes, a user and an issuer first need to establish a relationship, a
so-called identity relationship. Once this has been accomplished, the attributes, or partial information thereof, associated with this relationship can be authenticated to relying parties at the user’s
discretion. Figure 10 shows a schematic representation of identity relationships in the context of
issuer-based authentication.
A user and an issuer can establish an identity relationship at any point in time, and from then on, the
issuer vouches for certain user attributes as specified in the identity relationship. To establish an
identity relationship, the issuer must be able to obtain information on attributes of the user and
verify them accordingly. Identity relationships may or may not have a pre-determined lifetime depending on the requirements for that specific relationship. An identity relationship captures the
abstract notion of an issuer vouching for attributes of a user independent of technology. This notion
is general, and can capture any currently existing technology for issuer-based authentication, regardless of whether it is traditional or privacy-enhancing technology.
October 27, 2014
49
Deliverable D1.4.1
establish identity
relationship
authenticate
Issuer
User
Relying
Party
issue token
Figure 10 Identity Relationships
6.3.4.1 Establishing Identity Relationships
The aim of the AU2EU architecture is to adopt a flexible approach for establishing identity relationships, as is required for an open identity federation system. For example, in a physical presence registration scenario, users can use their passports when establishing an identity relationship with the
issuer. Alternatively, in order to vouch for attributes, the user uses the government-issued eID card
and reveals (a subset of) the attributes to the issuer with whom a new identity relationship is to be
established. This exemplifies the generic use of (legacy) authentication technologies within the
AU2EU architecture a building block of achieving the goal of privacy-preserving authentication. This
will be discussed later in this section. A user can also employ privacy-preserving AU2EU authentication to authenticate to the issuer that it is indeed a valid user in the system without revealing identifying information. The attributes of the identity relationship, e.g., permissions granted by the issuer,
can then be securely associated with this user without disclosing any identifying information about
the user to the issuer. The latter is particularly interesting in the case of attributes that are not related to the civil identity of the user, but can still be securely associated with the user. This example is
based on using AU2EU authentication towards the issuer to perform the binding of the attributes to
the user by means of privacy-ABC technology.
Another example for establishing an identity relationship is an organisation allowing its employees
to establish an identity relationship based on user attributes contained in the company’s LDAP. This
is an important example in terms of leveraging existing attribute infrastructures for bootstrapping
AU2EU.
Once the issuer has obtained the attributes it needs for the relationship in verified form, it can vouch
for them towards parties in the relying-party role. How this vouching for attributes is done and how
the identity relationship is established technically depends on the technical protocols used.
We next present the two paradigms of how an identity relationship can be realised practically.
6.3.4.1.1 Offline Issuer
One prominent way of establishing a relationship is that the issuer issues to the user a long-lived
multi-use digital credential certifying the attributes. The user can then use this credential containing
the authenticated attribute information without any further involvement of the issuer. This explains
the name of this setting, offline-issuer setting, because the issuer does not need to be online for and
involved in each authentication transaction. In Figure 11, the issuing of a credential is shown as the
optional step 0.B, which is done in the context of establishing an identity relationship and thus before a concrete authentication interaction.
6.3.4.1.2 Online Issuer
Another setting is that of online issuers. Here the establishment of the identity relationship means
that, at the request of the user, the issuer agrees to issue (short-lived) tokens certifying the user’s
attributes. In an authentication transaction, the user requests a token comprising all or a subset of
the attributes the issuer vouches for and uses this token to make an attribute assertion to a relying
party. How this is done in detail again depends on the technology. In naïve protocols, for example,
making the attribute assertion can be done by the user requesting an attribute token from the issuer
that contains exactly the information to be revealed to the relying party. The user then forwards this
October 27, 2014
50
Deliverable D1.4.1
token to the relying party. In a more advanced and privacy-preserving setting, the user obtains a
token certifying all attributes the issuer vouches for. Then, without involving the issuer, the user
transforms this token by means of a private key into a data-minimal issuer-certified attribute statement with a cryptographic proof revealing exactly the information requested by the relying party.
Finally, this attribute statement and proof are sent to the relying party.
6.3.4.2 Authentication Using Established Identity Relationships
The main functionality of the authentication platform of AU2EU is privacy-preserving authentication
of attribute statements of a user to relying parties. An authentication of this kind is based on attribute information certified by one or more issuers, that is, attributes comprised in corresponding identity relationships. We have already sketched above how authentication based on attributes of an
identity relationship can be done conceptually. Next, we will provide further details on the different
ways of authentication.
The process of leveraging that an issuer vouches for attributes of a user through an identity relationship is technically realised through the core authentication protocols of AU2EU for authenticating
attributes to relying parties. Therefore, we will now discuss the different authentication paradigms
mentioned above.
6.3.4.2.1 Offline Issuer
A very attractive option is that of the issuer issuing a long-lived token based on advanced cryptographic mechanisms as part of the process of establishing an identity relationship with a user and of
not being involved anymore, i.e., being offline, in the actual authentication transaction. Such a longlived token comprises all attributes of the identity relationship and, after having been issued, is held
by the user. In AU2EU, such tokens are privacy-ABCs such as Identity Mixer [ [7], [8], [9]] or U-Prove [
[10], [11]] credentials. In the case of Identity Mixer, a single credential, once obtained, can be used
an arbitrary number of times. In the case of U-Prove, the user obtains a set of credentials and can
use each credential only once. When or before the set of credentials is exhausted, the user has to
obtain fresh credentials, requiring the issuer to be available online from time to time.
6.3.4.2.1.1 Token Presentation
The user can make use of such tokens at their discretion for authenticating attribute statements
towards relying parties an arbitrary number of times for as long as the token(s) is (are) valid. Technically, using a token (credential) is realised by creating a cryptographic proof out of the user’s private
key and the token. The proof shows that an attribute statement that claims to be consistent with the
attributes certified by the token revealed to the relying party is indeed consistent with the attributes
in the token.
It is also possible to reveal only a subset of the attributes of the token together with such proof.
Also, the user can reveal partial information on an attribute, e.g., use the date of birth attribute to
prove that the user is of a certain minimum age. The cryptographic proof is unlinkable to the issuerprovided token and thus transactions are completely unlinkable. To summarise, with this approach
strong unlinkability and partial release properties for attributes can be realised.
6.3.4.2.2 Online Issuer
When a user and issuer have an identity relationship in which the issuer provides short-lived tokens
to the user at the user’s request, the issuer needs to be involved in each authentication transaction.
The user can request from the issuer that it issues a short-lived token and, upon receiving this token,
use it to authenticate to a relying party. There are two options to realise this, as will be explained
next. In Figure 11, an online request and the issuing of a token as part of an authentication interaction are shown as optional steps 3 and 4.
October 27, 2014
51
Deliverable D1.4.1
6.3.4.2.2.1 Token forwarding
In the case of a short-lived token based on traditional cryptographic mechanisms, such as RSA or
DSA signature schemes, the user requests a token from the relying party that comprises exactly the
attribute information the user intends to release, receives that token from the issuer, and forwards
it verbatim to the relying party, which verifies its integrity.
This approach is problematic in terms of its inherent privacy problems, namely, that the issuer can
build extensive profiles of the authentication transactions the user performs, including the identity
information revealed and the relying parties. From a security perspective, the issuer could perform
such transactions without involvement of the user, and thus frame the user. Also, the tokens are not
strongly bound to the user or the transactions controlled by the user. For those reasons, token forwarding, although supported in the architecture, is not encouraged as technology paradigm for
AU2EU.
6.3.4.2.2.2 Token Presentation
When using advanced cryptographic mechanisms of privacy-enhancing attribute credential protocols
[ [8], [11]], the short-lived token requested by the user can contain all attributes the issuer certifies
in the identity relationship. On receiving such token from the issuer, the user can create a cryptographic proof using the private key and provide this proof to the relying party. This proof shows that
the user holds such a token issued by the issuer certifying user’s attributes. The proof mechanisms
are similar to those of computing a presentation proof from long-lived tokens discussed above. That
is, an assertion (claim) consistent with the token can be proved authentic. The mechanisms AU2EU
intends to support for the online-issuer setting are U-Prove [ [10], [11]] and Identity Mixer [ [7], [8],
[9]]. We would like to point out that Identity Mixer is extremely suitable for the more general offline-issuer setting as explained above. Token presentation in the setting of online issuers can be
seen as special case of the setting with offline issuers. Token presentation as core part of an authentication transaction is shown as step 5 in Figure 11.
(0.A)
request identity relationship
(3) [optional]
request token
(1) access service
User
(agent)
Issuer
(4) [optional]
short-term token
Relying
party
(2) authN policy
(5) attribute statement
& proof token
(O.B) [optional]
long-term token
Figure 11 Authentication Message Flow
October 27, 2014
52
Deliverable D1.4.1
6.3.4.2.3 Discussion
A particular strength of advanced cryptographic mechanisms for presentation as discussed is that a
user can combine multiple tokens and the attribute information of those tokens in a single proof. All
attribute information revealed is bound to the same user by using their private key in generating the
proof. This is a very powerful feature of the AU2EU architecture as it allows many attribute sources
to be combined under full user control and without the issuers learning about the transactions performed. In terms of supported interaction paradigms of both offline and online issuers, the AU2EU
architecture combines the power of the ABC4Trust and TDL architectures in a single architecture.
The token presentation approach has a number of advantages over the token-forwarding approach
discussed. The main advantage is that in terms of privacy, the proof created is unlinkable to the token provided by the issuer, that is, the issuer can no longer profile the user. Also, as the token always comprises all attributes of the relationships, the issuer will not learn which attribute statement
is released and thus cannot glean further information about the transaction. Also, the security properties of this approach are stronger than those of the forwarding approach. The issuer alone cannot
perform illegitimate transactions for the user as it does not hold the user’s private key. Related to
this, the requirement that the private key be used for each proof ensures a strong binding of the
attributes to the user.
Note that for the offline issuer case there are no secure mechanisms based on token forwarding.
6.3.5 User Agent
The AU2EU architecture builds on the concept of user (identity) agents that perform actions related
to identity federation, that is, authentication, on behalf of the users. The agent thereby stores private key material of the user and executes cryptographic protocols. Also, this user agent provides
information for rendering the user interface for identity interactions and may render this information itself or have another component, e.g., a web browser, render it.
The agent of a user can be a locally hosted component under full control of the user, which is the
best situation in terms of user control and privacy. Another option is that of the user agent is hosted
as a cloud-based service. This is what AU2EU focus on, because such a system is easier to deploy
owing to a zero-footprint user-side deployment.
6.3.6 User Consent
From TDL and ABC4Trust, AU2EU has taken the basic principle that the user needs to give informed
consent for data releases to relying parties. This is a crucial property of user-centric systems and also
a requirement in the European Data Protection Directive 95/46/EC [12] and its member state implementations in national laws.
Informed consent in AU2EU can be given in two ways: It can be given explicitly through a user interface presented by the user’s identity agent, also referred to as user agent or user identity agent (UIA
or UA), e.g., as web-browser-based interface or an interface rendered in a local application or mobile app. It can also be given implicitly as required in special scenarios, for example, scenarios in
which users need to be registered upfront and know that some action, e.g., swiping an NFC card
over a reader, will trigger a specific authentication action with a specific relying party and the associated attribute-based authentication of the user to the relying party. One example of such a specific
is the AU2EU Biosecurity Incident Response scenario. Here users need to be able to authenticate to a
teleconference system and shared workspace conveniently, e.g., by swiping a hardware token, without any extra effort on their side in terms of additional user interaction or giving explicit consent.
6.3.7 Privacy
The main privacy challenges in traditional authentication systems with third-party issuers are that
the issuers learn the attribute statements that are being revealed to relying parties and also which
relying parties they are revealed to. Thus complete profiles can be established about the users. In a
October 27, 2014
53
Deliverable D1.4.1
system in which issuer-based authentication is used frequently, this is an unacceptable situation
because of the excessive profiling potential the relying parties have.
The AU2EU architecture enables untraceable authentication transactions of users, that is, not even
the issuers or collusions of issuers and relying parties will be able to learn which attribute statements are released to whom. Expressed differently, all authentication-related transactions executed
by a specific user are mutually unlinkable at the cryptographic level. However, clearly, two transactions are linkable if the revealed attribute information makes them linkable.
The underlying concept is data minimisation, that is, the data released in a transaction is reduced to
the required minimum. This reduction is adopted towards the relying party as well as towards other
parties involved in the transaction, e.g., the issuers.
6.3.8 Security
AU2EU features not only privacy-preserving, but also secure authentication. Security means that
attribute information is vouched for by third-party issuers who have properly validated the attributes according to their policy and that the integrity of the attributes can be verified by the relying
party, e.g., based on cryptographic mechanisms. In other words, it is hard for users or other parties
to claim attributes they do not have or for multiple users to pool their attributes and gain access to
services they would not be eligible for. For our core mechanisms, security is obtained using cryptographic signature schemes for protecting the integrity of attribute tokens.
6.3.9 Generic Support of Multiple Authentication Technologies
What we have discussed so far relates to the core functionality of the AU2EU authentication architecture: privacy-preserving authentication of attribute statements based on one or more issuers to a
relying party.
However, this constitutes only a subset of the authentication-related functionalities required in a
comprehensive architecture realising this core authentication functionality. Expressed differently, to
make the architecture work, also other forms of authentication are required. This comprises, for
example, authentication of the user to their user agent, authentication of the user to issuers during
an authentication transaction for obtaining short-lived tokens, or authentication of the user to the
issuer when initially establishing an identity relationship. Examples of this have been given already
above.
When performing such authentications, the authenticating party can use any of a plurality of possible mechanisms to authenticate, including the privacy-enhancing authentication mechanisms offered by the architecture. That is, the architecture composes in terms of being used to authenticate
users to parties as a prerequisite for authenticating the user to a service provider. Further possible
authentication mechanisms include, but are not limited to, username/password, PKI-based authentication using strong government-issued security tokens such as eID cards, software PKI certificates,
SSO mechanisms, proprietary mechanisms, and combinations of mechanisms, e.g., a hardwaretoken-based authentication followed by an SSO transaction.
Considering the plethora of authentication mechanisms that can be used in AU2EU, our architecture
is highly generic in terms of not only allowing, but leveraging any legacy authentication method for
establishing certain required authentication relations between parties in the system.
From an architecture perspective, a party (the authenticator) that requires another party to authenticate must deploy an appropriate authentication endpoint for each authentication technology supported. Also, the authenticatee needs to deploy an endpoint for its side of the corresponding mechanism. This holds for both legacy authentication schemes and the privacy-preserving schemes offered by AU2EU.
The architecture for generic support of authentication technologies can be defined when looking at
the authentication interaction between two parties, the authenticator and the authenticatee. The
October 27, 2014
54
Deliverable D1.4.1
authenticator intends to authenticate to the authenticatee in such interaction, thus the general setting in terms of the applied terminology is that of Figure 12.
Authenticator
authenticate
Authenticatee
Figure 12 Parties Involved in Generic Authentication
In terms of architecture, the authenticatee must have at least one authentication endpoint deployed. It can deploy multiple authentication endpoints for the different authentication mechanisms
it envisions to support. This makes sense, for example, for a user agent which can allow both password-based authentication and eID authentication and, depending on the scheme chosen, then enable transactions with the corresponding attribute assurance on a transaction basis. An authenticator similarly needs at least one user-side authentication endpoint or can have multiple such endpoints that can be used its discretion, e.g., depending on the assurance requirements for the authentication. Note that an authenticator endpoint can be trivial, e.g., for username/password authentication it can be realised by the party ‘s browser and its optional password manager. Figure 13 illustrates the high-level architecture for authenticators and authenticatees deploying one or possibly
multiple authentication endpoints.
authenticatee
username/password
government-deployed eID PKI
Party B
AuthN endpoint 1
fully standards-compliant
SSO scheme
authentication
using authN endpoints 1
(mechanism 1)
AuthN endpoint 1
Party A
authenticator
Figure 13 Generic Authentication Architecture of AU2EU for Two Parties
This generic architecture is the basis for any kind of authentication in the AU2EU architecture. For
example, it captures username/password authentication of a user to their user agent, that is, no
other party is involved in the authentication. A more generic view on this is that the authenticatee is
a service provider acting as relying party and the authenticator is a user authenticating an attribute
statement based on multiple issuers to the service provider. In this case, the other parties involved,
i.e., the issuers, are not explicitly captured in this model; however, the abstract notion of authentication is captured. The concrete AU2EU authentication architecture for issuer-based authentication is
a refinement which then captures the additional complexity. In that case, the authenticatee is denoted as relying party as it relies on the certified attributes of one or more third parties.
October 27, 2014
55
Deliverable D1.4.1
If an authentication is not based on a third party, as is the case for the common username/password
authentication and user-claimed attributes, the party the authenticator authenticates to is denoted
as authenticatee, a more generic notion.
Next, we present some scenarios that show how different standard or legacy technologies for authentication come into play when deploying the AU2EU architecture. Those standard or legacy technologies are always used as complement to our privacy-preserving mechanisms to allow the deployment and use of the latter.
6.3.9.1 Scenario1
Consider the scenario in which an issuer, or issuing party, allows users to establish identity relationships with them based on their government-issued eID cards. In such a scenario, the issuer first acts
as relying party towards the user when accepting an authentication of a specified set of attributes of
the eID card of the user. Once such authentication has been performed, the issuing party assumes
the issuer role and grants the user an identity relationship based on the attributes they have authenticated.
This scenario shows how the issuer uses one or more authentication endpoints for the types of government-issued eID cards it plans to accept in order to obtain attributes from a user as the basis for
establishing the identity relationship. This scenario also shows how legacy technologies can be leveraged in a powerful way for allowing users to use the attributes provisioned by those legacy deployments for widespread Internet authentication with strong privacy. That is, the secure legacy
identities can be transformed into easily accessible cloud-based identities with strong privacy protection support. Thereby we can bring the best of both worlds, i.e., of traditional eID and novel privacy-enhancing technologies, together in a concrete system.
6.3.9.2 Scenario2
Now consider the scenario in which the identity agent of the user is being run by a service provider
as a cloud service. Thus, users must authenticate for every authentication transaction they intend to
perform with the agent. For this, the agent has to deploy at least one authentication endpoint. In
many commodity scenarios, this currently will be a username/password endpoint.
Taking this scenario further, the user agent may deploy another authentication endpoint accepting
proofs with government-issued eID cards, thus, having stronger security for the user authentication.
Because user authentication is essential for binding the user to the transaction, using such stronger
scheme enables stronger assurance of the authentication transactions performed in the session with
the user agent. Taking this even further, a future scenario may comprise authentication of a user to
their user agent using a secure element in the user’s mobile phone to which authentication is done
by means of a biometric mechanism. In this way, high-assurance authentications with high convenience could be achieved.
This scenario shows the flexibility of our architecture in terms of supporting a wide range of authentication mechanisms for use in the architecture to enable the privacy-enhancing authentication.
Specifically, its strength is that it supports legacy technologies such as PKI-based eID, thereby leveraging technology already deployed in the field for strengthening the security of transactions or for
bringing strong privacy to a user’s authentication of attribute assertions.
6.3.9.3 Scenario3
Consider another scenario of a customer-specific in-house deployment of the AU2EU system within
a larger identity federation, a so-called entrusted union. The customer intends to allow some of its
employees to use the AU2EU authentication system to authenticate a predefined attribute statement to a relying party in order to access a shared workspace in the larger federation. The authentication within the federation is based on a user agent run as a cloud service to which an employee of
the company needs to authenticate.
October 27, 2014
56
Deliverable D1.4.1
Agent authentication is realised as a combination of hardware-based authentication locally at the
customer using already-deployed credentials, e.g., an RFID badge, and of this authentication triggering a fully standards-compliant and secure SSO flow to the user agent. Note that for this flow, privacy is not an issue as the user is known to the agent with their identity. This combined approach combines multiple standard authentication technologies to initiate a convenient transaction using the
AU2EU system by, for example, a single swipe of an RFID-enabled smart card.
6.3.10 TDL and ABC4Trust
The TDL architecture mandates that each issuer of whom attributes are required in an authentication interaction must provide a token (claim) for such an interaction to the user in an online manner,
based on which the user establishes a compound claim comprising attributes of possibly multiple
issuers. This compound claim is sent to the relying party for authentication, who can verify it using a
cryptographic verification algorithm. The AU2EU architecture generalises this architectural approach
significantly by also allowing users to obtain credentials upfront of authentication interactions and
use those credentials without further involvement of the issuers to authenticate attribute information to relying parties, with full support of unlinkability and untraceability. The AU2EU architecture supports both of those modi of leveraging identity relationships, and thereby makes TDL a special case of its architecture regarding the functionality of privacy-preserving authentication.
Conversely, ABC4Trust assumes that credentials (tokens) are always obtained upfront of an authentication interaction, regardless of whether Identity Mixer or U-Prove privacy-ABC technology is used.
Similarly, AU2EU generalises this to allowing both settings of offline or online issuers or combinations of both for a single interaction. Thereby, both TDL and ABC4Trust reference architectures can
be considered special cases of the AU2EU reference architecture.
6.4 Authorisation
The authentication part of the AU2EU architecture discussed so far is complemented by an authorisation part. The authorisation platform is designed to consume attribute statements authenticated
using the privacy-preserving authentication platform. The design is done in such way that the privacy
properties of the authentication platform are preserved. The authorisation platform has been codesigned closely with the authentication platform to obtain a composite system with strong security
and privacy properties that is applicable to a wide range of practical use cases.
The authorisation subsystem of the AU2EU architecture is based on XACML and extends this standard system towards supporting better privacy through the attribute-based authentication of AU2EU.
The choice of XACML as basis is motivated by the fact that is essentially the only (industry) broadly
supported standard in this domain. However, the standard cannot be applied as is, but requires
some extensions to render it applicable to our model of attribute-based authorisation.
6.4.1 Privacy Issues of the Traditional XACML Architecture
In a traditional XACML system, access requestors cannot obtain information on which attribute information needs to be provided to obtain access to a specific resource. The XACML paradigm is that
an access requestor needs to know which attributes it has to provide. This paradigm is rooted in the
old-fashioned and not privacy-enhancing paradigm of assuming that requestors are always authenticated with their (unique) identity in the system, that is, an combination of identifying attributes or z
unique identifier.
This XACML paradigm is inherently unsuitable for open systems in which requestors may have diverse sets of credentials with certified attributes, and access control is to be realised on a finegranular basis in the ABAC paradigm. The reason is that users will reveal their complete identity to
all parties they need to authenticate to, although for most scenarios already a (small) subset of this
identity in the form of certified attribute statements would be sufficient.
October 27, 2014
57
Deliverable D1.4.1
6.4.2 AU2EU Architecture
AU2EU takes a progressive approach of attribute-based authorisation that is particularly suitable for
open cross-domain authorisation as required for many current and future use cases in an increasingly interconnected world. The main idea is that requestors do not need to have information upfront
regarding which identity data need to be released by them to get access to a particular resource. On
the contrary, when a requestor wants to access a particular resource, the authorisation subsystem
will inform the requestor which additional information needs to be provided for making an access
decision if it is not possible to grant access based on the information currently known about the requestor or access is denied right away. Using this information, the requestor's system can make a
decision on how to fulfil this attribute request using the AU2EU authentication subsystem and provide the respective attribute information in certified form to the service provider. This is where the
authentication system is integrated with the authorisation system. The access control decision can
then be computed based on the attribute information known after the user has provided authenticated attributes.
This approach integrates privacy-enhanced authentication cleanly with privacy-enhanced authorisation. Thereby, authentication and authorisation remain as separated as possible, resulting in a clean
system architecture with a loose coupling of components.
6.4.3 Using the Cloud
Also, the authorisation components may be run as cloud services for simplified deployment of the
functionality. In particular, policy decision points may be run as cloud services, with REST-based interfaces that facilitate elastic scalability depending on system load and easy deployment. The use of
the cloud-based deployment can dramatically simplify the deployment of web applications using
fine-granular privacy-enhancing attribute-based authentication.
As in the case of the authentication platform, the cloud services can be run by the party using them
or a third party offering those services commercially to relying parties.
6.4.4 AU2EU Integration with Legacy and New Applications
The AU2EU architecture can be integrated with new or legacy applications to provide authentication
with attributes certified by third parties in a privacy-enhancing way. To enable applications, the simplest way of integrating the platform is by deploying its components in a public or private cloud environment or using existing, already deployed components.
To serve the needs of the application to be enabled, it is necessary to create an application-specific
PEP, use a standard PEP, or modify a template PEP. Additional integration efforts with AU2EU will be
needed for applications that require more than such a basic integration because of additional features, for special client-side applications or for mobile apps. This also includes the modification of
the client-side applications or apps to integrate with the AU2EU flow. Moreover, it may also involve
local deployments of authentication mechanisms to interface with the AU2EU system, e.g., to allow
users to employ deployed hardware tokens to authenticate to their user agent. Such advanced integration is also necessary for the two AU2EU pilot applications chosen because both are based on
hardware tokens to authenticate users.
6.4.5 Architecture
Next, we will provide more details on the design of the authorisation platform to illustrate the properties of the system to the reader. The basic approach we take is to build on a standard XACML system or an extension of such system.
The basic design approach is that an authorisation decision is split into two phases or decisions. The
first decision is taken by an authorisation subsystem that is specific to the authentication technology
used for soliciting authenticated attributes, e.g., ABC4Trust privacy-ABCs. This decision may not be
required for simple authentication systems, e.g., established standards to which XACML bindings
exist. The second decision is taken by the XACML system based on standard XACML syntax and seOctober 27, 2014
58
Deliverable D1.4.1
mantics. For the overall decision, this decision takes into account the sub-decision made, thus makes
a complete decision within XACML, while having some of the complexity of the authentication system outsourced to the other decision. Specifically, decisions related to semantics that are not expressible in XACML are outsourced to other dedicated components.
6.4.5.1 Policies
The policy definition in such a system requires that depending on the language support, the subject
attribute requirements be specified in either the authorization or the authentication policy language.
For advanced authentication systems that go beyond XACML in terms of syntax and semantics, any
aspects thereof that are not expressible in XACML have to be expressed in an authentication policy
in such a language. Each such authentication policy is included into the defined XACML policy by
reference. This is done by specifying a reference attribute in the XACML policy that represents the
full referenced authentication policy.
This special reference attribute contains the unique identifier of the authentication policy as mandatory value. The semantics of the attribute is that the attribute value is considered authenticated for
XACML if the authentication policy referred-to has been fulfilled with a mechanism-specific authenticated attribute statement provided by the requestor, that is, if the corresponding outsourced decision returns a positive result.
Moreover, also any aspects that XACML may be able to express, but not is able to handle in a privacy-friendly manner in the policy evaluation by the PDP have to be handled in a specific way. A prominent example are predicates, e.g., the predicate that a date of birth is less than or equal to a given
threshold for expressing major age. The problem in XACML is that it can handle such predicates in
the language, but that it cannot receive predicates instead of attributes as input to the PDP. This has
been resolved by the mechanism that the PDP replaces such predicates with references to
ABC4Trust policies and outsources the validation of the predicate to a mechanism-specific authorization subsystem that provides a Boolean value to the XACML PDP.
6.4.5.2 Flow
When a user first accesses a protected resource of the relying party, the PDP or another appropriate
component derives the special attributes that are needed to make an authorisation decision. Policy
combination algorithms, particularly conjunction and disjunction, can be applied. The combination
of authentication policies that corresponds to the special attributes according to the policy combination semantics will result in an authentication policy being provided to the requestor.
The user performs its usual process for an authentication transaction and may present an authenticated attribute statement fulfilling the authentication policy. The relying party checks whether this
authenticated statement fulfils the authentication policy and, if so, will consider the special attribute(s) derived earlier to be authenticated. This means that fulfilment of an arbitrarily complex authentication policy is propagated to the XACML system as authentication of a single or multiple special attributes.
The attribute/value pairs which may be contained in the user-authenticated attribute statement are
extracted and transformed into an XACML request that also includes the authenticated special attributes representing the authentication policy fulfilled. The PDP can now make a standard XACML
decision considering the special attributes of the XACML request and the optional attributes provided.
6.4.5.3 XACML Extensions
A functional extension element is that the policy decision point (PDP) or another appropriate component is needed so that is becomes possible to determine which user attributes are still missing for
computing an authorisation decision based on user and other attributes. Those attributes include
the special attributes referring to specific authentication policies, e.g., ABC4Trust authentication
policies.
October 27, 2014
59
Deliverable D1.4.1
Furthermore, the PEP has to orchestrate the flow described, which is different from the standard
XACML flow because of the attribute-request phase and the additional mechanism-specific authorisation decision. That is, the processes that differ from XACML can be realised through changes in the
application-specific PEP and by adding new components.
For each authentication mechanism to be supported whose syntax and semantics are more involved
than what XACML can handle, a mechanism-specific authorisation component has to be deployed.
This component handles the mechanism-specific authorisation decision on behalf of XACML. Thus
we have a fully modular architecture capable of supporting a wide range of advanced authentication
systems. Approaches that modify the core XACML language and semantics would not be capable of
achieving this, and thus were not pursued. Any standard technology can be supported as usual
through XACML bindings.
6.4.6 Discussion
One of the premier design considerations behind the architecture presented is that XACML flows can
be executed with full standard XACML compliance in parallel to our advanced privacy-enhanced
XACML-based flows. This can greatly facilitate deployment of such privacy-enhancing system in
terms of allowing standard flows in the same system.
The simplicity and effectiveness of the approach are achieved by splitting the decision into a generic,
standards-compliant, XACML part and a mechanism-specific part, thereby outsourcing anything that
is non-standard to the appropriate mechanism-specific component for computing sub-decisions.
Overall, the proposed architecture not only fits in extremely well with the XACML architecture, but
also offers the full feature set of advanced privacy-preserving authentication platforms such as that
used in AU2EU, ABC4Trust, or TDL. We think that this approach can help pave the way for real-world
deployments of privacy-enhancing authentication technologies from those projects.
6.5 Ontologies
Open identity federation systems present the challenge that different parties are likely to use different vocabularies1 with different semantics. For example, an issuer might refer to the first name of a
person using a specific string, e.g., first name, whereas a relying party may refer to the same concept
of first name using the string fname. Note that the presentation here is simplified, because in practical systems attribute names usually are based on URIs or similar schemes in order to use proper
namespaces.
6.5.1 Open Systems
In contrast to a so-called silo system, an open identity system is one in which more than a small set
of parties, e.g., a single identity provider and a single relying party, need to interact with each other.
We differentiate two kinds of such open systems: A completely open system at the scale of the Internet, which is the ultimate goal to address, and an entrusted union, that is, a union of a plurality of
identity providers and relying parties who can agree on certain aspects, e.g., one or more common
vocabularies they share, and mappings between them. Users do not have their own vocabularies,
but rather build on those of the issuers.
There are several reasons why such different semantics emerge in an open system, and will look at
some of them next. For example, a party, such as an issuing party, may build on top of a legacy system, such as LDAP, and carry over the vocabulary of that legacy system into the federation system.
There is no unique agreed-upon vocabulary for generic concepts that is used by all parties, e.g., in
1
Note that we use the terms vocabulary and ontology loosely synonymously in this chapter.
October 27, 2014
60
Deliverable D1.4.1
the form of an international standard, and especially not for domain-specific concepts, e.g., the vocabulary used in the context of a specific industry. Also, in an open system, there is no single party
available that could act as the party determining or consolidating multiple vocabularies of different
domains into a unified vocabulary or imposing a unified vocabulary for everyone.
6.5.2 Bridging Domains
To enable parties from different vocabulary domains to interoperate with each other and understand each other’s messages, the various vocabulary domains need to be bridged. AU2EU provides
an ontology-based solution for this problem for entrusted unions, hence the title of the project. A
solution for a completely open system, such as the Internet, can build on the same concepts we present, but will have to be augmented with open mechanisms for ontology management, such as
agreeing on and distributing ontologies.
The AU2EU approach of addressing authentication and authorisation in entrusted unions assumes
that each identity provider in the union and each relying party in the union can use different, e.g.,
their own, vocabularies and semantics. Furthermore, we assume that parts of the vocabulary may be
shared and that for the remaining parts mappings, also called alignments, are defined between domains that need to interoperate. Users do not use their own vocabularies, but build on vocabularies
of other parties.
Let us consider a simple example of a union with three different issuers and a relying party that accepts certified attribute assertions from each of those issuers. The example scales to k issuers and an
arbitrary number of independent relying parties. Note that we do not discuss the resulting complexities, e.g., conflicting ontologies or the maintenance of many ontologies that arise from this scaling to
large numbers in this architecture document. Figure 14 gives an example of vocabulary mapping and
uses a colour coding for representing the different domains and artefacts expressed in the respective vocabularies.
Mapping
Issuer A
Mapping
Ontology-based mapping
for translating policy
to user's semantics
Credential 1
Ontology-based mapping
for translating
proof token to relying
party's semantics
Policy
Credential 2
Issuer B
Relying
party
User
Proof token
Credential 3
Issuer C
Semantics domain A
Semantics domain B
Semantics domain C
Figure 14 Vocabulary Mapping
October 27, 2014
61
Deliverable D1.4.1
6.5.2.1 Setting
For example, Issuer A resides in its own domain Domain A, marked in blue. Analogously, the colours
green and magenta denote Issuer B and Issuer C, respectively, who are in their respective domains
Domain B and Domain C. A credential (claim, token) that A issues to a user as part of an identity relationship established between the user and A is expressed in the vocabulary of Issuer A, thus is blue.
In our example, the user obtains credentials from each of the issuers. With each credential that the
user obtains, it becomes a member of the domain of the respective issuer in terms of using the vocabulary. Thus, our user is part of all three domains blue, green, and magenta. The user understands
what policies and assertions mean based on those vocabularies. Of course, in the general case, the
relying party also resides in a different, e.g., its own, vocabulary domain, indicated in cyan.
6.5.2.2 Flow
Next, we will look at how interoperability is established between entities in the different domains.
We assume a scenario in which the user intends to access a service that is access protected using the
AU2EU architecture at the relying party. The user first issues a request for accessing the service (not
shown) and in response receives a policy it has to fulfil in order to access this service. This policy is
an authentication policy and is essentially a request to reveal an authenticated attribute assertion
(i.e., claims) to the relying party. The policy is expressed in the cyan-coded vocabulary domain of the
relying party.
The user does not understand the meaning of the request as it is not expressed in any of the vocabulary domains the user resides in. Thus, the user applies a mapping from the domain of the relying
party to the domains it understands. Once the policy has been translated into such a comprehensible vocabulary, the user can process it further. The user’s system (user agent) matches the credentials of the user with the policy and thereby obtains potential assertions it may release to fulfil the
policy. The user selects one of these assertions and has its agent generate a cryptographic proof of
the assertion based on identity relationships with the issuers. This proof generation may use credentials (tokens) the user has previously obtained or fetch fresh single-use tokens from the issuers. The
assertion may comprise attributes of multiple credentials, thus it may use a compound vocabulary of
multiple domains as indicated by the multiple colours in the encoding.
The relying party can cryptographically verify the proof for the assertion when it is expressed in the
user’s semantics, but only then. However, the assertion and proof per se are not “understood” by
the relying party because they are not expressed in the user’s vocabularies. Thus, the relying party
needs to translate the assertion back into its own vocabulary (shown in cyan) using an appropriate
mapping. After this mapping has been applied, the relying party can use the assertion for computing
an authorisation decision for the user’s resource request.
Using this approach, all parties in the system can interoperate in terms of authentication and authorisation to allow an open system.
October 27, 2014
62
Deliverable D1.4.1
User
Relying Party
service request
Mapping
authN policy
map authN policy to
user's vocabulary
compute/choose attribute
statement to fulﬁll
authN policy
compute cryptographic
proof for attribute
statement
attribute statement
& proof
verify attribute statement
against proof
map attribute statement
to Relying Party's Mapping
vocabulary
compute authorization
decision based on
attribute statement
authN policy
Figure 15 Flow
Figure 15 presents a high-level sketch of the message flow for an integrated authentication and authorisation flow discussed, and clarifies the loose coupling of the authentication system and ontology-based mapping approach. Essentially, there are only two points in the overall flow at which the
mapping plays a role: (1) Upon receipt of the authentication policy from the relying party, the user
has to map it from the issuer’s to its own vocabulary. (2) Once the relying party has cryptographically
verified the received attribute assertion against its cryptographic proof, it performs a mapping of the
assertion back from the user’s to its own vocabulary.
This architecture keeps the integration requirements for authentication and vocabulary mapping
minimal. Also, it allows every party to use its own language for most of the processing required. Particularly, users see the relying-party policy in their own, familiar vocabulary, and the relying parties
use a verified attribute assertion in their own language for computing access decisions based on the
assertion.
Our current proposal envisions that only two protocols will be available in the AU2EU architecture
for privacy-enhancing authentication of attribute statements by users to relying parties: the Identity
Mixer [ [7], [8], [9]] credential system and the U-Prove [ [10], [11]] credential system, both of which
enable untraceable, data-minimising transactions. Therefore the ontology-based mapping needs to
be implemented only for those systems.
October 27, 2014
63
Deliverable D1.4.1
6.5.2.3 Ontology Management
The prerequisites for the approach to work are that the alignments between different vocabularies
are available. For the more closed setting of entrusted unions, this problem can be solved by establishing pairwise alignments between parties that need to be interoperable. A suitable party to provide an alignment is the relying party because it consumes the services of certain issuers as it deems
appropriate. An issuer is not a suitable party to provide such alignments because it does not have to
be aware of which relying parties consume its services of providing certified attributes. An alignment
needs to be integrity protected because it is crucial for security and because a tampered alignment
can be as bad as the execution of an attacker’s code. Alignments can either be distributed using
standard PKI mechanisms or they can be pre-distributed in (small) entrusted union deployments.
Fully open systems, such as the Internet, require more elaborate approaches of managing ontologies
for vocabulary alignment.
6.6 Assurance
An extremely important aspect of digital identities and thus authenticated attributes is their assurance. The assurance level indicates not only the rigor applied in the validation of the attributes by
the issuer and the strength of authentication of the user with the user agent or issuer, respectively,
depending on the protocols, but also the security properties of the authentication technology being
used.
All aspects of attribute validation by the issuer, the strength of authentication of the user with the
agent or issuer, and the technology need to be combined for deriving the assurance level of the authenticated attributes. This level of assurance is relevant for the trust decision to be made by the
access control system of the relying party based on the authenticated user attributes.
Take for example an issuer who has validated attributes at a high assurance level. If the user authenticates to the user agent using a username and password, the assurance level of the attributes authenticated to the relying party reaches only the level of authentication with the user agent, which is
less, say only medium. Such scenario with a medium assurance level may be sufficient for a majority
of the authentication transactions a user needs to do in its everyday interactions. However, the user
may use a government-issued eID for the small set of transactions that require a high assurance level
for the entire authentication transaction. This approach of allowing different authentications of the
user to the agent or issuer caters for the needs of the real-world structure of user authentications
needed. Moreover, it does not impose the burden of using high-assurance authentication for all
transaction.
This again builds on the generic view of authentication in the AU2EU reference architecture in terms
of parties being able to accept any kind of authentication with different levels of assurance at their
discretion. Handling assurance in a general way in the architecture means that is has to be considered in both the authorisation and the authentication platforms of AU2EU in a concerted manner.
6.7 Cloud Deployment
AU2EU attempts to deploy ABC technologies in a novel manner, thereby offering more convenience
and ease of deployment for all parties involved than traditional deployments. We discuss the traditional approach and the approach taken by AU2EU on the deployment of privacy-ABC technologies
next.
6.7.1 Traditional Approach
The traditional architecture for credential-based authentication requires each player to run the cryptographic protocols it requires as part of the software system implementing the party's functionality.
Expressed differently, every party must deploy a cryptographic protocol endpoint for each supportOctober 27, 2014
64
Deliverable D1.4.1
ed authentication mechanism. This complicates the deployment of the technology and entails the
requirement to install software, particularly for users. The latter has always been a major inhibitor
for privacy-preserving authentication protocols, such as privacy-ABCs, because of the complexity of
technology deployment for every party.
establish identity
relationship
Issuer
User
ABCE
ABCE
authenticate
Relying Party
ABCE
issue token
Figure 16 Traditional Architecture
Figure 16 shows the high-level architecture in terms of parties deploying a protocol endpoint, labelled ABCE for ABC Engine, locally, e.g., within their application as an in-process protocol endpoint.
Such protocol endpoint can be available as software library. The library provides the cryptographic
functionality and complementary functionality, e.g., key management, so that each party can realise
their respective protocol endpoint for privacy-ABCs.
6.7.2 Cloud-Based Approach
The AU2EU authentication platform uses web-services-based services to obtain a more streamlined
deployment of the privacy-ABC technology than the traditional approach of deploying all components locally, possibly as in-process components of the application, by the respective parties.
Those web services expose easy-to-use REST-based interfaces that can be accessed by the respective
party’s application. A web service may be hosted by the party itself, or the party may make use of a
third-party service. In either case, the simplicity of a REST-based interface can be leveraged for
streamlining the integration of the authentication platform into the application. If a third-party service is used, not even the REST-based web service needs to be deployed by the party.
establish identity
relationship
authenticate
User
Relying
Party
Issuer
Service
User Agent
Service
Relying Party
Service
ABCE
ABCE
ABCE
Issuer
issue token
Figure 17 Cloud-based Architecture
Figure 17 presents the changes in the architecture required for a cloud-based deployment of the
authentication parts of the architecture. The key property is that the cryptographic library for the
credential protocols need not be run within the process executing the code of the respective party.
In the figure this component is labelled ABCE for ABC engine. Instead, the cryptographic functionality
is implemented by a separate process/service that is accessible through a REST interface. Optionally,
such separate processes/services may be implemented and run by the party itself or a third party
October 27, 2014
65
Deliverable D1.4.1
offering the services. The latter is particularly attractive to users because, as discussed, it simplifies
the use of the system and eliminates the need to install software.
We next discuss the advantages and possible compromises involved in a web-services-based deployment for the various parties.
6.7.2.1 User
The user side of the authentication endpoint for privacy-ABCs is preferably deployed in a cloud service to enable zero-footprint user-side deployments and at the same time leverage the benefits of
the strong security and trust model of credential systems. Clearly, such a cloud deployment will entail certain trade-offs in terms of system properties. Concretely, those trade-offs include that a
cloud-based UA offered by a third party needs to be trusted by the user. In other words, the trust
model is weakened compared with the traditional deployment approach for privacy-ABCs.
The architecture for the privacy-ABC part of the authentication system is, however, designed in such
a way that a user can decide not to rely on a cloud-based service, but instead install their own user
agent locally, in a public cloud, or in a location of their liking, thus becoming the trusted provider of
the UA themselves. In this deployment scenario, the user can benefit from the full properties of the
credential system, e.g., in terms of privacy, without making the additional assumptions on trust in
the third-party user agent provider. Thus, the overall AU2EU architecture combines the advantages
of cloud and local deployment, depending on user's choice, and thereby enables a trade-off between
convenience and simplicity on the one hand and privacy on the other hand and, of course, in a usercentric architecture this trade-off is left to the user themselves to be decided upon.
6.7.2.2 Relying Party
A relying party may choose to run the cryptographic protocols for verifying tokens provided by users
themselves, to use its own cloud service, or to use one offered by a third party. This again provides a
trade-off between ease of deployment and the trust model. The AU2EU architecture is designed
such that the use of cloud-based services or the use of the parties’ own implementations of those
services is essentially transparent to other parties.
6.7.3 Access Control
Much like the authentication components of the project discussed, also the authorisation components may be provided as cloud services for simplified deployment of the functionality because of
the loose coupling with the application deployment. Specifically, policy decision points may be run as
cloud services with REST interfaces, which facilitates elastic scalability depending on system load and
offers ease of deployment. The approach of AU2EU of maintaining the stateless property of XACML
to a large degree considerably facilitates elastic scaling of policy decision points in cloud environments using standard scaling approaches. As for the authentication platform, also the cloud services
can be run either by the party requiring them or by a third party offering the services commercially
to relying parties.
Using the cloud-based approach for deployment can dramatically simplify the deployment of Web
applications using fine-granular privacy-enhancing attribute-based authentication. For deployment,
the party needs to enrich their application with a limited amount of code, e.g., following a template
approach or using examples realised by the AU2EU project, to make the appropriate web service
calls. The web services are either deployed by the party itself or consumed on an as-needed basis
from a commercial provider.
6.8 Legacy Integration
The AU2EU architecture does not build on the assumption of starting from a clean playing field. Rather, it builds on top of a plurality of different legacy technologies and systems that are available and
October 27, 2014
66
Deliverable D1.4.1
deployed in practice. This is crucial for a privacy-preserving identity management architecture such
as that of AU2EU:
 Legacy technology can be leveraged for secure authentication in the “back end” of the authentication system, e.g., for authenticating a user to the user agent or to an issuer, where
privacy is not a relevant property because of existing relationships;
 Legacy systems can be used as attribute sources for attributes with considerable assurance
properties onto which an AU2EU deployment can be bootstrapped;
 Using deployed systems can help benefit from investments already made into existing infrastructures and their seamless integration with AU2EU.
6.8.1 Attribute Sources
An attribute source is a system in a generic sense that provides attribute information about users.
An attribute source allows an issuer to obtain attributes as the basis of identity relationships. The
AU2EU architecture can leverage a plurality of legacy technologies as attribute sources for establishing identity relationships. That is, an available system deployment which stores user attributes in
some form with a given degree of attribute validation having been done can be connected with an
AU2EU issuer deployment to allow the issuer to create identity relationships based on those identities. Next, we give two example classes of attribute sources which AU2EU can tap into in a concrete
deployment, thereby leveraging existing investments.
6.8.1.1 PKI
A particularly important class of legacy systems to be used as attribute sources are traditional PKI
infrastructures. Common examples are government-maintained PKI infrastructures, e.g., government-issued electronic ID cards. An AU2EU issuer can be deployed in such a way that authentications done through eID cards by users can be leveraged and that based on the latter it can establish
identity relationships for those attributes with the respective users. Essentially this means that a
user can transform their high-security smart-card-based government-issued PKI certificates into
AU2EU identity relationships, e.g., a privacy credential to be used for their day-to-day identity management in the Internet. This is an important use case for governmental eID schemes going beyond
the intended primary use cases of e-government. Given the added convenience of authenticating
with AU2EU rather than with traditional eID schemes, this might help resolve the problem of nonadoption of eID in the private sector.
6.8.1.2 Corporate Directories
In-house databases of organisations that comprise attribute information of people affiliated with
those organisations are another important class of legacy systems. Examples are HR databases of
companies which hold verified attributes of their employees. Those systems are often based on
LDAP, a standard for representing such information. Such a directory can be connected to an issuer
in a specific deployment to allow the issuer to obtain the attributes of those attribute sources for
establishing identity relationships with the people the attributes apply to.
6.8.1.3 Discussion
The PKI-based class of examples builds on establishing an identity relationship based on an authentication performed by a user in an online transaction and thereby transferring the PKI certificate into
the AU2EU system, conceptually speaking. The directory-based class of examples of in-house attribute sources follows a different paradigm of attribute source. In this case, different processes of establishing the identity relationship with a user can be envisioned in terms of how the user can obtain
the possibility to authenticate with the issuer. The AU2EU architecture pushes this decision towards
a concrete deployment and therefore remains flexible in terms of allowing a wide range of possible
deployments.
October 27, 2014
67
Deliverable D1.4.1
Once an identity relationship has been established based on a legacy attribute source, the user can
use the attributes for a wide range of online authentication scenarios. In the case of a cloud-based
user agent, this enables users to use the privacy-enhancing authentication features of AU2EU and
thus to bootstrap a capable privacy-friendly identity management ecosystem without having to install additional software on their machines.
6.8.2 Authentication
Legacy systems such as government-run eID systems can be used not only as attribute sources as
explained above, but also as specific authentication schemes, without having any privacy-preserving
capabilities, thus allowing users to authenticate to their user agent in a very secure manner, e.g.,
based on an eID smart card. Accordingly, we see a second dimension of the use of deployed PKI
schemes within AU2EU. This enables higher-assurance transactions than those based only on authentication with username and password.
6.9 Overview of Deployment of an AU2EU System in Real-World Settings
The reference architecture discusses how systems following the AU2EU paradigm can be realised.
The reference architecture needs to be refined through detailed technical architectures for authentication and authorisation. This will be done through the respective documents D2.1.1 and D3.1.1 to
be released later. In a concrete system deployment, the implementation and deployment of each
party system needs to follow the corresponding parts of the technical architectures. Different deployments for the same type of party, e.g., issuer, may be done differently, e.g., in terms of how the
issuing service obtains attributes for identity relationships by connecting to different existing types
of user attribute sources.
As discussed in this document, the architecture composes very well and thereby leverages existing
identity infrastructures and protocols, e.g., government-issued PKI schemes or private-sector issuers
using SSO protocols. This integration helps bootstrap an AU2EU system based on existing (strong)
identities of those legacy infrastructures, and thereby combines the advantages of those systems
with the privacy advantages of AU2EU. Essentially, the identities of any available identity infrastructure can be transferred into the AU2EU cloud, and then be used by users for convenient privacypreserving authentication.
The AU2EU architecture can be integrated with new or legacy applications to provide authentication
with attributes certified by third parties in a privacy-enhancing way. To enable applications with
AU2EU authentication, the simplest way of integrating the AU2EU platform is by deploying its components in a public or private cloud environment or using existing, already deployed components.
Applications to be enabled can simply connect to those web services using REST-based interfaces.
When looking at how an application, either legacy or new, is enabled with AU2EU-based privacypreserving authentication capabilities, application developers can follow a simple pattern. Implementation wise, an application-specific policy enforcement point (PEP) has to be created, a standard
PEP be used or a template PEP can be modified to serve the authentication and authorisation needs
of the application to be enabled. To facilitate deployment, AU2EU template PEPs can be provided as
open-source components for common standard classes of applications, e.g., web applications served
by a specific open-source application server, such as Tomcat.
Applications requiring more than such a basic template-based integration, for example because of
additional features, special client-side applications or the availability of mobile apps, require further
efforts for integration with AU2EU. This also includes the modification of client-side applications or
mobile apps so that they integrate with the AU2EU flow. This is also the case also in the AU2EU pilot
applications chosen, which both will involve complications such as user-side hardware tokens for
higher assurance or convenient authentication following key requirements for the pilots.
October 27, 2014
68
Deliverable D1.4.1
Once the implementation task has been completed, the next step is the deployment of the AU2EU
services in a cloud environment. This is followed by setting up both the authentication and the authorisation system in terms of generating cryptographic keys and other materials, authoring authentication and authorisation policies that integrate the latter into the AU2EU paradigm, and deploying
all those in the service.
Overall, the deployment can be seen as an approach of putting (open-source) building blocks together, implementing the required service around them, deploying the components, and deploying
the cryptographic parameters and policies.
6.10 Building on and Leveraging Existing Architectures
The proposed reference architecture leverages features of the underlying architectures of
ABC4Trust, TDL, and TAS3. It comprises an extended subset of those architectures which has been
aligned with the requirements of the AU2EU use cases, pilots, and standard (web-based) use cases
of everyday user interactions on the Internet. The decisions have also been made particularly in the
light of designing the AU2EU architecture in such a way that it enables easy deployment and adoption.
The core ideas of data-minimising authentication and authorisation have emerged from the TDL
architecture, which is a generic architecture for data-minimal identity management focused on using
short-lived tokens and ABC4Trust, which is specific to using privacy-ABCs as authentication technology. In AU2EU, we leverage and build upon the concepts proposed by TDL and instantiate them
through ABC4Trust credential technology.
6.11 Trust Management
The proposed architecture features a very general and powerful approach to trust management.
Authorisation and authentication policies jointly express requirements to be meet by a user who
intends to access a resource. Those requirements are expressed in an attribute-based manner, going
much beyond what XACML can express in its out-of-the-box deployments.
Concretely we allow the specification of each requested attribute that parties are trusted for vouching, that is, may be its issuer. This allows the assurance requirements to be adjusted according to the
needs of the concrete application case at hand. Particularly, it allows the implementation of for having different requirements for different attributes needed in a single access control decision. Such
general trust semantics cannot be expressed in XACML, where the trust decisions of this kind are not
handled in the authorisation system, but rather in the authentication system by a rigid list of trusted
issuers (identity providers).
Also, the AU2EU approach is extremely standards compliant with XACML in that mechanism-specific
aspects of trust management are outsourced to the mechanism-specific authorisation part outside
of core XACML.
Trust management in AU2EU draws upon ideas put forth in the TDL, ABC4Trust, and TAS3 architectures. It builds on top of the ABC4Trust model of expressing trust relationships on a per-attribute
basis, which is in-line with the proposals of TDL. With the ontology-based extensions, we introduce
entrusted-union-scale and large-scale interoperability, and enhance our scheme towards more generic trust management capabilities. However, we do not go as far as the TAS3 architecture in proposing a full-blown 2-party trust management approach as this would be less compatible with
XACML. The reasons for this are requirements from our use cases, which typically require the service
provider to be authenticated under its identity, and the substantially easier deployability of our sim-
October 27, 2014
69
Deliverable D1.4.1
pler approach and its XACML compatibility. In our opinion, our approach balances the practical
needs of use cases with powerful trust management functionality for a practical system.
Considering the above discussions, we have implemented an architecture that nicely balances the
advanced features of its contributing architectures, while remaining very practical. Further features
may be added in future versions of the architecture if needed. This approach of keeping non-needed
features currently outside of the architecture helps simplify the deployment and enables smooth
deployment of additional features once a system is deployed in practice.
6.12 Conclusions
Considering the discussion on the reference architecture proposed by the AU2EU project, we can
conclude that this architecture strikes a balance between functionality and simplicity, which helps its
practical adoption and deployment. Especially the cloud-based deployment option and the trust
management features enable an easy deployment in open systems. The openness again helps reduce cost because identities can be re-used and no silo identities that are usable only with a single
party are established.
In later stages of the project, this reference architecture will be refined with concrete architectures
for the authentication and authorisation subsystems and their integration.
October 27, 2014
70
Deliverable D1.4.1
7 Components
In this section, we give an overview of the architecture components deployed at parties of the
AU2EU reference architecture. This can be seen as a very high-level view on the detailed architecture documents D2.1.1 and D3.1.1 of AU2EU to be published later in the project. The detailed architecture is currently still being defined and thus may change until release of the corresponding architecture documents.
Figure 18 Main Components of AU2EU Parties
7.1 Authentication
The AU2EU authentication approach requires multiple parties and components at those to be deployed as already discussed abstractly in the architecture section 6.3.3. In addition to the parties for
a basic deployment as discussed, namely users, service providers, issuers, and relying parties. We
need additional parties in a generic setting leveraging all functionality of the AU2EU authentication
system. A detailed authentication architecture will be made available as AU2EU document D2.1.1.
7.1.1
Parties
7.1.1.1 Issuer
The issuer issues credentials to users, thereby vouching for the correctness of the information contained in the credential with respect to the user to whom the credential is issued.
October 27, 2014
71
Deliverable D1.4.1
7.1.1.2 Inspector
The inspector is a party that can be used for ensuring accountability in anonymous transactions, that
is, bringing the seemingly contradictory properties of strong privacy in the sense of data-minimal
transactions together with user accountability in such transactions in a single privacy-preserving
authentication system. Under specific circumstances, this trusted authority can de-anonymize
presentation tokens and reveal specific user attributes, in case a certain previously agreed condition
becomes trues, e.g., in the context of law enforcement.
7.1.1.3 Revocation Authority
A revocation authority is a party responsible for revoking issued credentials, so that these credentials can no longer be used to generate a valid presentation token. In such privacy-preserving settings revocation is a highly non-trivial task because it is not possible to do revocation based on identifiers of credentials as those are typically not revealed. Rather, advanced cryptographic mechanisms
are employed by the revocation authority and other parties in order to ensure that revocation does
not affect privacy in a negative way.
7.1.2 Authentication Libraries
The authentication components, at a very high level, comprise libraries for the different supported
authentication mechanisms. Each of the parties may have libraries for multiple of the supported
authentication mechanisms installed in a deployment, which represent the authentication endpoints
as discussed in the architecture section of the document. We currently support the ABCE and SAML
libraries, which we will introduce in the following paragraphs.
ABCE Library
All of the issuer, user agent, verifier, revocation authority, and inspector are using the ABC4Trust
ABCE authentication library. This component implements the cryptographic protocols for realising
attribute credentials with strong privacy. As of the current design, each of the parties uses the same
library and uses only the subset of functionality thereof which is required for performing their tasks.
The parties may deploy the library through a web service or build upon a third-party web service in
order to simplify their deployment.
SAML Library
For the SAML part of the authentication infrastructure, a protocol library is hosted by a party that
intends to accept SAML tokens for authentication and by a corresponding SAML Authority. Due to
the weaker privacy properties of this protocol suite compared to the AU2EU credential-based protocols, we intend to utilise the protocol not in the front end between user and service provider, but
rather as an authentication mechanism between users and user agents or identity providers. The use
of the protocol is deployment specific and will allow realising simplified user authentication in the
back end of the architecture.
7.1.2.1 Policy-Privacy Authentication/Authorisation Library
This library implements the functionality of the policy-private authentication and authorisation integrated mechanism of AU2EU. This mechanism is an experimental research implementation and capable of performing authorisation without revealing the access control policy to the user by using
cryptographic protocols. This approach deviates from the core architecture of how to integrate authentication and authorisation as it is based on a unified approach to the problem doing authorisation also based on cryptographic protocols integrated with authentication.
October 27, 2014
72
Deliverable D1.4.1
7.1.2.2 Device Attestation Library
The support of high-assurance transactions is becoming increasingly important in online transactions. The AU2EU authentication platform therefore supports a building block for device attestation
of Android-based systems. This attestation is essentially an authentication system with the purpose
of authenticating properties of the device. In contrast to this, the other supported authentication
systems in the platform authenticates users’ attributes. Combining both (users’ attributes and device
properties) allows raising the assurance of the authenticated attribute assertions (claims) and thus
the overall online interaction which builds upon the secure authentication of user-related attribute
statements. The technology of this platform component is again different to the other technologies
used, for the reason of the low-level platform attestation being done.
The authentication model of this component does not rely on a trusted third party issuer in the usual
sense. Instead, a trust anchor in the device, e.g., a secure element, acts as a conceptual trusted party
towards the relying party and generates authentic attribute tokens making assertions about the
device. The trust anchor will, of course, require some form of initial endorsement, e.g., during postmanufacturing processes, through a trusted party, e.g., by issuing a digital certificate to it.
7.2 Authorisation
Next, we present the components related to the authorisation part of the AU2EU overall integrated
platform. This is similar to the XACML architecture in the core components, however, is extended
through additional components realising functionality such as ontology-based mapping between
different vocabularies. Figure 18 depicts the conceptual relationship between these components.
Further details on the authorisation architecture will be published as document D3.1.1.
7.2.1 The Local Administration Point
The local administration point is in charge of managing the policies that are applied by a decision
point of a specific organisation. It is composed of a PAP (Policy Administration Point), a local mapper,
and a local policy validator. All of these components will be described thereafter.
7.2.2 Policy Administration Point
AU2EU defines a policy administration point based on the XACML PAP specification [13]. The PAP
provides a storage mechanism for all the policies of the domain (files or databases) and provides a
complete CRUD interface (Create, Read, Update and Delete) in order to easily manage policies. The
REST architectural style seems to be suitable for such interface.
An HMI can optionally be provided in order to facilitate the policy administration. Due to the complexity of XACML representation, this kind of HMI cannot be generic. Usually, domain specific HMI’s
are developed in order to make the complexity of the XACML language more manageable. In AU2EU,
dedicated interfaces for administration points that are specific to the pilots will be developed if
needed.
7.2.3 Local Mapper
The local mapper is in charge of mapping the local concepts that are used to specify access control
policies of a specific organisation to universal concepts that are shared with external organisations.
The local mapper provides ontology editing capabilities and mechanisms allowing local administrators to edit and export ontologies expressing local concepts in order to share them with an external
organisation. These security policy concepts specifying semantics of attributes and conditions that
are used to grant or deny access can also be shared at a consortium level in a context of a collaboration involving more than two organisations. Import capabilities are also provided in order to align
external concepts with internal ones.
October 27, 2014
73
Deliverable D1.4.1
7.2.4 Local Policy Validator
In a multi-organisational context, the complexity and the number of control access policies increases. Moreover, the access control policies are edited by various administrators and the access requests are received from different domains where points of views and objectives can diverge. In
such context it is impossible for a human to predict all possible access cases and test cases. A validation tool is provided to ensure that the local policies behave as predicted in a multi-organisational
context. The validation process relies on formal models to check the consistency of the policies and
their compliance with local requirements and to carry out exhaustive analysis of cases where access
could be granted or denied and the impact of concept mapping.
7.2.5 Federal Administration Point
The federal administration point is in charge of putting together various access control policy concepts coming from different organisations of a federation or entrusted union and to verify the consistency of these concepts once merged together.
The federal administration point provides ontology editing capabilities and mechanisms allowing a
federal administrator to import and export ontologies from and to local organisations. Putting together several ontologies that specify related concepts could lead to inconsistencies caused by incorrect interpretation of concepts or redundancies. A verification tool is provided at the consortium
level to check such inconsistencies.
7.2.6 Policy Repository
The Policy repository stores access control policies. These policies are managed through a local administration point and evaluated by a local decision point.
A policy repository is dedicated to each organisation in order to store the authorisation policies that
are related to its resources. Each policy repository is connected to a dedicated organisation PDP.
Local concepts and vocabulary are used to store authorisation policies in policy repositories.
7.2.7 Policy Decision Point
The decision point is in charge of evaluating access requests against authorisation policies before
issuing access decisions.
AU2EU defines a decision point based on the XACML PDP (Policy Decision Point) specification [13].
The XACML PDP process and algorithms will be extended in order to support privacy [14] [15] [16].
The ability to deliver information about the attributes that need to be provided in order to grant
access to a specific resource is an example of capabilities that will extend the XACML PDP. This functionality allows end users to choose and minimise information that is revealed about them during
the authorisation process.
The PDP needs information in order to grant or deny access. The information needed can be extracted from the authorisation request coming from the PEP or can be retrieved from the PIP. In case of
some required user information missing, the PDP will return a DENY response with a list of required
attributes.
The PDP can be run in process or be accessed using a REST interface and improved flexibility in terms
of deployment and scalability. The PDP is stateless which makes it easy to provide for elastic scalability using standard cloud-related technologies, e.g., load balancing and auto scaling of the PDP component. The most prominent deployment example of the AU2EU PDP will be the deployment with a
single PDP, possibly scaled to multiple instances in order to support elastic load balancing.
Another deployment option within AU2EU is in a multi-PDP setting where the decisions of multiple
PDPs are considered for taking a decision. This brings a subset of multi-PDP functionality of the TAS3
[2] to the AU2EU architecture.
All the user information required to grant the access is validated by the authentication platform
which validates the user token upstream.
October 27, 2014
74
Deliverable D1.4.1
7.2.8 Policy Enforcement Point
The Enforcement Point is an entity that is responsible for enforcing the access decision taken by a
local decision point and consequently to effectively grant or deny the access. The enforcement point
is based on the XACML PEP (Policy Enforcement Point) specification [13]. It intercepts all access attempts to a protected resource. It collects information about the access request, such as, who is
making it and the resource that is being accessed and sends a decision request to the decision point.
In context of AU2EU, the enforcement point plays a key role to enable the integration of the authorisation and minimal data authentication platform observing end-user privacy. Consequently, the enforcement point will use the authentication results to find information about the user. Such information is collected from the authentication system itself or through a PIP caching authentication
results.
The PEP is typically application specific and needs to be rewritten, or at least adapted, for a new
application. This is in line with PEPs as defined in standard XACML.
7.2.9 Policy Information Point
The PIP (Policy Information Point) is the system entity that acts as a source of attribute values. Basically if there are missing attributes in the XACML request that is sent by the PEP, the PIP would obtain them to enable the PDP to evaluate the policy. This component can retrieve information about
the subject, the resource, or the environment. Several capabilities will be provided by the PIP to
support the multi-organisational dimension and to enable a smooth integration with dataminimising authentication such as verification of attribute mapping mapped in external organisation
and proof verification of external user attributes.
October 27, 2014
75
Deliverable D1.4.1
8 Challenges of Large Dynamic Cross-Domain Collaborations
This section describes the challenges for the design of an integrated eAuthentication and eAuthorisation framework by large dynamic cross-domain and jurisdictional collaborations. Such description
is twofold: on the one hand, Section 8.1 presents those challenges associated with the different use
cases analysed in deliverable D1.1.1 [4] and D1.2.1 [5], whereas, on the other hand, Section 8.2 provides a different perspective based on the legal and business analysis performed and shown in deliverable D1.3.1 [6].
8.1 Challenges based on the AU2EU Use Case Analysis
This section describes the challenges that will be addressed within the context of AU2EU in order to
develop an integrated eAuthentication and eAuthorisation framework by large dynamic crossdomain and jurisdictional collaborations. Such description will be led by the use case analysis performed in deliverables D1.1.1 [4] and D1.2.1 [5].
Special emphasis will be put on those challenges focusing on the aspects of security, privacy and
trust that need to be properly handled by the eAuthentication and eAuthorisation framework in
order to guarantee its successful deployment, functioning and acceptance.
8.1.1 Biosecurity Incident Response Use Case Challenges
While conducting the Biosecurity Incident Response use case requirement analysis and mapping to
the software components and architecture, we identified the following technical challenges, which
can lead to interesting research:
1) In the Biosecurity Incident Response use case, an urgent animal disease incident may involve
multiple participants from different organisations. It is challenging for existing IT infrastructure and technologies to quickly manage the identities and privileges of these dynamic participants for the animal disease case. So a simple UI and efficient security protocol are required to enable the collaborative parties to quickly set up a dynamical collaboration when
an animal disease incident occurs.
2) The Biosecurity Incident Response use case may produce and share a lot of sensitive data. It
is thus challenging to guarantee the security and privacy of the data, especially when the
system is compromised by malware and/or hackers, that can access data by circumventing
the regular access control mechanism. So new data security technology is required to protect the collective confidential data during collaboration.
3) Given so many existing ID federation technologies and protocols, it is challenging for software architects to decide which one and/or which combination is the best suitable to their
particular application. As a result, a security model/tool is required to provide the best architectural solution, based on different collaboration application requirements for security and
privacy.
8.1.2 eHealth/AAL Use Case Challenges
This Section shows the challenges elicited from the eHealth/AAL use cases presented in Section 3 of
deliverable D1.1.1 [4]. In particular, the following three main challenges were identified:
1) Device authentication of care givers device in the AAL Efficient Care Coordination use case.
Without proper authentication of the devices used by the actors (in particular, the care givers) in this use case, the system is exposed to several impersonation threats jeopardising the
protection of the high sensitive data. It is especially challenging to authenticate the device of
October 27, 2014
76
Deliverable D1.4.1
the field representative (care giver) when the device actually belongs to a third party service
provider, such as, e.g., an Ambulant Care Service Provider, or a Hospital.
2) Privacy of Access Policies in the AAL Efficient Care Coordination use case. As mentioned in
the description of the use case, the subset of the Patient data provided to the Care Giver is
determined based on a number of policies stored at the Care Coordinator premises. Therefore, responsible management of those policies is required in order to avoid reckless leakages of sensitive private data.
While traditional policy-based authorisation systems worked well in the past, where access
control was enforced by a trusted party, the paradigm falls short in the setting of cloud
computing. The reason is that cloud computing presumes the outsourcing of authentication
and access control to an untrusted cloud by design. The main challenge is to prevent any
leakage of security-critical information, as the disclosure of privacy-sensitive data can do
considerable harm.
For example, let us assume a policy stating “grant all oncologists access to patient Y’s encrypted health record” stored in plaintext. Then, whenever a representative is successfully
identified as an oncologist, they will have access to the encrypted record, leaking the very
sensitive fact, that Y is a cancer patient, to the policy storage. In short, having access to policies in clear will leak information (be it explicitly or implicitly).
We therefore aim to design an identification protocol that combines the tasks of credentialbased authentication of the user (assigned with a set of attributes) with a cloud enforcing a
policy such that no information about the attributes and the policy is leaked except a single
validity bit.
3) Processing encrypted information for both eHealth/AAL use cases. As an additional security
layer, the patients’ sensitive e-health related information should be stored in an encrypted
way. Yet, such encryption should be performed in a fashion that still allows certain operations over the encrypted domain, such as searching. The main challenge here consists of developing an efficient and effective searchable encryption technique assisting in the protection of the sensitive information handled within the eHealth/AAL use case, while permitting
useful search operations.
Current searchable encryption solutions either fall short in efficiency or in privacy leakage.
Regarding the latter shortcoming, a secure and robust searchable encryption scheme needs
to prevent privacy leakage from a number of different perspectives, namely: index privacy,
search pattern privacy, trapdoors privacy, keywords privacy, etc. Moreover, besides efficiency and security-related features, there are additional desirable properties such as: allowing
open dictionaries, fuzzy keywords, wildcards, keywords frequency, etc.
In the context of AU2EU we will analyse these properties to determine which ones are the
most relevant and crucial for a novel solution that includes such selected features.
Appropriate and efficient handling of these three challenges is a must in order to safeguard the security and privacy of sensitive users’ information managed within the context of the eHealth/AAL
use cases.
8.1.3 PACS Use Case Challenges
In Collaborative PACS consent management is very important. Inside a hospital patient consent was
sought for using personal data inside the hospital. Once data sharing and collaboration between
hospitals become part of the picture, patient’s consent will become relevant in policy enforcement
and consequently in the authentication and authorisation of users across organisations.
October 27, 2014
77
Deliverable D1.4.1
The Collaborative PACS use case together with the associated security and privacy requirements
raises challenges from an authorisation point of view where data sensitivity and geolocation solutions can complement classic authorisation solutions:


The sensitivity of data depends on the data and may be dynamic, e.g. subject to changing
legislation, policy, applications or even user demand. Given that the data sensitivity level determines how this data may be used, its management is important.
Geolocation is an important parameter to control access to services and data. Reasons for
geolocation control include business, regulatory and aforementioned data sensitivity. With
mobile users and devices remotely accessing services being the standard, geolocation control should be part of the access control and authorisation functionality.
Furthermore the data can reside partially in the cloud; partially in the hospital, which leads to a hybrid cloud solution. The system should support policies that specify geographical boundaries for the
storage and traffic of data.
8.1.4 Translational Research Use Case Challenges
A Demilitarised Zone (DMZ) is for temporarily data storage and is separated into landing zones. Each
organisation is assigned a landing zone and uploads its data (anonymised by themselves) into its
DMZ landing zone. The presence of multiple actors and landing zone separation necessitates authentication and authorisation mechanisms to protect data temporarily stored in the landing zones. Similar security mechanisms are needed when the anonymised data is downloaded by data stewards
from the DMZ and checked for proper anonymisation.
Finally, access to sensitive anonymised medical data from “globally accessible shared translational
research data” is usually protected by access control policies, which specify which parties may access
information and under what conditions. If the information is confined within a single, trusted system, policy enforcement can be achieved using traditional enforcement mechanisms. When information needs to be disclosed across different organisational and jurisdictional domains (e.g. Research Institutes and University Medical Centres that host biostatisticians and researchers), however, guaranteeing policy enforcement becomes more challenging. Therefore attribute and data sensitivity based policy enforcement techniques play an important role in data protection.
Translational research implies the usage of various domain applications which provide access to distinct types of resources (e.g. images, databases) using distinct types of permissions (e.g. select from
databases, view on images). That is why translational research needs centralised authentication and
authorisation solutions that provide consistent and non-conflicting security mechanisms across domains. The latter leads to more secure collaborations because it provides more efficient compliance
with agreed collaboration authorisation policies.
8.1.5 DNA Data Management in Clinical Trials Use Case Challenges
DNA information is highly sensitive, since DNA sequences can reveal risk of or predisposition to certain diseases, provide information about ancestry, and are unique identifiers of human beings.
Therefore, the DNA clinical trial use case as well as DNA data management overall face a number of
challenges:

Since DNA data is privacy-sensitive data, ensuring proper initial management of the sequenced data, i.e. encoding and pseudoID generation, is very important.
October 27, 2014
78



Deliverable D1.4.1
Furthermore, enabling a rich set of operations on encoded DNA data can lead to a set of encoded DNA sequences associated with the same DNA sequence. The set of operations and
that of encoded sequences can grow over time.
Due to the fact that DNA contains genetic information, security guarantees for DNA information should be much stronger than for other sensitive information, as the information
remains relevant beyond after the lifetime of a person, the DNA data contains significant
amount of information about DNA of any descendants.
From the authorisation point of view, regulation of access to only people authorised to perform analysis of the encoded DNA information is another requirement that needs to be supported by the system with policy enforcement mechanisms.
Human DNA genome is composed of roughly 3.2x109 nucleotides with around 30000 genes [17]. This
amount of data requires substantial computing and storage resources for processing and analysis.
When this amount of information has to be analysed in a privacy-preserving way, efficiency becomes
a challenging issue.
8.2 Challenges from a Legal and Business Perspective
There is an increased need for secure and trustworthy cross border online services to cater for the
increasing mobility and flexibility of citizens and businesses, and for the technological transition to
digital economies and administrations.
In the following section we have identified some problems that concern the seamless and secure
cross border use of electronic authentication and electronic authorisation.
8.2.1 Legal Challenges
Electronic authentication and authorisation services (also referred to as electronic Identification,
Authentication, Signature and electronic related trust services in the proposal for a Regulation of the
European Parliament and of the Council on electronic identification and trust services for electronic
transactions in the internal market) are pre-requisites for a wide range of electronic interactions
such as e-health services, e-banking and e-government. Although, a regulatory framework for electronic signatures has been developed at the EU level, there is no specific framework for mutual
recognition and acceptance of electronic authentication and electronic authorisation.
8.2.1.1 Market Fragmentation
According to CROBIES [18], the European harmonisation brought about by the e-signatures directive
is imperfect and incomplete, resulting in market fragmentation. Some of the main problems identified, include different interpretations of the current directives, which leads to cross-border interoperability problems. Furthermore outdated standards lead to a highly complex standardisation
framework, and vague directives on supervision obligations lead to a lack of trust as the effectiveness of supervision regimes is unclear.
8.2.1.2 Interoperability Challenges
The use of electronic identification is hampered by the adoption of different technological solutions
which leads to interoperability issues. This can also lead to difficulties in exchanging electronically
signed documents across organisations, as well as across member states/countries with differing
regulations and standards.
8.2.1.3 Reliability Check
There is no framework of reference for determining the reliability of an entity that issued an electronic identification, the legal certainty on the cross-border use of such electronic identification and
a clear liability for the correctness of the ID when it is used as electronic representation of a person.
October 27, 2014
79
Deliverable D1.4.1
It is currently almost impossible for users to employ a single electronic identification for accessing
cross-border online services. Additionally, electronic identification tokens can be issued by private or
public sector parties and may be issued for a specific purpose, such as eBanking, eHealth etc. The
absence of a general framework for electronic identification and of an authentication framework for
recognition and acceptance of an electronic identification token outside its context present liability
and data protection challenges.
8.2.1.4 High Costs for Cross-Border Legal Compliance
The lack of a common European framework can lead to an incurring of high costs. Since trust service
providers have to ensure technical compliance with the rules of the country of destination, in order
to obtain guarantees with respect to trustworthiness of foreign electronic identification, authentication and signature tools.
8.2.2 Legal Challenges Specific to the eHealth/AAL Pilot Use Cases
Some specific legal challenges have been identified for the eHealth/AAL use cases (described in section 3 of deliverable D1.1.1 [4]):
1. Fragmentation in the way data protection is implemented across the European Union (refer
to section 8.2.1.1 above).
2. Absence of a well-defined regulatory framework for eAuthorisation as well as eAuthentication.
3. Legal uncertainty regarding allocation of liability between the participants in the eAuthenticated and eAuthorised transactions (refer to section 8.2.1.3 above). In the eHealth/AAL use
cases, it is difficult to allocate liability between the various service providers since the service providers are not registered with the DRK.
4. Widespread public perception that there are significant risks for the protection of individuals associated notably with online activity. This might pose a considerable challenge to convince AAL users to use electronic identification tools and systems.
5. Differences in the implementation and application of Directive 95/46/EC [12] leading to differences in levels of protection of the rights and freedoms of individuals, notably to the
right to the protection of personal data.
8.2.3 Outlook
A comprehensive legal and business analysis of all AU2EU cross-domain collaboration use cases and
pilots with respect to the applicability of the joint eAuthentication and eAuthorisation Reference
Architecture developed in this document can be found in deliverable D1.3.1 (Business & Legal Analysis) [6].
October 27, 2014
80
Deliverable D1.4.1
9 Extensions to the joint eAuthentication and eAuthorisation
Framework
This section outlines and motivates the research opportunities addressed within the context of the
AU2EU project, that is to say, it addresses the extensions and advancements with regards to the
current state of the art (see Figure 19)(developed in detail in WP4). Each subsection here is actually
associated with each of the four tasks comprised by WP4 (T4.1, T4.2, T4.3 and T4.4), respectively.
As in the case of the aforementioned WP4 tasks, these research opportunities will be also focused
on those security, privacy and trust aspects determining the successful deployment, functioning and
acceptance of the eAuthentication and eAuthorisation framework in a real environment.
Figure 19 Extensions to the Joint eAuthentication and eAuthorisation Framework
9.1 Assurance of Claims
Assurance of claims refers to the confidence one can have in the claim being made. For example, if a
claim is made by an entity A to an entity B, the assurance is analysed in terms of how strongly B can
believe the claim that has been made by A. There are several factors that affect the level of assurance, and that can be achieved on a claim. They depend on the following: (a) the trust that can be
associated with the entity who is making the claim, (b) the channel(s) through which the claim is
made, (c) the content of the claim (d) the context in which the claim is made. For instance, in the
case of (a) if two entities are mutually suspicious, the use of trusted third parties vouching for the
claim made by an entity helps to increase the level of assurance. (E.g. how much the recipient trusts
the entity that is vouching for the claim). In the case of (b), securing the channel by using cryptographic techniques will protect the claim and the entity vouching for the claim, and offers better
October 27, 2014
81
Deliverable D1.4.1
assurance. (E.g. trust in the un-forgeability of the signature scheme used by the vouching entity).
Case (c) considers the relevance of the claim to the decision in question (e.g. how well the attributes
in the claim itself match with what the recipient wants to determine), and (d) refers to the context
attributes such as location and time associated with the claim which can increase the assurance level. Assurance also depends on the trust in the process that has been used to make the claims. E.g.
using a hardware trusted computing base protected against tampering to create the certified claims
increases the level of assurance. These aspects are being addressed in Task 4.1.
9.2 Policy Enforcement
Based on the use case objectives, medical records of patients need to be shared among a number of
collaborating healthcare parties. When sensitive data is shared across different domains, in addition
to the deployment of traditional access policy enforcement systems, three problems should be addressed:
i)
how to manage possible conflicts of policies between domains and how to enforce the
policy efficiently,
ii)
how to enhance the granularity level of the authorisation to data, based on its sensitivity
and using subjects attributes, and
iii)
how to ensure that the access policy is enforced correctly when the level of trust in different domains is not the same.
In Task 4.2 we address these problems by proposing an architecture and appropriate techniques. We
extend traditional policy enforcement systems with
i)
cross-domain policy management techniques to address the first problem,
ii)
data sensitivity annotations and geolocation control to address the second problem, and
iii)
cryptographic policy enforcement techniques to address the third problem.
9.3 Trust Indicators
A trustworthy environment is essential for security, and requires that all its parts be trustable. This
includes a reliable infrastructure that resists malicious attacks, and honest behaviour by the participants. There are different aspects of trustworthiness and different levels of it, depending on the
participants’ needs and aims. The objective of this task is to establish a set of trust indicators applicable to useful, practical situations and scenarios, such as in web-based scenarios and in cloud-based
services.
9.4 Processing Encrypted Information
Bearing in mind the high sensitivity of private information to be handled and processed by the eAuthentication and eAuthorisation framework, an appropriate and efficient protection of such data is
mandatory in order to guarantee the success of the platform. One way of achieving such protection
is the encryption of sensitive data. However, within the context of the AU2EU project we will investigate how to apply (and develop) novel cryptographic techniques and solutions to protect (encrypt)
the users’ information in such a fashion that it is still possible to perform certain useful operations
over the encrypted domain.
To this end, we will analyse how modern DNA management and code-based cryptography models
can effectively help to protect DNA sequences handled by the framework while permitting a number
of privacy-preserving operations on the DNA data.
October 27, 2014
82
Deliverable D1.4.1
Moreover, a thorough analysis of the searchable encryption field will also be performed in order to
determine which solution will better accommodate the extracted requirements and challenges identified for the eAuthentication and eAuthorisation framework.
Finally, some advanced solutions to deal with encrypted databases, as well as to achieve certain
privacy-preserving correlation over the encrypted data will be studied in depth as they might result
extremely useful for the pursued aims and goals of the eAuthentication and eAuthorisation framework.
October 27, 2014
83
Deliverable D1.4.1
10 Conclusion
A joint eAuthentication and eAuthorisation framework has been designed that supports privacypreserving authentication and authorisation and secure data processing thus enabling trusted crossdomain collaborations and secure and efficient delivery of services in cloud-based and other deployments.
In order to achieve this goal, an analysis of the security and privacy requirements of the AU2EU use
cases and Pilots has been given, the necessary eAuthentication and eAuthorisation functionalities of
the use cases have been derived, and the joint reference architecture for eAuthentication and eAuthorisation has been laid out and related to existing architectures.
Furthermore, challenges for the design and deployment of an integrated eAuthentication and eAuthorisation framework by large dynamic cross-domain and jurisdictional collaborations have been
investigated; extensions and advancements of the AU2EU reference framework to be addressed
within the research activities of the project have been outlined.
10.1 Outlook
The consolidated reference architecture for eAuthentication and eAuthorisation described in this
document is a core element and milestone of the AU2EU project and a major objective of WP1,
building the foundation for all subsequent AU2EU work-packages.
This reference architecture will be refined and instantiated as integrated privacy-preserving eAuthentication and eAuthorisation platform within the scope of WP2 and WP3.
Followed by its practical adoption and deployment in two real-life pilots within WP5, its usability and
efficiency is evaluated in WP6.
Within WP4, the joint reference architecture will be extended by innovative solutions and advanced
functionalities to meet the security and privacy challenges supporting trust in large-scale distributed
collaborative systems. In WP7 the project results built on the consolidated reference architecture for
eAuthentication and eAuthorisation will be disseminated via standardisation bodies.
It is envisioned that the consolidated architecture will not only serve to fulfil the AU2EU project
goals but also will be adopted beyond the scope of this project enabling trustworthy cloud-services
and complex collaboration scenarios thereby generating opportunities for significant business value
and new revenue streams.
October 27, 2014
84
Deliverable D1.4.1
Glossary
Acronym
AA
AAL
ABAC
Full Name/Description
Attribute Authority
Ambient Assisted Living
Attribute-Based Access Control
Attribute-based access control defines a new access control paradigm whereby access rights are granted to users through the use of policies which combine attributes
together. The policies can use any type of attributes (user attributes, resource attributes, etc.). Attributes can be compared to static values or to one another thus
enabling relation-based access control.
ABC4Trust
Attribute-Based Credentials for Trust
ABCE
Attribute-Based Credentials Engine
ABCs
Attribute-Based Credentials
ACVO
Australian Chief Veterinary Officer
AHA
Animal Health Australia
AtP
Attribute Provider
AUSVETPLAN Australian Veterinary Emergency Plan
AuthN
Authentication
AuthS
Authorisation
BIR
Biosecurity Incident Response
BTG
Break-the-Glass
A term used to describe an access control policy that allows users who would not
normally have access to a resource, to gain access themselves by “breaking the
glass” in the full knowledge that they will have to answer for their actions later to
their management
CCEAD
Consultative Committee on Emergency Animal Disease
CCP
CSIRO Collaboration Platform
CIS
Credential Issuing Service
The service that issues digitally signed attribute assertions, provided by an attribute
authority.
CP
Claims Provider
CR
Customer Registration
CRUD
Create, Read, Update and Delete
CSIRO
Commonwealth Scientific and Industrial Research Organisation
CSO
CCEAD Secretariat Officer
CVO
Chief Veterinary Officer
CVO-A
Chief Veterinary Officer
of the affected state
CVS
Credential Validation Service
The service of validating digitally signed attribute assertions and determining which
are trusted and which are not, and mapping remotely issued trusted attributes into
locally valid ones.
DMZ
Demilitarised Zone
DNA
Deoxyribonucleic Acid Data Management in Clinical Trials
DRK
Deutsches Rotes Kreuz (German Red Cross)
EAD
Emergency Animal Disease
EADRA
Emergency Animal Disease Response Agreement
October 27, 2014
85
EADRP
ECC
eID
HMI
HR
IBAC
ID
IdP
LDAP
LIS
NFC
NMG
PACS
PAP
PDP
PEP
PIP
PKI
RBAC
REST
RFID
RP
SAML
SSO
SoA
SOAP
SP
Deliverable D1.4.1
Emergency Animal Disease Response Plan
Efficient Care Coordination
Electronic Identity
Human Machine Interface
Human Resource
Identity-Based Access Control
IBAC is access control based on the identity of the user (typically relayed as a characteristic of the process acting on behalf of that user) where access authorisations to
specific objects are assigned based on user identity.
Identity
Identity Provider
An authoritative source of subject attributes (i.e. an AA) that is also capable of authenticating subjects prior to issuing credentials.
Lightweight Directory Access Protocol
Linking Identity Selector
Near Field Communication
National Management Group
Picture Archiving and Communication System
Policy Administration Point
Point which manages access authorisation policies
Policy Decision Point
The (application independent) part of an access control system that can answer access control requests with a granted or denied decision.
Policy Enforcement Point
The (application dependent) part of an access control system that is responsible for
enforcing the decisions returned by the PDP.
Policy Information Point
Entity that acts as a source of attribute values
Public Key Infrastructure
A highly scalable infrastructure, based on public key cryptography, which allows
subjects to authenticate to relying parties based on their mutual trust in Public Key
Certification.
Role-Based Access Control
Permissions are defined in terms of roles that are assigned to users and privileges
that are assigned to roles.
Representational State Transfer
An abstraction of the architecture of the World Wide Web
Radio Frequency Identification
Relying Party
Security Assertion Markup Language
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
Single Sign-On
The process whereby a user can sequentially gain access to a number of computer
services by only providing his login credentials once to the first service he contacts.
Source of Authority
The ultimate authoritative source for an attribute. A trusted root for authorisation
purposes.
Simple Object Access Protocol
Service Provider
October 27, 2014
86
TAS3
TDL
TEE
TR
UIA
UA
XACML
ZXID
Deliverable D1.4.1
An entity which offers some kind of electronic service to users.
Trusted Architecture for Securely Shared Services
Trust in Digital Life
Trusted Execution Environment
Translational Research
User Identity Agent
User Agent
eXtensible Access Control Markup Language
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
ZXID is the Reference Implementation of the Core Security Architecture of TAS3.
October 27, 2014
87
Deliverable D1.4.1
Bibliography
[1] ABC4Trust Consortium, “H2.2 - ABC4Trust Architecture for Developers,” October 2013.
[Online].
Available:
https://abc4trust.eu/download/ABC4TrustH2.2_ABC4Trust_Architecture_for_Developers.pdf.
[2] “TAS3 Trusted Architecture for Securely Shared Services,” [Online]. Available:
http://vds1628.sivit.org/tas3/.
[3] “Architecture
serving
complex
Identity
Infrastructures,”
[Online].
Available:
http://www.trustindigitallife.eu/uploads/Architecture
serving
complex
Identity
Infrastructures.pdf. [Accessed 19 February 2014].
[4] J. Zic, B. Lange, T. Ignatenko, D. Pletea and P. Koster, “AU2EU, D1.1.1 - Detailed Description of
Use Cases,” http://au2eu.eu/, 2014.
[5] M. Johnstone, B. Lange, D. Gessner, D. Liu, J. Jang-Jaccard, T. Ignatenko, D. Pletea and D.
Vangjeli, “AU2EU, D1.2.1 - Requirements Specification,” http://au2eu.eu/, 2014.
[6] K. Ghorai, M. Kluitman, P. Ray and J. Smits, “AU2EU, D1.3.1 - Legal and Business Analysis
Document,” http://au2eu.eu/, 2014.
[7] J. Camenisch and A. Lysyanskaya, “A Signature Scheme with Efficient Protocols,” SCN 2002, pp.
268-289.
[8] IBM Research – Zurich, “Specification of the Identity Mixer Cryptographic Library,” January
2013. [Online]. Available: https://abc4trust.eu/idemix.
[9] IBM Research – Zurich, “IBM Identity Mixer cryptographic library open source implementation,”
[Online]. Available: https://abc4trust.eu/idemix.
[10] S. Brands, “Rethinking Public Key Infrastructures and Digital Certificates – Building in Privacy,”
MIT Press, August 2000.
[11] C. Paquin and G. Zaverucha, “ U-Prove Cryptographic Specification V1.1 (Revision 3),”
December
2013.
[Online].
Available:
http://research.microsoft.com/apps/pubs/default.aspx?id=166969.
[12] European Parliament, “DIRECTIVE 95/46/EC OF THE EUROPEAN PARLIAMENT AND OF THE
COUNCIL of 24 October 1995 on the protection of individuals with regard to the processing of
personal data and on the free movement of such data,” Official Journal L 281/31, p. 31,
November 1995.
[13] OASIS, “eXtensible Access Control Markup Language (XACML) Version 3.0,” January 2013.
[Online]. Available: http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.pdf.
[14] OASIS, “XACML v3.0 Privacy Policy Profile,” March 2010. [Online]. Available: http://docs.oasisopen.org/xacml/3.0/xacml-3.0-privacy-v1-spec-cd-03-en.pdf.
[15] U. Mbanaso, G. Cooper, D. Chadwick and S. Proctor, “Privacy Preserving Trust Authorization
Framework
Using
XACML,”
August
2006.
[Online].
Available:
http://kar.kent.ac.uk/14477/1/Privacy_Preserving_Trust_Authorization_Framework_Using_XA
CML.pdf.
[16] C. A. Ardagna, S. D. C. d. Vimercat, S. Paraboschi, E. Pedrini and P. Samarati, “An XACML-Based
Privacy-Centered Access Control System,” November 2009. [Online]. Available:
http://spdp.di.unimi.it/papers/wisg09-ADPPS.pdf.
[17] National Human Genome Research Institute, “The Human Genome Project,” 2014. [Online].
Available: http://www.genome.gov.
[18] European Commission, “Digital Agenda for Europe - CROBIES: Study on Cross-Border
October 27, 2014
88
Deliverable D1.4.1
Interoperability of e-Signatures 2010,” [Online]. Available: https://ec.europa.eu/digitalagenda/en/news/crobies-study-cross-border-interoperability-esignatures-2010.
[19] ABC4Trust Consortium, “D2.2 - Architecture for Attribute-based Credential Technologies,” June
2014. [Online]. Available: http://abc4trust.eu/download/Deliverable_D2.2.pdf.
[20] “TDL-SRA-version-2,” [Online]. Available: http://www.trustindigitallife.eu/uploads/TDL-SRAversion-2.pdf. [Accessed 19 February 2014].
October 27, 2014
89
A. Appendix:
Deliverable D1.4.1
ABC4Trust Reference Architecture Building Blocks
We briefly describe the ABC4Trust protocol. We refer to [19] for a complete description. The first
two paragraphs of this description are a slight modification of paragraphs from [1].
The goal of ABC4Trust is to address the federation and interchangeability of technologies that support trustworthy yet privacy-preserving Attribute-based Credentials (ABC). Towards this goal,
ABC4Trust provides a unified architecture for privacy-ABC systems to allow comparing their respective features and combining them on common platforms. The main contribution of this architecture
is the specification of the data artifacts exchanged between the implicated entities (see Figure 20), in
such a way that the underlying differences of concrete Privacy-ABC implementations are abstracted
away through the definition of formats that can convey information independently from the mechanism-specific cryptographic data. It also defines all technology-agnostic components and corresponding APIs a system needs to implement in order to perform the corresponding operations.
Issuer
Revocation Authority
credential revocation
revocation info retrieval
User
credential issuance
revocation info retrieval,
credential revocation
token presentation
Inspector
Verifier
token inspection
Figure 20 Entities and Interactions Diagram of ABC4Trust
The ABC4Trust architecture uses a layered approach, where related functionalities are grouped into
a common layer that provides simple interfaces towards other layers and components. Figure 21
shows an overview of the components for the User's side. The ABCE layer contains all technologyagnostic methods and components for a Privacy-ABC system. That is, it contains, e.g., the methods
to parse an obtained presentation policy, perform the selection of applicable credentials for a given
policy or to trigger the mechanism-specific generation or verification of the cryptographic evidence.
The ABCE layer is invoked by the application-layer and calls out the CryptoEngine to obtain the
mechanism-specific cryptographic data. To perform their tasks, the internal components can also
make use of other external components such as the KeyManager, RevocationProxy, or IdentitySelection.
October 27, 2014
90
Deliverable D1.4.1
Figure 21 Overview of the ABC4Trust Architecture on the User Side
ABC4Trust provides the specification in XML notation for data artifacts exchanged during the issuance, presentation, revocation, and inspection of privacy-ABCs. The specification separates the
mechanism-independent information conveyed by the artifacts from the opaque mechanism-specific
cryptographic data. In the following we recall the specification of these data artifacts.
 Credential
The credential description describes the contents of a credential. Users employ the XML scheme
abc:CredentialDescription in [1] to store the credential contents.
 Setup
In the setup phase, the issuer generates his parameters and communicates them in an XML
scheme abc:IssuerParameters.
The revocation authority employs abc:RevocationAuthorityParameters.
The inspector employs abc:InspectorPublicKey.
 Presentation of a token
The process of the presentation of a token is triggered when the application on the User’s side
contacts a Verifier to request access to a resource (Figure 22, step 1). Having received the request, the Verifier responds with one or more presentation policies (Figure 22, step 2.a). The
XML scheme abc:PresentationPolicyAlternatives in [1] describes the contents of
the presentation policies. In some cases, the user has more than one set of credentials that fulfill the presentation policies. The ABCE reports those alternatives via the XML scheme
abc:PresentationArguments in [1]. The choice is reported to the ABCE through
abc:UIPresentationReturn in [1]. Then the user outputs the presentation token (Figure
22, step 3.a), consisting of the presentation token description and the crypto evidence. The XML
scheme abc:PresentationToken in [1] describes the contents of this message.
October 27, 2014
91
Deliverable D1.4.1
Figure 22 Presentation of a Token
 Issuance
To start an issuance process the User first authenticates toward the Issuer (Figure 23, step 1).
How the authentication is done, is outside of the scope of the Privacy-ABC architecture. After,
or together, with the authentication, the User sends a credential request which specifies the
credential type she wants to obtain (Figure 23, step 2). The subsequent issuance protocol can
come in different ways. The XML scheme abc:IssuanceMessage in [1] is used as a wrapper for all the messages that are exchanged in the issuance protocol. The first message of the
issuance protocol contains the XML scheme abc:IssuancePolicy. In the simple case, the
issuance policy contains only the credential specification and the issuer parameters, and the
rest of the protocol depends on the concrete cryptographic mechanism utilized. In the complex
case, the issuance of a credential requires the presentation of previously obtained credentials,
which are specified in abc:IssuancePolicy. In this case, as for the presentation of a token, there may be several alternatives, which are reported by the ABCE through the XML
scheme abc:UiIssuanceArguments. The alternative chosen is reported to the ABCE by
using the XML scheme abc:UiIssuanceReturn. After that, the second message of the
protocol contains the XML scheme abc:IssuanceToken. The subsequent messages of the
protocol, which are also wrapped in abc:IssuanceMessage, depend on the underlying
cryptographic mechanism.
 Revocation
The exact details of how and when the non-revocation evidence is created and updated vary
greatly among the different revocation mechanisms. ABC4Trust therefore simply defines an artifact abc:RevocationMessage that acts as a wrapper for a message in a (possibly multilegged) evidence creation or update protocol. A Revocation Authority regularly publishes the
most recent revocation information, allowing Users to prove and Verifiers to ensure that the
credentials used to generate a presentation token have not been revoked. Contrary to the Revocation Authority parameters, the revocation information changes over time, e.g., at regular
time intervals, or whenever a new credential is revoked. The Revocation Authority publishes the
revocation information using the XML scheme abc:RevocationInformation.
October 27, 2014
92
Deliverable D1.4.1
Figure 23 Issuance of a Credential
October 27, 2014
93
Deliverable D1.4.1
B. Appendix:
TAS3 Reference Architecture Building Blocks
B.1. Appendix:
Introduction
The TAS3 (Trusted Architecture for Securely Shared Services) [2] proposes an Integrated Project that
will develop and implement an architecture with trusted services to manage and process distributed
personal information across heterogeneous, context dependent and continuously changing systems.
The personal information that will be processed and managed can consist of any type of information
that is owned by or refers to people. The proposed architecture therefore has to be generic and
cross-domain applicable.
The trust and privacy enhancing services offered by TAS3 include:
-
-
-
authorisation services, whose purpose is to answer the question "is this subject authorised
to access this resource in this way"
authentication services, whose purpose is to validate that the communicating party is indeed
the subject who they claim to be
privacy preserving services whose purpose is to provide pseudonymous identities for users
and minimise the cross linking of identities
trust negotiation services whose purpose is to determine if the remote communicating party
is trust-worthy enough to start a dialogue
secure business process management services whose purpose is to ensure that business
processes operate securely, and can be dynamically modified securely
delegation services, whose purpose is to delegate credentials from a delegator to a delegate
discovery services, whose purpose is to inform clients where particular services can be found
trusted registries, whose purpose is to keep a directory of all services in the trust network
who are known to provide services conforming to the TAS specifications
attribute authorities whose purpose is to assert that particular users have particular attributes
identity management services, which are a combination of an authentication service and an
attribute authority
secure repository services, whose purpose is to store users’ personal data securely and give
users complete control over who should access their data and how they should handle it
once access to it is given
trust and reputation services, whose purpose is to answer the question "how trustworthy is
this actor (service provider or end user)"
secure audit services whose purpose is to keep a tamper resistant record of transactions
within the trust network so that legally admissible evidence can be obtained in the case of a
dispute.
on-line compliance testing services whose purpose is to ensure that all the services in a trust
network comply with their published specifications and policies.
B.1.1. Appendix:
Building Blocks
The main components of the TAS3 architecture are presented in Figure 24 below.
October 27, 2014
94
Deliverable D1.4.1
Figure 24 TAS3 Main Components
B.1.2. Appendix:
The Payload Application
This group is not part of the TAS3 scope but it is the entry point for the user. It is composed of the
followings part:
 Front End
This GUI is the entry point for the user in order to interact with the system and represents
services that the user can use. (This GUI is dependent on the user context and has to be
generated in the context of the application)
 Business Process Engine
The Business Process engine is in charge to orchestrate the front end and web services interaction in order to realise a required sequence.
 Web Services
Web services represent the service offered by the infrastructure in order to provide data or
services to the user.
B.1.3. Appendix:
TAS3 User Tools
This second group of components is in charge of providing information and management of the user’s on her personal information. This group is composed by

The User Audit Dashboard
This GUI is in charge of providing information to the user about the usage of their personal
information by the services. The user could also interact with this GUI in order to give consent to an access to a service.
October 27, 2014
95


Deliverable D1.4.1
The Policy Editor & Consent Management
This element enables the user to select (consent) policies.
The Delegation Settings
This element manages the delegation realised for the user.
B.1.4. Appendix:
The Core TAS3 Infrastructure
This group of component is in charge to manage identities and trust
 Identity Provider
The identity provider is the element that interacts with the user to authenticate. At the end
of the authentication, the Identity Provider returns a SSO token which contains certified
identity attributes of the user.
 Identity Aggregator
The Identity Aggregator combines attributes coming from different IdPs.
 Trust & Reputation
Policy based scoring of trust which may use:
o Reputation (user feedback)
o Credentials (certificates)
o Service Performance (KPIs, compliance tests)
Information is coming from the audit event bus (this bus is an object which collect all
the information coming from the different elements of the system) about all the
services and the users of the system.
B.1.5. Appendix:
The Core TAS3 Infrastructure Backchannel
 Authorisation
This part will be developed later.
 Delegation Service
This service allows a user to authorise another user to use the front end or web services on
their behalf. It is also possible to invite users.
Delegation could be also realised when a service acts on behalf of a user. In this case, ID
Mapper is used.
 ID Mapper
This service is used to translate a User Id Mapper bootstrap token (given by the IdP during
the authentication phase) to a token usable by the web service to be called.
 Ontology Handler
In case of RBAC, roles in one organisation may not be the same as in another organisation.
The ontology will allow the roles to be aligned with each other so as to be able to enforce
authorisation based on the privileges assigned to the mapped role.
 Credentials & Policies Negotiator
Iterative trust building by sharing of credentials.
 Discovery Registry
The purpose of this service is to inform clients where particular services can be found.
Audit & Monitoring
B.1.6. Appendix:
Audit & Monitoring
TAS3 provides an event bus in order to monitor and audit all the events published by the different
components of the platform. Information coming from an event can be evaluated in order to provide
trust scores and feedbacks for users and service compositions.
October 27, 2014
96
B.2. Appendix:
Deliverable D1.4.1
Authorisation Infrastructure
The detail of the authorisation infrastructure is presented in Figure 25 below:
Figure 25 TAS3 Authorisation Infrastructure
The authentication infrastructure resembles to the XACML architecture. In detail, it consists of the
following components:
PEP: The PEP (Policy Enforcement Point) intercepts requests coming from subjects. It enforces access
decisions coming from the PDP for access requests on a certain resource.
In TAS3, 4 kinds of PEP are put in place:
 The PEPOut-requester: This PEP is used to check whether data can be submitted to the Web
Service, or whether the call can be made at all. The PEP will contact organisation’s Master
PDP to obtain a policy decision.
 The PEPIn-responder: This PEP is used to check whether data or call can be accepted by the
Web Service. It also records what obligations and policies the Service Requester pledge to
honour. These will be checked later by PEPOut-Rs.
 The PEPOut-responder: This PEP is used to filter the data on the responder side and to perform any responder obligations attached to the data. In particular, the pledges recorded by
PEPIn-Rs are checked against obligations and sticky policies attached to the data, and if
found unsatisfiable either the data is filtered out or the operation is aborted. If no data can
be returned, an error response will still be returned.
 The PEPIn-requester: This PEP is used to extract and perform or record any obligations attached to the response for later performance evaluation.
PDP: The Policy Decision Point will return a “Permit” or “Deny” to the PEP after validating the authorisation. In the TAS3 context, a Master PDP is in charge of answering to the PEP. In order to valiOctober 27, 2014
97
Deliverable D1.4.1
date the authorisation, it must contact a list of PDPs in the system and consolidate their responses.
The other PDPs are:
 The Trust Network PDP
 The Organisation PDP
 The User PDP
 The Trust PDP
Obligation service: Obligations are actions which must be executed “before”, “together with” or
“after” a decision. With this mechanism, we could realise actions like found additional attributes,
modified credential, etc. before sending the request to the second organisation or on the second
organisation side.
CIS: (Credential Issuing Service). The CIS provides credentials for the user. In the first part of this
appendix this component is named “core TAS3 infrastructure” (IdP aggregator).
CVS: The Credential Validation Service is a sub system that helps the PEP to establish the validity of
the credentials and attributes it is about to pass to the Master PDP. This component integrates the
ontology in order to realise the attributes mapping.
B.3. Appendix:
Flow
Figure 26 TAS3 Authorisation Workflow
1. A client application wishing to call some service in another organisation, initiates the call.
2. The Client PEP will enforce outbound authorisation decisions. To be able to do this, it first
engages in Trust and Privacy Negotiation, which is a discovery process, and then forwards
the request to the web services stack.
3. Web services Stack (the "Stack") will compose a request message including the identity tokens that are needed and signs the message. It then sends the message to the Stack on the
service side.
October 27, 2014
98
Deliverable D1.4.1
4. The service Stack will authenticate the sending Stack and verify its digital signature. The acceptance of the message will depend on the degree of trust in the signing party, which was
established during the Trust and Privacy Negotiation.
5. The service inbound PEP will consult the Master PDP to determine if the service request
should be allowed to go forward.
6. The inbound PEP will pass the request to the payload service, which will reply.
7. The outbound PEP of the Service will validate that the data can be released and attach obligations.
8. The Stack at the service correlates the response to the request, signs it and sends the response.
9. The client Stack receives the response, checks its correlation with the request, and verifies
the signatures in the response.
10. The client inbound PEP checks that the response is authorised and complies with the obligations that were received.
11. The payload message is passed to the Client Application.
B.4. Appendix:
Standard and Implementation
A reference implementation of the TAS3 component is provided under the “ZXID” name
(http://www.zxid.org/) under the Apache2 license. The compliance between the description on the
TAS3 document and the implementation must be checked.
The standards used for the implementation are: SAML 2.0, Liberty ID-WSF 2.0, and XACML 2.0
stacks.
October 27, 2014
99
C. Appendix:
Deliverable D1.4.1
TDL Reference Architecture Building Blocks
Figure 27 presents the software development context in which the TDL architecture (red rectangle)
is used [20]. The TDL architecture [3] contains three building blocks: Data Lifecycle management,
Platform & Service integrity and Trusted Stack. Next the functionalities of these building blocks are
listed.
Figure 27 Overview of TDL
The building blocks (depicted in Figure 28) and their functionalities are:
 Data Lifecycle management
o Leveraging existing technologies and filling in gaps with missing technology building
blocks, technologies from secure authentication, access control, secure storage and
revisions management to data archiving and data termination;
o User-controlled management of identities and identifiers;
o Termination of identifiers;
o Provides consistent (single) user interface for access and management of identities
and identifiers;
o Decomplexifies real information and technology for user authorisation;
o Enforces the minimum disclosure to application for performing transactions.
 Platform & Services Integrity
o Assists users to adjust policies & Requests user acknowledgment of policies, both using the User Interface;
o Monitors functions and provides auditing;
o Isolation of applications;
o Prevention of unauthorised modifications of applications;
o Remote attestation of the state of execution;
o Search on large scale encrypted data (without decryption);
October 27, 2014
100


Deliverable D1.4.1
o Cloud protection filter for black listed providers;
o Secure tunnel access to non-client certificate storage and access;
o Access key authorisation.
Trusted Stack
o Uses strong authentication of hardware, software, people and data;
o Provides improved auditability of events;
o Provides accountability (by auditability);
o Provides tools for people to manage their online reputation;
o Mapping of the trust model on legal systems and law protection;
o Evaluation of trust in distributed systems;
o Information system security for identity federation for heterogeneous domains;
o Disclosure of attributes on need to have basis;
o Claim based e-authentication;
o Connectivity Stork platform;
o Usable anonymising network.
Trusted Framework
o Claim Providers. (Identity Providers (IdP) manage core identity claims; Attribute Providers (AtP) manage extra claims)
 Issues claims after validating the entity (in claims-based architecture);
 IdP: Validates the online identity of the entity (e.g. user of the relying party),
which is trying to authenticate;
 IdP: Can provide different forms of authentication: from passwords to smart
card based authentication;
 Shares claims’ assertions about the entity with Relying Party (RP);
 Keeps information about people in their origin;
 Fetches the claims using secure and standardised protocols;
 Fetches the claims in real-time.
o Relying Party (RP)
 Consumes the claims;
 Validates the presented credentials;
 Authorises access to resources (using credentials).
o User Identity Agent (UIA)
 Makes decisions on which claims to share;
 Gathers and presents the required claims in a secure and privacy preserving
way (e.g. leveraging cryptographic keys of the user) to RP;
 Collects claims from claims providers (IdPs and AtPs);
 Allows user to intervene and stop unwanted sharing of claims.
October 27, 2014
101
Deliverable D1.4.1
Figure 28 TDL Architecture Overview
October 27, 2014
102
October 27, 2014
Deliverable D1.4.1
103

Reference Architecture for eAuthentication and

Transcription

Similar documents

Connecting Windows 8 to the Switch to the desktop - Crye

How to configure your email client

Internet of Things Security Implications v1.4

Steps for staying PCI DSS compliant

Identity Security Trends in the Mobile Era

J Armstrong, Surrey Police

LaserVault DMS10 Reference Guide Installation

How do I authorise a batch payment using the Offline Authorisation

What are we talking about?!? The online privacy landscape

Civil Liability Theories for Insufficient Security Authentication in