ASPiS - Architecture for a Shibboleth-Protected iRODS System - PowerPoint PPT Presentation

1 / 17
About This Presentation
Title:

ASPiS - Architecture for a Shibboleth-Protected iRODS System

Description:

Proxy server. Get proxy cert. compare DN in iCAT. Authorisation. iCAT stores information on: ... Access Control Lists (ACLs) Access managed according to: ... – PowerPoint PPT presentation

Number of Views:38
Avg rating:3.0/5.0
Slides: 18
Provided by: markh112
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com