OGF PGI - Security Roadmap
==========================


1) Grid Users and Certificate Authorities
-----------------------------------------
1.1)  Each grid User is authenticated by a legal body (recognized by a government).

1.2)  This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User.

1.3)  Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority.

1.4)  All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities).

1.5)  These 3 Policy Management Authorities trust each other and cooperate within IGTF.

1.6)  IGTF distributes the list of CA Certificates to be trusted.

1.7)  Each grid Site providing grid Services to grid Users has to install this list of CA Certificates and keep it up to date.

1.8)  Using its X509 certificate, each grid User can create at any time a (short lived) X509 proxy with permits impersonation / delegation during a short period.


2)  Virtual Organizations
-------------------------
2.1)  A Virtual Organization (VO) groups grid Users with common goals.  A VO is NOT a legal body, can NOT be a Certificate Authority, and can NOT issue X509 certificates.

2.2)  Inside DEISA, a Virtual Community also groups grid Users with common goals.  The relationships between Virtual Communities and Virtual Organizations has to be precised by Morris RIEDEL.

2.3)  Each grid User belongs to 1 ore more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Ressources.

2.4)  Access rights are granted by VOs to grid Users through either :
      2.4.1)  VOMS extensions of X509 proxies (this makes a VOMS proxy)
      2.4.2)  SAML assertions


3)  Grid Services :  Information, AUTHN, AUTHZ
----------------------------------------------
3.1)  Each grid Infrastucture provides an Information Service, with describes the Infrastructure according the the GLUE2 schema.

3.2)  Each grid User can query this Information Service anonymously in order to know which security protocol he has to use to submit requests to grid Services.

3.3)  Each grid User can directly access data hosted by grid Storage Services.  For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy.  For Authorization, the grid User can present :
      3.3.1)  the public part of his VOMS proxy, or
      3.3.2)  a bag of SAML assertions.

3.4)  Each grid User can submit Jobs to grid Computing Services.  If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token.  This delegation token can be :
      3.4.1)  a full VOMS proxy, or
      3.4.2)  a bag of SAML assertions.


4)  Consequences for Interoperability
-------------------------------------
4.1)  X509 proxies MUST fully comply to RFC 3820.

4.2)  VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820.

4.3)  The authentication library used by grid Services MUST fully comply to RFC 3820 (for example a recent version of OpenSLL), so that it can accept as well X509 certificates as X509 proxies.

4.4)  Each grid Site providing grid Services to grid Users MUST install files describing VOMS authorizations and other authorizations, and keep them up to date.

4.5)  The semantics of Authorization tokens MUST be the same for all grid Infrastructures :
      4.5.1)  VOMS extensions
      4.5.2)  Restriction attributes

4.6)  The Information Service of each grid Infrastructure MUST describe, for each grid Service, which Authorization tokens this Service understands (potentially several) :
      4.6.1)  VOMS extensions
      4.6.2)  X509 restriction attributes
      4.6.3)  SAML assertions

4.7)  For SAML assertions, the Information Service of each grid Infrastructure MUST describe, for each grid Service, how they are transported :
      4.7.1)  As attributes of X509 proxies
      4.7.2)  Inside a SOAP header

Unfinished ...