EDGI Use Case 'Service Grid to Desktop Grid'                        2006-07-07
--------------------------------------------                     Etienne URBAH


Security Context
----------------
The security context is described by the EDGI Use Case 'Security of a Production Service Grid'.


System
------
-  A Production Service Grid (Managed Grid of managed Computing Clusters) able to submit Activities to Production Desktop Grids (Loose opportunistic Grids using idle resources)
   For example EGI, EELA, DEISA, ... using the EDGI 3G Bridge to submit Activities to SZTAKI DG, Ibercivis, AlmereGrid, OurGrid, ...


Participants
------------
-  Application Gridification Team
   For example the team having already gridified the Application for a Service Grid

-  DG Application Validation Team
   Team Validating that the Desktop Grid version of the Application is really suitable for submission to the Desktop Grid through the Bridge
   An example of such team is EDGI SA2

-  DG Application Repository Manager
   Manager of the Application Repository for Desktop Grid Applications
   An example of such Manager is a member of EDGI SA1

-  Manager of the UserDomain granting access rights to the User
   The concept of UserDomain is defined by GLUE 2.0
   An example of UserDomain is a VO (Virtual Organization)

-  Bridge Manager
   Manager of the Bridge marshaling the Activities from the Service Grid to the Desktop Grid
   An example of such Manager is a member of EDGI SA1

-  User (of the Service Grid)
   Member of the UserDomain


Description
-----------
-  An Application Gridification Team, belonging to a UserDomain, chooses an Application which both :
   - already runs successfully inside a Service Grid,
   - is suitable for execution inside a Desktop Grid (Input and Output files well known at the time of submission of the Activity, NO Application License, NO Manual Data Staging, NO Hold Point)
   Then the Application Gridification Team uses a Testing Infrastructure to develop a version of this Application suitable for submission to one Desktop Grid through the Bridge, and submits it to the DG Application Validation Team.

-  The DG Application Validation Team :
   - uses a Validation Infrastructure to verify that the Desktop Grid version of the Application can really be submitted through the Bridge for successful execution on the targeted Desktop Grid, and is harmless to the resources of the Desktop Grid,
   - issues an official document stating that this Application version is suitable indeed, and transmits this document to the DG Application Repository Manager.

-  The DG Application Repository Manager :
   - stores the validated Desktop Grid Application inside the Application Repository of the Operational Bridge,
   - notifies the Manager of the UserDomain to which the Application Gridification Team belongs.

-  The Manager of the UserDomain :
   - creates Credentials (such as a VO Group or a VO Role) permitting to identify Activities suitable for submission to one Desktop Grid through the Bridge, and informs the Bridge Manager.
   - grants these specific Credentials to suitable members of the UserDomain, and informs them.

-  The Bridge Manager :
   - configures the Bridge to associate a Bridge Endpoint to these specific Credentials,
   - publishes this association to the Information Repository of the Service Grid.

-  A User, member of this UserDomain :
   - assesses if the Input Data to be processed and the Output Data to be obtained can be made publicly available or not.  If NOT, this User should submit the corresponding Activity for execution only to the local Desktop Grid of his/her Institution, NOT a public Desktop Grid.
   - uses the System to obtain Security Credentials, including these specific Credentials.

-  Optionally, this User fetches the validated DG version of the Application.

-  This User uses the Security Credentials obtained above to submit to the System an Activity :
   - containing the validated DG version of the Application, or referring to it,
   - containing Input Data not too large, or referring to Input Data of any size already present in a Storage Resource readable by the Bridge with the User Credentials.

-  The System recognizes that the User Credentials contain the specific Credentials described above, and brokers the Activity to the associated Bridge Endpoint, which processes the Activity.

-  Each time the User queries the Activity Status, the Bridge Endpoint responds with its best knowledge.


Devious flows
-------------
-  The Desktop Grid version of the Application :
   - crashes on the Validation Desktop Grid, and is NOT validated.
   - overflows the Bridge resources, and is NOT validated.

-  The User is NOT trained enough to obtain the required specific Credentials, so that the System does NOT broker the submitted Activities to the Bridge.

-  The System does NOT correctly use its Information Repository, and does NOT broker the submitted Activities to the Bridge.