Download Quinteros-DI4R

A novel AAI approach for the European
Integrated Data Archive within EPOS
J. Quinteros, A. Heinloo, B. Weber, L. Hämmerle and W. Pempe
DI4R-2016 – Krakow, September 28th 2016
EIDA within Orfeus
The European Integrated Data Archive (EIDA) is a distributed
data center established to:
(a) securely archive seismic waveform data and metadata
gathered by European research infrastructures, and
(b) to provide transparent access to the archives by the
geosciences research communities.
EIDA nodes are data centers which collect and archive data from
seismic networks deploying broad-band sensors, accelerometers
and other geophysical instruments.
EIDA within Orfeus
• Protocols to share data
• Daily synchronization
of metadata
• Development of clients
and tools
• Common policies for
data curation
• Statistics
• Maintenance of Routing
Tables
Existing EIDA authentication mechanisms
Arclink
• Proprietary protocol to access seismic waveforms. It was a de
facto standard in Europe.
• It allowed for the creation of federations of datacenters.
• Authentication is based on the email account and no passwords
need to be sent by the user, but...
• Passwords are needed to decrypt data! (one password per
data center).
• Authorization is based on pattern-matching of email address.
FDSN* web service
• It works on datacenters and not federations.
• HTTP digest authentication.
(* Federation of Digital Seismograph Networks)
Why HTTP digest is not optimal for EIDA?
User perspective
• User has to manage independent credentials for each EIDA
data center (unless a central LDAP server or similar is used).
Datacenter perspective
• Pattern-matching (*@gfz-potsdam-de) is not possible, each
individual user has to be added manually.
• Each user has to be deleted when the account expires.
• Problematic for brokers (who makes requests on behalf of
users).
EIDA Authentication System (EAS)
Challenges
• Users from hundreds of institutions want to access data.
• Unified login for users.
• Can we skip the maintenance of a users database?
• No exchange of sensitive information.
• Support retrieval of restricted data from scripts!
Why eduGAIN initially?
• It works with one of the de facto standard
(SAML/Shibboleth).
• We do not need to keep track of the user database (at least
passwords).
• ca. 2000 Identity Providers.
• Some nodes belonged already to eduGAIN when we started.
• Most of them have joined since then and we work to include
the few remaining DCs.
EIDA-AAI solution
• We developed a
prototype of an
Authentication system
to be used in
Federated
environments.
• Secure use of the
services from scripts
and browser.
• EAS provides users with a digitally signed token valid for limited
time and with information about the user.
• This token can be used to query services without the need to login
once you have it locally.
EIDA-AAI solution
•
•
•
•
Separate
authentication from
data services (leaving
just authorization to
data services).
Pattern-based
authorization (data
access rules).
The Authorization system can make use of these attributes to
allow/deny access to resources.
We also support email-based authentication and in the future
other mechanisms (e.g. oAuth, etc.).
FDSN web service extension
• The user presents the list of attributes to /auth method (https) of
a data service.
• The digital signature is verified.
• A temporary account (for /queryauth) is created.
• Access is granted based on pattern-matching of the attributes
(eg., eduPersonPrincipalName LIKE '%@gfz-potsdam.de' is given
access to network XX).
Example
Authenticate in web browser
• eduGAIN: https://EAS/eidaws/auth/1/sso
• E-Mail: https://EAS/eidaws/auth/1/email
• ...
Get temporary queryauth credentials
wget --post-file eidauser.asc https://WS/fdsnws/dataselect/1/auth -O cred.txt
Get data
wget http://`cat cred.txt`@WS/fdsnws/dataselect/1/queryauth?net=... -O data.mseed
Command line client (fdsnws_fetch)
Example
fdsnws_fetch -a token.asc -N "*" -S "A*" -L "*" -C "LHZ" -s \
"2010-02-27T07:00:00Z" -e "2010-02-27T08:00:00Z" -v -o data.mseed
• Work on top of the official EIDA Routing Service running at GEOFON.
• Data and metadata are retrieved from standard FDSN web services.
• Able to handle token issued by the EIDA Authentication Service.
Conclusions
• GEOFON is continuously working to improve:
• the user experience and to facilitate access to data and its
usage.
• The exchange of data between data centres.
• Federation instead of centralization: Provide users a unified,
integrated view of data. Search data focused on scientific purposes
and not on management/political reasons.
• scalable solution, researcher worldwide can benefit through global
eduGAIN infrastructure.
• solution developed user driven - from researchers for researchers.
• adaptable to other communities, who already have expressed their
interest.
Thank you for your attention!
http://geofon.gfz-potsdam.de/
Federative Authentication