1. AAI for a Collaborative Data Infrastructure
EUDAT
AAI for a Collaborative Data Infrastructure
- Challenges and Approaches -
Mark van de Sanden, EUDAT
EGI H2020 workshop
Amsterdam, 5 December 2013

2. Outline Intro to EUDAT EUDAT Services 2 use case
EUDAT AAI requirements

3. The CDI concept Collaborative Data Infrastructure
User-focused functionality, data capture & transfer, VREs
Trust
Data Curation
Data Generators
Users
Data discovery & navigation, workflow creation, annotation, interpretability
Community Support Services
Persistent storage, identification, authenticity, workflow execution, mining
Common Data Services

4. Initially six research communities on Board
EPOS: European Plate Observatory System
CLARIN: Common Language Resources and Technology Infrastructure
ENES: Service for Climate Modelling in Europe
LifeWatch: Biodiversity Data and Observatories
VPH: The Virtual Physiological Human
INCF: International Neuroinformatics
All share common challenges:
Reference models and architectures
Persistent data identifiers
Metadata management
Distributed data sources
Data interoperability

5. Communities and Data Centers
Identifying basic requirements
Identify commonalities, common data services

6. What community users see …
Today
Community portal, single credential type
Community Layer
Community specific authentication, authorization & single sign-on
commutity data

7. What community users see …
Tomorrow
EUDAT portal, for non-affiliated users, many credential types
Various community portals, different credential types
common metadata exploration
common data stage-in and stage-out services
data services for the long tail data, also from citizen scientists
common replication services with access to distributed storage
Unified Authentication, Authorization & Single Sign-On
data
community data
commutity data
useful
Other
very

8. EUDAT Services services to come Metadata Catalogue AAI PID
Aggregated EUDAT metadata domain.
Data inventory
Network of trust among authentication and authorization actors
Identity
Integrity
Authenticity
Locations
Safe Replication
Data Staging
Simple Store
Data curation and access optimization
Various flavors
Dynamic replication to HPC workspace for processing
Researcher data store (simple upload, share and access)
Semantic Anno
checking & referencing
EUDAT Box
Dynamic Data
Workflow Engine
services
to come
dropbox-like service
easy sharing
local synching
immediate handling
executing WFs

9. VPH use case

10. DRIHM Bridge between citizen and community scientists
Community Domain
Specific Metadata
Describe
Citizens

11. Communities * 𝚷 𝛀 𝛀 𝚫 𝚿 * AuthN IdP A B C D AtP 1 2 3
eID
shib
OpenID
x.509
Identity credential conversion
Different types of
Identity Providers
AuthN
zoned credential conversion service
unique user Ids, project-wise mapped to
attribute based access control information 𝚷 𝛀 𝛀
consolidated credentials
AtP 1 2 3
Communities 𝚿 𝚫
Attribute Provider AuthZ
either community-managed or ( ) attributes provided by user’s home IdP are reused *

12. EUDAT AAI Requirements
Support different authentication methods (e.g. OpenID, OAuth, X.509, Shib, …)
Support fine grained access control – VO and Role approach does not work
A minimum set of semantically standardized attributes for user identification and access control
Communities retain control on authorization decisions
Attributes can be provided by Universities, Scientific institutes or Community organizations as IdP or AtP
Support different Access Methods (e.g. HTTP, GridFTP, Web Portals, Workflows)
Technics for bridging between community, Institute, NREN, e-Infrastructure providers (e.g. EGI, PRACE and EUDAT) and public/private (e.g. Helix Nebula, ..) domains
Need for broadly accepted use and data privacy policies (e.g CoC, LoA)

14. EUDAT AAI
SAML is used for authentication (possibly translated from OpenID) OAuth2 is used for delegation - internally, within the federation
XACML is used for access control policies. Communities retain ultimate decisions on authorizations, EUDAT enforces these authorization rules across the federation
An X.509 certificate with authorisation attributes is generated and managed internally and thus it is not exposed to or accessible by the user. Its purpose is threefold: (a) to ensure that non-HTTP services can be accessed (i.e., outside the OAuth delegation workflow), such as GridFTP and iRODS, and (b) to allow fine-grained authorisation, and (c) to allow command line access to services for expert users. In OAuth, the authorisation server remains the central hub where access is delegated. Since EUDAT needs finer grained access, the generated X.509 certificate carries also authorisation attributes which are checked against pre-defined access policies.
The system used for this EUDAT AAI pilot was built by the Contrail project. The Contrail Security (ConSec) code is reused and tools are developed for this pilot project.
ConSec was chosen after an evaluation of options, where ConSec promised most of the features required by the EUDAT communities. A ConSec authentication service is currently running at Juelich. EUDAT is currently not running an authorisation infrastructure.

15. EUDAT Sites community centres general data centres repositories
(replica) storages