This page is purely unfinished notes from the UseCasesPaper page.
Use cases for a generic grid
Introduction
An appeal
The authors of this document appeal strongly for feedback and for criticisms of our use-cases. We would also like to hear examples of other use-cases that we may not have considered.
What is this document?
This document is the first step in establishing the types of actors and some example use cases, and then requirements for access management and security in a 'generic grid'. We use the term generic grid to denote something which is a grid (defined in appendix XXXX) but which does not (as yet) mandate any particular technology or middleware. Once the general use cases are established that reflect the types of users that a generic grid would support, and possibly some of the scope of activities within a grid, then the requirements for the middleware/access management and security can be generated.
What this document is not!
This document is not about building requirements for access management and security. The approach taken with this document is to try to capture some scope of a generic grid, identify the basic actors in such grids using example use-cases and from there to open the way for thinking (in documents) regarding general access management and security requirements.
Use-cases for grids
Introduction
Please note that section 2.3 addresses the use-case scenarios from the point of view of a user, rather than the technology or machines involved. The use-cases in section 2.3 do not consider issues such as personal privacy (as in service providers knowledge of who is the end-user) and data confidentiality (as in service providers being able to steal sensitive or confidential data). These issues are considered in section 2.4.
See section 2.2 for short definitions of the terms used in the next section.
The accompanying/later document Requirements gathering exercise:(2) Authentication, authorisation, accounting and security goes on to consider some of the issues of authentication, authorisation, accounting and security (AAAS) that arise from such use-cases and the types of grids that are proposed in this document. It should be noted that the subsequent document is fully dependent upon the contents of this present document and any changes to the use-cases may affect the AAAS findings as laid out in that later document.
As a point of interest with which to explore the actors and to test the generalised use-cases given in section 2.3, Appendix XXXX n. XXXX gives some example user stories.
Terms defined
AuthN Authentication.
AuthZ Authorisation.
Grid AM service Grid access management service (left undefined further).
Grid resource node Any computer or instrument connected as part of the grid that is available for grid use.
GRID-SYS Grid Infrastructure System Administrator (or similar role).
Identity provider Authentication (and possibly authorisation) service run by an organisation to which the user belongs. The grid, or the grid AM service may trust this identity provider to perform the authentication task and it may also trust this provider to supply reliable authorisation/status information.
Primary grid service A grid infrastructure service (e.g. grid cluster, resource broker, access management point etc., as opposed to other 'services' which may run as applications and which may use the primary grid services.)
PUA Power user that does not care which grid resource node is used to run his/her job.
PUDS Power user developing an application service.
PUS Power user requiring specific grid resource nodes upon which to run jobs.
Resource broker Some kind of service running on 'the grid' that accepts jobs from users and SPs and allocates those jobs to individual grid resource nodes. It may also play a role in accounting. Note: This document seeks to avoid mandating architectures or middleware technology. Therefore, the resource broker could also be taken to mean the first node to which the user submits a job. That primary node could also negotiate with other nodes in order to run jobs.
Secondary resource Computer that is not dedicated to only grid use. Its primary purpose may cause it to be under-utilised at certain times and (as a secondary purpose) it can be used as a grid resource.
SP Service Provider.
SEU Service end-user.
TPB Third party beneficiary of grid processing. This entity (individual or organisation) is not a user (PUA, PUS, PUDS or SEU) but a grid user may invoke a grid procedure that processes that entity's data.
Types of grid users and very basic example scenarios
We propose the following types of grid users and give some example use scenarios. Terms in italics are defined in the previous section.
Service end-user (SEU)
Typical characteristic: No computing expertise
Example use-case / scenarios:
Example 1: PhD Biologist submitting large data sets for processing to a service such as BASIS. BASIS (Biology of Ageing e-Science Integration and Simulation system http://www.basis.ncl.ac.uk/ ) is a UK e-Science pilot project which delivers a grid enabled system that serves the biology of ageing research community by helping to integrate data and hypotheses from diverse biological sources, (further information Shawn Gillespie et al's 'Web-services for the biology community: the BASIS project', AHM 2005.
- Example 2: Humanities researcher asking very complex questions of a service (e.g. requiring complex textual analysis).
- Example 3: User or organisation receiving regular output (without necessarily sending input) e.g. the BBC or Meteorological Office receiving bulletins from a 'Weather' SP.
Example 4: Social scientist submitting various problems or scenarios to a social modelling and simulation service (with full graphical interface like the games 'The Sims'™ as well as 'SimCity'™, as suggested by the MOSES project. A use-case suggested by the MOSES project (Modelling and Simulation for e-Social Science) is that "a user with an interest in crime patterns might access data on propensities to commit crimes (or the likelihood of falling victim to crime) together with intelligence relating to the crimes reported to various local police forces. This could lead to a model which allows the effectiveness of crime prevention to be benchmarked." (Further information Mark Birkin et al's 'MOSES: Modelling and Simulation for e-Social Science', AHM 2005.
AM/security characteristic: SEU does not need to be 'known' by the grid AM service (as the grid trusts and accounts the SP not the user). SP may need to authN/authZ and account for the user.
Power user agnostic of ''grid resource node'' (PUA)
Typical characteristic: Develops programs and data but does not care where processing takes place
Example use-case / scenarios: Technical expert programmer supporting end-user. Submits the programs and data to a resource broker or primary node, which, in turn, submits jobs to (other) grid resource nodes. The PUA does not care which resource takes on the job.
- Example: Takes data from PhD Biologists as there is no service available for their needs. Packages data and algorithms and submits these to the grid for processing.
AM/security characteristic: PUA need not be 'known' by the grid AM service (but some sort of mapping to a billing account may be necessary). It is likely that the grid AM service may need status information from an identity provider (for authZ purposes).
Power user requiring specific ''grid resource nodes'' (PUS)
Typical characteristic: As PUA but may have more platform etc. dependent expertise and some sysadmin expertise
Example use-case / scenarios: As above (PUA) but PUS does not wish, or cannot, use a resource broker (in its normal method of operation). The PUS writes specifically for jobs to be run on defined grid nodes. This could involve interaction with a resource broker, but for accounting purposes only.
- Example 1: (The example of an expert serving the needs of PhD Biologists or Humanities researchers fits equally well here).
- Example 2: PUS has a never-ending project that calls a grid-connected telescope studying sunspot activity. PUS has to be specific about the telescope and s/he is also driving a project that needs to keep running and not be seen as a discrete (set of) job(s) that has one output.
AM/security characteristic: PUS may or may not need to be 'known' by the grid AM service (but some sort of mapping to a billing account may be necessary). All of the text regarding AM/security for PUA is equally valid here. However, in addition, grid node owners may wish to have a direct authN/authZ (and accounting) relationship with the PUS.
Power user developing a service (PUDS)
Typical characteristic: As PUA/PUS but developing expertise like SP
Example use-case / scenarios:
- As PUA or (more likely) PUS where the user wishes to allow the developed application to run as a service for SEUs but the service is still in development.
Example 1: XXXX NeuroGrid developers? XXXX Further information John Geddes et al's 'NeuroGrid: Collaborative Neuroscience via Grid Computing', AHM 2005.
Example 2: XXXX GRIDCC Collaboration? Further information Peter R. Hobson et al's 'GRIDCC - providing a real-time Grid for distributed instrumentation', AHM 2005.
Example 3: XXXX ImpliedVolatilityGrid? for stock market option calculations. Further information Gordon Macleod et al's 'ImpliedVolatilityGrid: Grid Based Integration to Provide On Demand Financial Risk Analyisis', AHM 2005.
Example 4: XXXX UK Virtual Observatory providing UK access to the Solar Dynamics Observatory for AIA and HMI Data and Algorithms. Further information Elizabeth Auden et al's 'eSDO: UK Access to the Solar Dynamics Observatory: Leveraging the UK Virtual Observatory for AIA and HMI Data and Algorithms', AHM 2005.
AM/security characteristic: As for PUS or PUA, but moving into arrangements like SP (see below). May need to begin interacting with and accounting for SEUs in an experimental manner.
Service Provider (SP)
Typical characteristic: As PUA/PUS but has expertise in authZ and possibly identity management
Example use-case / scenarios:
- SP provides a user interface (possibly via web, not necessarily via grid middleware) for SEUs. The SP interfaces directly with SEUs and then adopts a role as PUA or PUS in order to execute the processing job.
- Example 1: Accepts large spreadsheets or XML files of data from PhD Biologists (or digital texts and complex textual analysis questions from humanities researchers).
- Example 2: A 'Weather service' SP runs constant 'chains' of jobs on the grid that call upon satellites and weather stations for 'moment in time' data. Grid jobs compute predictions and reports to present or send to SEUs.
Example 3: Offers immersive virtual reality interfaces over access grid technology, such as developers for the project Advanced Grid Interfaces for Environmental e-science in the Lab and in the Field. This project has been exploring areas of escience involving significant field-based activity, including environmental monitoring in the Antarctic and urban pollution in London. In this project they have also explored ways of integrating with the Access Grid, in particular the Access Grid Toolkit version 2 (currently version 2.3). Specifically, they have worked to (1) integrate a collaborative mobile pollution monitoring and visualisation application, and (2) allow immersive virtual reality interfaces (e.g. CAVE™ and RealityCentre™ type devices) to be used as nodes. (Further information Chris Greenhalgh et al's 'Integrating with the Access Grid: Experiences and Issues', AHM 2005; and Steve Benford et al's 'e-Science from the Antarctic to the GRID', AHM 2003; and Anthony Steed et al's 'e-Science in the Streets: Urban Pollution Monitoring' AHM 2003; and The Access Grid Project; and Chris Greenhalgh's 'Equip: An Extensible Platform For Distributed Collaboration'.
Example 4: Offers the management and processing of data, including banks of high resolution .TIF images of manuscripts from private collections for comparison and analysis by partner organisations, such as via the "The Online Froissart : texts, manuscripts, and digital tools" project. The Froissart Project led from the University of Sheffield has created and archived high-quality .TIFF images, at 133MB each, and JPEGs are in daily use for transcription and research. See also Colin Dunn's and Peter Ainsworth's 'The Medieval Book: Online Froissart Project: HEIF KNOWLEDGE EXCHANGE AWARD Report of activities, Aug-Sept 2004 (Project Title : "Virtual Vellum : digital tools for the medieval manuscript, Research & Development and Public Dissemination")'.
Example 5: Offers orchestral performances to an audience, to be delivered via the Access Grid, (part of the CSAGE project's investigations into the issues of linking researchers with each other). The Collaborative Stereoscopic Access Grid project (CSAGE, Manchester) is building user (i.e. audience) 'presence' into an extension of existing Access Grid infrastructure by establishing stereoscopic extensions to an existing Access Grid node. This will deliver new and far more sophisticated means of one-to-one, or one-to-many communication. Orchestral performances, for example, can be delivered to the 'audience' with the familiar speed, cost-efficiency and flexibility of the Access Grid, but stereophonically. The project will achieve this by digitising objects in 3D and infiltrating them into virtual environments as believable, life-sized entities. Referred to in Anderson, Dunn and Hughes' 'VREs in the arts and humanities', AHM 2005.
The SP may need to identify or authZ the SEU for access or accounting purposes. The SP then submits the 'job' to the grid, possibly via a resource broker or possibly directly to particular grid nodes. The SP collates the returning output and sends or presents it to the user.
AM/security characteristic: SP may be trusted to provide services only to those supposedly authorised to use the grid. SP may need to identify (authN) SEUs but will probably need to recognise status (authZ). SP will need strong authN between it and the primary grid service or grid resource nodes. Accounting may be required between the grid resource nodes (or primary grid service) and the SP and between the SP and the SEU (although this latter requirement may not need to be met using grid middleware).
Infrastructure sysadmin (GRID-SYS)
Typical characteristic: System administration of grid nodes with possibly infrastructure delivery and security expertise
Example use-case / scenarios:
A GRID-SYS may manage dedicated grid resource nodes (including clusters) and any grid system objects such as resource brokers, authN, authZ or accounting points. As well as possibly managing a resource, a GRID-SYS is likely to be responsible for (and expert in) security and access management. A GRID-SYS may be the resource manager of a node that accepts jobs (from PUAs) from the resource broker, or of a node that may authenticate or authorise PUS users directly where they wish to be specific and use the GRID-SYS's resource without any involvement of the resource broker. A special type of GRID-SYS is someone who hosts a grid resource node for a particular SP, or a set of SPs.
AM/security characteristic: A GRID-SYS may need to authenticate directly to particular grid resource nodes. However, in theory, it is possible that s/he may authenticate elsewhere and the node computer may trust that external authentication point (or identity provider). [This may be difficult to accept in these days where direct (root) access for sysadmins is the norm, but it would seem that there is no compelling reason for this to remain the primary system of access in the future].
Third party beneficiary TPB (non-user)
Typical characteristic: Person or organisation who does not interact directly with the grid but where his/her/its personal data are being handled on the grid
Example use-case / scenarios: Data belonging to or pertaining to a TPB may be handled by one or many grid nodes. These data may be required to be guaranteed to be confidential and the TPB may require anonymity.
- Example: A SEU could ask an SP for a TPB's records to be processed and for the SEU to receive the results of the processing. Irrelevant data concerning the TPB may be required to be kept from the SEU and all other grid users, owners and administrators. The TPB should be anonymous or untraceable by other grid users, owners and administrators.
Example: XXXX Extracting information from clinical records for British Medical Association or the World Health Organisation or n.? e.g. AMBIT (text analysis). Further informationfrom Henk Harkema et al's 'Information Extraction from Clinical Records', AHM 2005.
AM/security characteristic: The TPB typically does not interact with the grid (whereby s/he would become a SEU) and therefore no direct AM may be required, except for interaction with the database that holds the confidential data (and this may not be considered a grid interaction – merely database authN/authZ). However, there is a possible security characteristic in that the TBP’s data and identity may have to be kept secret from other grid users.