ASPiS - Architecture for a Shibboleth-Protected iRODS System

1
ASPiS - Architecture for a Shibboleth-Protected
iRODS System

• Mark Hedges, Tobias Blanke
• Centre for e-Research, Kings 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
2
Overview of ASPiS

• Funded by JISC e-Infrastructure programme
• Partners
• Centre for e-Research, Kings 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

3
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

4
Username/password AuthN
Contains username
iCAT contains list of usernames and passwords
irodsEnv
IRODS iCAT
iinit
Username/hashed pw
client
Password
AuthN response
Store hashed pw
irodsA
5
GSI AuthN
Proxy server
Get proxy cert
IRODS
iinit
Challenge/response
client
AuthN response
compare DN in iCAT
User cert on client machine
IRODS iCAT
iCAT contains list of usernames and DNs
6
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.

7
Issues

• Centralised management of user identities and
  access rights
• Doesnt 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

8
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)

9
Shibboleth Information Flow
10
Shibboleth iRODS
access request
Apache
Capture store attributes
mod_ shib
iRODSRE
PIP
attributes
admin
Rule
response
PDP
PEP
µ-service
µ-service
µ-service
11
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

12
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.

13
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.

14
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).

15
Provenance iRODS
Client stores data in iRODS
client
IRODS iCAT RE
IRODS RE
Update iCAT file metadata
Rule engine runs, manipulations recorded
Update iCAT file metadata
Internal Provenance System
Rule causes micro- service to access external
system
IRODS RE
External Provenance System
IRODS System
16
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.

17
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