1. OGF PGI – EDGI Security Use Case and Requirements
Etienne URBAH
LAL, Univ Paris-Sud, IN2P3/CNRS, Orsay, France
The EDGI project receives Community research funding under grant agreement

2. Summary Security Use Case Requirements for Information
Requirements for Security
Requirements for Application Repository
Requirements for Accounting
Requirements for Logging
Requirements for Job Description
Requirements for Job Management
Requirements for the State Model
Non Functional Requirements
Author : E. Urbah

3. Security Use Case : Actors and System
UserDomain Manager (VO Admin)
CSIRT
Security Engineer of a Site
UserDomain (VOMS) Server
Manages UserDomain (VO)
 Provides Credentials (X509 or SAML)
 Requests Credentials
Accounting Logging & Bookkeeping
Gives Accounting and Auditing
Registration Authority (RA)
Manages Site
  Gives Activity Status
 Log
Info System
Info System
Info System
  Log
Publishes available Resources
Publishes available Resources
Grid User
 Submits Activity with Credentials
Grid Broker
Site
Computing Resource
Knows User
 Pushes Activity
 Provides Results
 Sends back Results
Vets User
 Accesses Data  with Credentials
Signs Credentials
  Accesses Data with Credentials
Site
Storage Resource
The Trust Anchor (IGTF)
publishes the Root CA Certificates
Certificate Authority (RA)
Author : E. Urbah

4. Mandatory Requirements for Information (permitting Service Discovery)
1 : All grid entities (if possible) MUST be described using the GLUE model. If not possible, extensions for the GLUE model are necessary.
5 : The Execution Service MUST NOT expose detailed information about the GLUE entities which the Execution Service does not manage (all that are not expressed by the computing part of GLUE). For example, Storage Element GLUE entity NOT exposed by Execution Service, NO details about Storage entity.
165 : For already finished Activities, the Information functionality SHOULD accept requests querying the Activity Status, but MAY return an error
172 : In order to prevent overloading the Execution Service (which has performance requirements for Activity Management), the Information functionality SHOULD be separated from the Execution Service
Author : E. Urbah

5. Mandatory Requirements for Security (Authentication, Authorization, Delegation)
9 : If server authentication to clients, then it must be done with X.509 certificates on TLS (as mandatory option, allowing also other mechanisms additionally)
11 : Each Service MUST publish the Authentication and Authorization methods accepted by its Endpoints in conformance with GLUE recommendations
32 : There must be a mechanism which allows users to manage Activities submitted by other users (access control lists/methods/policies). In order to authorize (or not) an request on an Activity, each instance of the Execution Service MUST enforce a consistent authorization method.
Author : E. Urbah

6. Mandatory Requirements for Application Repository
34 : WITH FOLLOWING TITLE : There MAY exist Application Repositories containing applications or pre-configured / pre-installed software, and publishing them according to GLUE.
- JSDL SHOULD be extended according to GLUE so that a client is able to easily require an Application stored inside a Repository w/o specifying location details.
- The Execution Service SHOULD then honor Job Descriptions referencing an Application stored inside a Repository.
Specifications of the Execution Service SHOULD describe only how it retrieves the Application files from the Application Repository (but MUST NOT try to address ALL the aspects and implications of Application Repositories, in particular queries and rights to store Applications)
Author : E. Urbah

7. Mandatory Requirements for Accounting
36 : The Execution Service SHOULD provide Accounting records for each managed Activity. e.g. OGF Usage Records, for tracking resource usage. Most likely improving UR in terms of network and storage resource tracking and improvements of compute parts of multi-core-business. Grid-level attributes (for example: start-time on Grid vs. in batch-system).
173 : In order to prevent overloading the Execution Service (which has performance requirements for Activity Management), the Accounting functionality MUST be separated from the Execution Service
Author : E. Urbah

8. Mandatory Requirements for Logging
37 : WITH FOLLOWING TITLE : In order to permit efficient Log analysis and Security audit, some Logging and Bookkeeping functionality MUST secure persistence at the grid level of Activity logs from various logging systems and MUST permit Client access to these Activity logs, even after Activities have finished.
Author : E. Urbah

9. Mandatory Requirements for Job Description
100 : The Job Description document MUST reference all grid entities in conformance to the GLUE specification
101 : The Job Description document specification MUST permit the Client to request automatic data stage-in and stage-out
107 : Job Description should be only used for Job Description not for any kind of feedback. Job status information should not be communicated with a 'changed JSDL'
Author : E. Urbah

10. Mandatory Requirements for Activity Management
45 : On creation of an Activity, the Execution Service MUST return to the Client an Activity ID permitting the Client to perform subsequent actions (Query, Cancel, ...) on this precise Activity
62 : The Execution Service MUST log enough grid information inside logging systems (which MAY vary during the lifetime of the Activity), in order to permit efficient Log analysis and Security audit
67 : If a Client queries for an already finished Activity, the Execution Service MAY response with an error
74 : The execution service MUST NOT expose activity information when queried for resource information
94 : Requirement to have a purge (maybe called wipe) operation. Removing all presence (except logs & usage records) of the activity (when it is not longer active or once finished). This functionality is only allowed on any final state according to the PGI state model. The functionality is not supposed to kill Activities, that is why its only allowed on final states.
Author : E. Urbah

11. Mandatory Requirements for the State Model
119 : The Execution service MUST support a common state model
131 : The Execution service MUST perform the transition between Activity states requested by the Client ONLY if it makes sense. Otherwise, the Execution service MUST return an error to the Client.
Author : E. Urbah

12. Mandatory non functional Requirements
146 : Software components (Services and Clients) MUST ease traceability of the original author of a request
147 : Software components (Services and Clients) MUST generate adequate logs
148 : Software components (Services and Clients) MUST generate and propagate meaningful error messages, including context description
149 : Specifications SHOULD prevent the occurrence of SPOFs and bottlenecks
154 : Basic SW Engineering basic principles - implementation encapsulation, separation of policies, construction by composition, don't re-invent new mechanisms when some existing
160 : Execution Service MUST NOT try to provide ALL grid functionalities, but MUST have a well defined scope, and MUST work together with other grid services : Security, Accounting, Data (Storage, Movement, Catalog, ...), perhaps Information, Logging and Bookkeeping
Author : E. Urbah