ASPiS - Architecture for a
Shibboleth-Protected iRODS System
Mark Hedges, Tobias Blanke
Centre for e-Research, King’s College London
Adil Hasan, Jens Jensen
Science and Technology Facilities Council
Andrea Weise
STFC / University of Reading
Building data grids with iRODS, e-Science Institute, Edinburgh, 27th May 2008
Overview of ASPiS
• Funded by JISC e-Infrastructure programme
• Partners:
– Centre for e-Research, King’s College London
– Science and Technology Facilities Council
– (University of Reading - very helpful PhD student)
• Strand 1: access management in iRODS integration with Shibboleth (and authorisation
systems such as PERMIS)
• Strand 2: integration of iRODS with
provenance capture systems
AuthN, AuthZ and iRODS
• Current authentication in iRODS
(username/password, GSI).
• Current authorisation in iRODS.
• Issues with current mechanisms
• Shibboleth and federation
• Shibboleth and iRODS integration
Username/password AuthN
Contains username
iCAT contains list
of usernames
and passwords
irodsEnv
iinit
Username/hashed pw
Password
client
AuthN response
Store hashed pw
irodsA
IRODS
+ iCAT
GSI AuthN
Proxy server
Get proxy cert
iinit
Challenge/response
IRODS
client
AuthN response
compare DN in iCAT
User cert on
client machine
iCAT contains list
of usernames
and DNs
IRODS
+ iCAT
Authorisation
• iCAT stores information on:
– Users
– Domains
– Groups
– Access Control Lists (ACLs)
• Access managed according to:
– Mode of access (read / write / delete /
annotate)
– By user, domain, group
• Information held centrally.
Issues
• Centralised management of user
identities and access rights
• Doesn’t scale well
• Different organisations cannot maintain
their own lists of users in data grid duplication, lists can get out of synch
• Inflexible authorisation system - no
locally managed admin of access rights
• Certificates a barrier to uptake of grids
in some communities
Shibboleth
• Architecture for federated access to web
based resources
• Based on circle of trust among organisations
• User identities managed locally to their
institution
• Access to resources managed locally to the
owning institution
• Adopted by JISC as solution for managing
access to distributed web resources (UK
Access management Federation)
Shibboleth Information Flow
Shibboleth & iRODS
Apache
PIP
Capture &
store
attributes
access
request
mod_
shib
iRODS+RE
attributes
admin
Rule
response
PDP
µ-service
µ-service
µ-service
PEP
Shib: Work so far & plans
• Gathering use-cases for access
management (SRB users, NGS users,
Diamond users and others).
• Setting up iRODS and Shibboleth test
environments (including one for NGS
users)
• Investigate, prototype and evaluate a
number of options:
– How a micro-service will call PDP/PEP
– How to pass attributes through iRODS
– Interaction with web-browser
Provenance
• How the data was derived affects the
interpretation of the data.
• So, important to record how data is
derived (i.e. provenance of the data).
– “derived” includes the process of creation
and subsequent modification and
manipulation of the data.
– we must store as much information as
necessary to understand the data –
depends on context of subsequent use.
– implies that provenance is open-ended.
Provenance & iRODS
• Data to be stored in iRODS should also have
provenance information attached to it.
• Requirements for provenance metadata will
depend on the purpose and context of its
use:
– Implies that we must interoperate flexibly with
existing (& future) provenance systems.
• Must also record the manipulations on the
data once stored in iRODS:
– Versions of rules operating on data.
– Versions of micro-services operating on data.
– Date when data manipulated, host data
manipulated on.
– Who did it.
Provenance & Data Curation
• Internal: store provenance information
in iRODS itself:
– In iCAT or part of iRODS that can be
queried from iCAT
– Capture all iRODS manipulations in rules
and microservices.
• Rules cause micro-services to access
external provenance systems.
– Different micro-services for different
external provenance systems.
– Can configure rule to be executed using
conditional rule execution (as for AuthZ).
Provenance & iRODS
Client stores
client data in iRODS
IRODS
+ iCAT
+ RE
Rule causes microservice to access
external system
External
Provenance
System
Update iCAT
file metadata
Update iCAT
file metadata
IRODS
+ RE
IRODS
+RE
Rule engine runs,
manipulations
recorded
Internal
Provenance
System
IRODS System
Provenance: Work so far & Plans
• Gathering use-cases for what to
store/access.
• Already working on how to query
PASOA through iRODS (Andrea
Weise).
• Starting to investigate how to capture
information from iRODS system.
– Need to understand how we can version
rules and micro-services.
Contacts
mark.hedges at kcl.ac.uk
tobias.blanke at kcl.ac.uk
a.hasan at rl.ac.uk
j.Jensen at rl.ac.uk