|
Size: 4612
Comment:
|
Size: 2959
Comment: Added in refs to All Hands papers
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| #language fr | #language en == A final Requirements Document == This page offers a guide to what work ESP-GRID has done on requirements for access control for grids. (-- AlunEdwards [[DateTime(2006-04-11T08:48:11Z)]]) RequirementsDoc * These are the final requirements for Authentication, Authorisation and Accounting on a generic grid as proposed by the ESP-GRID project. They are based heavily upon [wiki:Self:RequirementsBibliography#MullenGAAAR Shawn Mullen et al's] (2004) document on "Grid Authentication, Authorization and Accounting Requirements". * Other "requirements" documents (including that of Mullen et al.) make an assumption that PKI is being used throughout (client to site/machine, and machine to machine). We wished to take a step back and write down the requirements (for access management and security) without the assumption that 'client to machine' PKI is already employed. For more detail and justifications of changes made to the original [wiki:Self:RequirementsBibliography#MullenGAAAR Mullen et al.] document, please see RequirementsDocFull. This contains many annotations explaining the difference between the documents. |
| Line 4: | Line 15: |
| Currently we are seeking assistance to build a list of use-cases that will lead us towards a set of functional requirements for access management and security for a generic grid. (The 'generic grid' is a production grid, with production applications and a set of users with a wide variety of skills and interests.) We are trying to avoid any limitations with current technologies and to think clearly about requirements before considering technology. This is an early workpackage for the ESP-GRID project. | To inform the above work, the project reviewed publications and other work concerning grid UseCases. The 'generic grid', to which this work alludes, is a production grid, with production applications and a set of users with a wide variety of skills and interests. This work attempts to avoid any limitations with current technologies and to think clearly about requirements before considering technology. |
| Line 6: | Line 17: |
| === Top-level requirements described under: === {{{ * Grid AAA (A) requirements (authentication authorisation and accounting, and auditing) * Grid protection of data requirements (privacy, confidentiality, integrity, digital rights management) * Grid operational characteristics (trust, performance and scalability, manageability incl. architectural components, interoperability, assurance) * Additional requirements which need a better home (single log-on, policy exchange) }}} |
=== Bibliography === RequirementsBibliography * sources and references to articles and papers used in this Requirements gathering exercise |
| Line 14: | Line 21: |
| == Grid AAA requirements (authentication authorisation and accounting, and auditing) described under: == | === Focus Group === FocusGroup * Notes and documents surrounding the focus group meeting. This meeting was held at the start of this activity, on 8th April 2005. |
| Line 16: | Line 25: |
| === Use Cases === UseCases * use cases for a generic grid * this work contains some of the ESP-GRID project output, plus many references to other good work. |
|
| Line 17: | Line 30: |
| === Authentication AuthN === Include Note |
See also the draft [attachment:FocusGroup/GridUseCases0_65.pdf Grid use cases] document (PDF) produced as a stimulus for the Focus Group Meeting. |
| Line 20: | Line 32: |
| identity, anonymity, pseudonimity (secure anonymous communication), credential lifespan and renewal (short-term credentials), assurance levels (SEE ALSO Operational Characteristics), revocation, policies, documentation, usability, trust (SEE ALSO Operational Characteristics) and responsibility, secure roaming | See also [attachment:AllHandsPapers2006/AllHands06TypesUsers.pdf Types of grid users and the Customer-Service Provider relationship: a future picture of grid use] (PDF) - a paper submitted for the UK e-Science All Hands Meeting (2006). |
| Line 22: | Line 34: |
| Insert definition here and requirements follow... === Authorisation AuthZ === Include Note identity, grouping users/roles, authorisation levels, revocation, attributes, policies, 'transparency', privacy, logging, credentials, fault tolerance, delegation, XXXXmore... Insert definition here and requirements follow... === Accounting === Include Note accurate billing and metering, (operational costs, service levels), monitoring or logging, resource and end entity - secure logging, scheduling and resource management. SEE ALSO Grid Auditing Insert definition here and requirements follow... === Auditing === Include Note 'Accounting as a security component', monitoring or secure logging (resource access decisions, policies, policy changes, resource implication of policies), audit logs, intrusion detection, forensics, diagnostics, audit trail (AuthN and AuthZ). SEE ALSO GridAccounting Insert definition here and requirements follow... == Grid protection of data requirements described under: == Include Note . === Privacy === Include Note use of data, (supported by confidentiality mechanisms including AuthZ), significant for health data etc. Definition and requirements follow... === Confidentiality === Include Note supported by access control within systems and encryption between and within systems, signalling policies, supports privacy, protects sensitive data Definition and requirements follow... === Integrity === Include Note provenance (i.e. maintaining integrity of chains/groups of related data), message integrity Definition and requirements follow... === Digital rights management (DRM) === Include Note XXXX Definition and requirements follow... == Grid operational characteristics described under:== Include Note . === Trust === Include Note between collaborative organisations, policy framework, infrastructure Definition and requirements follow... === Performance and scalability === Include Note delegation(policies and trust frameworks, virtual grids) Definition and requirements follow... == Manageability incl. architectural components == Include Note policies, identity management, intrusion detection, anti-virus (i.e. architectural components - others include platform security, system level security design, firewall traversal). Definition and requirements follow... === Interoperability === Include Note between grid environments, policies Definition and requirements follow... === Assurance === Include Note (is this the same as we understand?), security assurance level Definition and requirements follow... described under: == Other Requirements == Additional requirements which need a better home include: . === Single log-on === Include Note delegate an entity's rights subject to policy Defintion and requirements follow... === Policy exchange === Include Note establish a negotiated security context Defintion and requirements follow... |
=== Justification/Requirements for Shibboleth === See the following submitted paper (also to the UK e-Science All Hands Meeting) that ties together the type of grid use for most types of user (i.e. non-computer-technical) to the ease with which Shibboleth could provide access to grid resources. * [attachment:AllHandsPapers2006/AllHands06CaseShib.pdf A case for Shibboleth and grid security: are we paranoid about identity?] (PDF) |
A final Requirements Document
This page offers a guide to what work ESP-GRID has done on requirements for access control for grids. (-- AlunEdwards DateTime(2006-04-11T08:48:11Z))
These are the final requirements for Authentication, Authorisation and Accounting on a generic grid as proposed by the ESP-GRID project. They are based heavily upon [wiki:RequirementsBibliography Shawn Mullen et al's] (2004) document on "Grid Authentication, Authorization and Accounting Requirements".
- Other "requirements" documents (including that of Mullen et al.) make an assumption that PKI is being used throughout (client to site/machine, and machine to machine). We wished to take a step back and write down the requirements (for access management and security) without the assumption that 'client to machine' PKI is already employed.
For more detail and justifications of changes made to the original [wiki:RequirementsBibliography Mullen et al.] document, please see RequirementsDocFull. This contains many annotations explaining the difference between the documents.
Requirements gathering for secure access and use of a generic grid
To inform the above work, the project reviewed publications and other work concerning grid UseCases. The 'generic grid', to which this work alludes, is a production grid, with production applications and a set of users with a wide variety of skills and interests. This work attempts to avoid any limitations with current technologies and to think clearly about requirements before considering technology.
Bibliography
- sources and references to articles and papers used in this Requirements gathering exercise
Focus Group
- Notes and documents surrounding the focus group meeting. This meeting was held at the start of this activity, on 8th April 2005.
Use Cases
- use cases for a generic grid
- this work contains some of the ESP-GRID project output, plus many references to other good work.
See also the draft [attachment:FocusGroup/GridUseCases0_65.pdf Grid use cases] document (PDF) produced as a stimulus for the Focus Group Meeting.
See also [attachment:AllHandsPapers2006/AllHands06TypesUsers.pdf Types of grid users and the Customer-Service Provider relationship: a future picture of grid use] (PDF) - a paper submitted for the UK e-Science All Hands Meeting (2006).
Justification/Requirements for Shibboleth
See the following submitted paper (also to the UK e-Science All Hands Meeting) that ties together the type of grid use for most types of user (i.e. non-computer-technical) to the ease with which Shibboleth could provide access to grid resources.
[attachment:AllHandsPapers2006/AllHands06CaseShib.pdf A case for Shibboleth and grid security: are we paranoid about identity?] (PDF)