Bernd, Oxana and all, Concerning a proposal of specification on GLUE Capability for Security : Lot of thanks to Oxana and Bernd for their contribution. 'In-band' and public GLUE views ------------------------------- I fully agree with Bernd that several different views will be published for GLUE information : - 1 'in-band' GLUE view requesting client credentials (through LDAPS, HTTPS, ...), and providing detailed information according to the access rights of the client, - 1 public GLUE view (through LDAP, HTTP) providing only public information (including the security setup of the 'in-band' GLUE view). At OGF30 in Brussels, JP Navarro explained that TeraGrid is implementing a FLAT XML rendering for several reasons, in particular to ease the publication of these different views. See slide 4 at http://forge.gridforum.org/sf/go/doc16099 'Capability_t' type of GLUE 2.0 for security -------------------------------------------- I agree with Bernd, and I have updated my proposal in the attached 'Glue-Capability-For-Security.txt' file, which is also available at http://forge.gridforum.org/sf/go/doc16157 Thank you in advance for studying this proposal and criticizing it, in order to improve it. Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr ----------------------------------------------------- On Thu, 18/11/2010 20:45, Bernd Schuller wrote:

hi Etienne, Oxana,

On Do, 2010-11-18 at 19:32 +0100, Oxana Smirnova wrote:

...

I'm no Glue expert, and can't remember whether Glue foresees different access privileges to different bits of information. There's one problem with advertising security setup in information systems:

normally, one can't access an information document without being authorised.

That is, you probably can't obtain security setup information without knowing the security setup. Kind of a bootstrap issue, admittedly.

I think that this is not so much of a problem. Let's say you can have "in-band" info systems that use the same security setup as the target services. However, you often have out-of-band info systems that use a different security setup. Usually this will be less strict, say normal HTTPS or even plain HTTP. You might even get a snipped of GLUE2 sent to you via email :-)

So Etienne's approach has a lot of merits.

In detail I've a couple of comments on the SSL/TLS capabilities. There are only three cases here: a1) normal SSL, i.e. server presents its certificate to the client a2) client-authenticated SSL, i.e. the client additionally MUST present a valid certificate

GSI ("SSL with proxy") is not(!) SSL, and should not be on the same level.

So the SSL/TLS attributes should be just security.authentication.ssl security.authentication.ssl.clientauth

if you really want GSI (everybody seems to agree that it is going to be deprecated ...), you need "security.authentication.gsi" etc

Best regards, Bernd.

...

18.11.2010 15:45, Etienne URBAH wrote:

...

Morris, Johannes and all,

Inside OGF PGI, I am trying to perform pragmatic work and provide constructive proposals.

So, inside the attached 'Glue-Capability-For-Security.txt' file, I has written down a first proposal of specifications for extensions of the 'Capability_t' type of GLUE 2.0 taking into account requirements 1, 4, 163, 11 and 17.

I hope that this proposal is understandable.

Please criticize it, in order to improve it .

Best regards.

----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------