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, 27 th May 2008

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

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 IRODS + iCAT irodsEnv client iCAT contains list of usernames and passwords irodsA Contains username iinit Store hashed pw Username/hashed pw AuthN response Password

GSI AuthN IRODS client iCAT contains list of usernames and DNs User cert on client machine iinitChallenge/response AuthN response IRODS + iCAT Proxy server Get proxy cert compare DN in 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 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

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 mod_ shib access request iRODS+RE PIP Rule PDP μ-service attributes admin PEP response Capture & store attributes

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

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