1 / 17

ASPiS - Architecture for a Shibboleth-Protected iRODS System

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.

edmund
Télécharger la présentation

ASPiS - Architecture for a Shibboleth-Protected iRODS System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  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 • 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

  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 iRODS+RE 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

More Related