Hi Etienne,
I am not easy at all with purely operational requirements being presented as a PGI recommendation. We define what is a standard profile, and it is up to m/w providers and VOs to decide whether they should conform to it or no. I am also sure that PGI is not in a position to define procedures and policies - only best practices, at most. Specifically:
2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. It should be possible to map each Virtual Community to a Group of a Virtual Organization. Why should it be possible at all? I suppose you meant to say that a Virtual Community is similar to a VO, or for all practical reasons can be characterized as a VO, but I don't think it should be necessary to perform any mapping! You are right. New formulation : When necessary, a Virtual Community could perhaps be mapped to a Group of a Virtual Organization.
2.3) Each grid User belongs to 1 or more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Resources. ... and many other services - why single out these two? There are information services, file transfer services, accounting services, monitoring services, data indexing services and even collaborative documentation development and agenda services - my VO membership grants me access to such services already today. New formulation : Each grid User belongs to 1 or more VO (Virtual Organization), which grants him access rights to various Services (Information, Storage, Computing, File transfer, Data indexing, Monitoring, Accounting, Collaborative tools, ...) provided or not by grid middleware. Inside PGI, we focus on following Services provided by grid middleware : Information, Storage and Computing.
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). Currently, inside EGEE : - VOMS servers with version older than 2.0 only accept This has nothing to do with EGEE; old VOMS servers are used by many other projects. You are right.
Globus proxies. The 'vomses' configuration file theoretically contains information about this version, so that the 'voms-proxy-init' command adapts the proxy format when needed, but many VOs distribute an incorrect 'vomses' file. There's certainly nothing "theoretical" with the configuration file: it is well documented, and it is up to every user to fix it, because it actually resides in his/her home directory and can be easily fixed (or messed up, for that matter) without intervention of VO managers. This paragraph has nothing to do with a standard definition. We are not going to write down configuration instructions for every single tool here, are we? New formulation : VOMS servers with version older than 2.0 only accept Globus proxies. The 'vomses' configuration file can contain, at the end of each line, the Globus version used by the VOMS server, so that the 'voms-proxy-init' command adapts the proxy format when needed. But many VO managers distribute an incorrect 'vomses' file, which is installed 'as it' by system engineers, and best practices such as ITIL forbid us to require
Oxana, Concerning my 'PGI Security Model' document : I thank you very much for your efforts to read it, understand it, and provide remarks to it. All your remarks are relevant, and most are appropriate, so I have updated my document accordingly. I also provide my updates interspersed below. I you still have suggestions for any part, or even the full structure of this document, please send them to me. Inside PGI, my general goal is to describe accurately what is really currently used, and to achieve consensus about what could be achieved in short term. I wish that SEVERAL members of PGI perform the same reviewing effort as you, for following documents : 'PGI Security Model' at http://forge.gridforum.org/sf/go/doc15584?nav=1 'Data Staging - Concepts and Scenarios' at http://forge.gridforum.org/sf/go/doc15607?nav=1 'Vocabulary' at http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/Vocabula... Thank you in advance. Best regards. ---------------------------------- Etienne URBAH IN2P3 - LAL Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Mob: +33 6 22 30 53 27 Skype: etienne.urbah mailto:urbah@lal.in2p3.fr ---------------------------------- On Thu, 16 Apr 2009, Oxana Smirnova wrote: that each end user fixes the content of this file himself.
- VOMS servers with version 2.0 onwards will be able (at the end of this year) to accept any kind of proxy, even an X509 certificate.
This is also a minor detail which will have no practical meaning very soon (even now it is hardly relevant)
New formulation : VOMS servers with version 2.0 onwards are able to accept any kind of proxy, even an X509 certificate. EGEE plans to deploy them before the end of this year.
- New GSI implementations of TLS (since version 4.0 approximately) accepts both RFC-3820-compliant X509 proxies and Globus proxies.
I would recommend to read this fine paper, dated July 2005: http://www.globus.org/toolkit/docs/4.0/security/GT4-GSI-Overview.pdf Does anybody think that a technology of 2005 is "new"?.. And it is not "approximately", it is GT4. Even if some projects still use GT2, it is not a reason to call GT4 "new".
Thank you very much for the link, which I have included in chapter 1.9 New formulation : GSI implementations of TLS since version GT4 accepts both RFC-3820-compliant X509 proxies and Globus proxies.
5.3) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820 or GSI, and MAY accept both. Inside EGEE, all VO managers MUST verify the content of their 'vomses' file, and fix it if necessary. No way we can require this, really. Besides, like I wrote before, vomses files are easily overwritten by users local vomses, so this recommendation is completely void. And knowing that the latest VOMS version is actually compliant with this requirement, it becomes redundant.
Best practices such as ITIL forbid us to require that each end user fixes the content of this file himself. These best practices require that each 'vomses' file must be fixed ONLY by its creator (the VO manager), and then deployed. New formulation : Inside EGEE, each VO manager MUST verify the content of his 'vomses' file, append "2" at the end if necessary, and deliver it for deployment.
5.4) The authentication library used by grid Services MUST fully comply to RFC 3820 or GSI, and MAY accept both. Old versions of GSI, which do NOT accept RFC-3820-compliant X509 proxies, block interoperability, and are STRONGLY DEPRECATED. Therefore, we advise each provider of grid middleware using such an old version of GSI to : - establish and publish the list of the components which still uses it, - migrate to a new version of GSI which also accepts RFC-3820-compliant X509 proxies.
No need to advise this publishing and migration, we do not define policies and procedures here. If any Grid m/w provider does not accept both, it is simply not PGI-conforming, period. It may still serve users happily.
As far as I know, EGEE and NAREGI are stuck with old versions of GSI for the foreseeable future. So, if we follow you, EGEE and NAREGI can NOT be PGI-conforming. Therefore, I keep my advice unchanged. You can propose a better formulation.
7.2) The Information Service of each grid Infrastructure MUST describe, for each grid Service, the security requirements for access to the grid Service, and which Authorization Tokens this Service expects (potentially several). Globus proxies are DEPRECATED in favor of RFC-3820-compliant X509 proxies. Each provider of grid middleware MUST establish and publish the list of the components which still require Globus proxies. See above. We can not require m/w providers to report to PGI what they do and what they don't - we are not that kind of an authority. Unless we are going to issue "PGI certified" stickers, or give away "PGI product of the year" awards, of course ;-)
You are right. I have replaced 'MUST' by 'we advise to'.
7.3) The Information Service of each grid Infrastructure MUST describe the transport method that the grid Service expects (potentially several). We repeat here what we have written in chapter 5.4 : Old versions of GSI, which do NOT accept RFC-3820-compliant X509 proxies, block interoperability, and are STRONGLY DEPRECATED. Therefore, we advise each provider of grid middleware using such an old version of GSI to : - establish and publish the list of the components which still uses it, - migrate to a new version of GSI which also accepts RFC-3820-compliant X509 proxies. See above, we are not this kind of an authority. If a m/w provider chooses to produce a non-PGI-compliant software, it is their choice entirely.
Same problem and same answer as for chapter 5.4).
Cheers, Oxana