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

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

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

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

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

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

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

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

VPH use case

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

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 *

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)

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.

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