This is a version of the document ESP-GRID (Draft) Use cases for a generic grid. Previous versions are available by clicking on this link [http://users.ox.ac.uk/~markn/GridUseCases/ Grid Use Cases] which will show the document produced for and after the Focus Group Meeting.
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:
- PhD Biologist submitting large data sets for processing or Humanities researcher asking very complex questions of a service (e.g. requiring complex textual analysis). or User or organisation receiving regular output (without necessarily sending input) e.g. the BBC or Meteorological Office receiving bulletins from a 'Weather' SP.
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.
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.
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.
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.
Models of grids and grid resources
The following is a (non-exhaustive) list of types of grid resource and models of grid upon which grid computing may be possible. N.B. All may be possible on the same grid, and examples from section 2.3 may be applicable to all.
- Dedicated primary grid service (e.g. compute cluster, data cluster) b. Voluntary secondary resource, actively monitored by resource owner. Resource owner deliberately makes resource un/available and may choose whether or not to run grid jobs on an individual basis. c. Voluntary secondary resource operated blindly by resource owner, possibly with dedicated, secure, ring-fenced sandpit within the system that defers to end-user activity.
d. A no-trust, no-accounting grid (subset of c., above). Each node has a secure sandpit and the owner allows anything to go on there. All users are authorised to use it.
Notes/examples:
SETI@home and climateprediction.net should be examples of b. above as they could theoretically be managed by the resource owner and be actively selected. However, as most workstation users completely trust the programs, they may be behaving more like c., except that the processing is not ring-fenced and secure.
No further detail is attempted here as this document attempts to be neutral in terms of architectures and technology.
Privacy and confidentiality
Running alongside each of the use-cases above are another two dimensions. The first is the need for privacy/anonymity and the second is the confidentiality of the data and/or algorithms.
Privacy
In any of the use-cases listed in section 2.3, the identity of the end-user may need to be protected. Grid nodes and services may care what the end-user is, but may not care who is the end-user. Clearly this is easier to achieve if a trusted third party (e.g. a SP) is submitting the grid job(s).
Confidentiality of data and/or algorithms
Again in any of the use-cases listed in section 2.3, the data and/or algorithms being processed may either be sensitive (e.g. medical records) or confidential (e.g. of commercial importance). Users may need either contractual guarantees that data or algorithms cannot be stolen or observed by an 'unauthorised' entity, or for this to be technically unfeasible.
Appendix one
Appendix two
What is a grid?
Other people's definitions
"An environment in which individual users can access computers, databases and experimental facilities simply and transparently, without having to consider where those facilities are located." [RealityGrid, Engineering & Physical Sciences Research Council, UK 2001] http://www.realitygrid.org/information.html
"A means of network computing that harnesses the unused processing cycles of numerous computers, to solve intensive problems that are often too large for a single computer to handle, such as in life sciences or climate modeling." http://www.consultingtimes.com/glossary.html
After admitting that there is a short answer and a very long answer, the GridCafé web pages at CERN (http://gridcafe.web.cern.ch/gridcafe/whatisgrid/whatis.html) say that:
"The short answer is that, whereas the Web is a service for sharing information over the Internet, the Grid is a service for sharing computer power and data storage capacity over the Internet. The Grid goes well beyond simple communication between computers, and aims ultimately to turn the global network of computers into one vast computational resource."
Wikipedia (http://en.wikipedia.org/wiki/Grid_computing on 29 March 2005), described grid computing, thus:
"Grid computing offers a model for solving massive computational problems by making use of the unused resources (CPU cycles and / or disk storage) of large numbers of disparate, often desktop, computers treated as a virtual cluster embedded in a distributed telecommunications infrastructure."
The same article later asserted:
"Grid computing involves sharing heterogenous resources (based on different platforms, hardware/software architectures, and computer languages), located in different places belonging to different administrative domains over a network using open standards. In short, it involves virtualizing computing resources."
Ian Foster (with Carl Kesselman) updated his previous definitions of a grid in 2004. It should be noted that Foster has also come up with checklists and other, more lengthy text to explain what is a grid. Foster and Kesselman stated:
"We define a Grid as a system that coordinates distributed resources using standard, open, general-purpose protocols and interfaces to deliver nontrivial qualities of service."
Our definitions
For the purposes of this document, we take much of the spirit encompassed in Foster and Kesselman's definition, but find the phrases "standard, open" and "nontrivial qualities of service" laudable but not necessarily defining terms for a grid. We therefore define a grid as:
A set of networked computers and/or other devices, including remote instrumentation, that have been made available so that their operation can be shared. The sharing of these resources must be via an agreed set of protocols.
Foster and Kesselman's "system" is an object because it is identifiable by the agreed set of protocols. Any grid system which the ESP-GRID project produces will use "standard, open, general-purpose protocols", but it is possible that other grids may use proprietary code and standards, as long as all components of the grid use the same protocols. However, for resources that are geographically remote and non-contiguous in network terms, the feature of the set of resources that conveys the essence of being a grid is the common protocols (or possibly middleware).
N.B. For the purposes of the ESP-GRID project, we must also assume that the 'generic grid' is of a mixed economy – i.e. that commercial, academic and non-profit use may co-exist within the same grid. This means that we must consider grids where detailed accounting must be possible. However, this does not need to affect the definition of "a grid".