Howdy partners, (1a)

...

If we are talking about attributes carried inside SAML assetion, getting the attributes from attribute authority is not a challenge, for instance we can use the VOMS SAML service (client gets back SAML assertion that including attributes through SSL authentication with VOMS SAML service) as a candidate.

Well I propose that we MAY have to consider also the classic VOMS style in using the Proprietary VOMS protocol to obtain ACs, because of interoperability reasons since many of our infrastructures (i.e. ARC + EGEE) rely on this - or am I wrong in this? Please consider that we have to focus on production not what may arise in 2 years time as a security framework. More conrete facts/questions: GENESIS-II and UNICORE will work with SAML-based VOMS because of largely build in support for SAML assertions. Q: Is there a short-time plan that ARC will be able to support SAML-based VOMS? Q: Is there a short-time plan that gLite will be able to support SAML-based VOMS? (1b)

I propose that the "aquisition of tokens" in a push-style model is orthogonal to action-item (1). If we want to consider it, we should address it as a separate concern (in the same vein that aquisition-of-delegation-tokens has been broken out into a seperate issue). Action-item (1) should be about nothing more complicated than profiling a simple request-response message exchange between two endpoints in which all parties already possess the necessary credentials.

I agree with Duane - having both discussed together is too complex and certain elements of it are also part of a security document which in OGF public comment I guess: https://forge.gridforum.org/sf/sfmain/do/downloadAttachment/projects.ggf-edi... I suggest that we... a) create for this a seperate number in the thread which is 6 then b) re-use elements of the security groups we are working with, i.e. the above mentioned document and others. (1c)

...

But how to push the SAML assertion from client side to service side could be a challenge (for which voms has not provided solution, IMO). I can see two ways: one ways is put the SAML assertion into X.509 proxy certificate's> extension, by which you can gurantee that the attributes information is binded with SSL authentication;

I believe that the use-case for attribute-bound SSL authentication involvesX.509 attribute certs (ACs) as per the original VOMS implementation rather than SAML attributes.

...

the other way is to put SAML assertion in the SOAP header, which furtherly cause two branches: First brach, using the SAML assertion for message (SOAP) level authentication + attribute carraying (in this case the VOMS SAML service should probably be improved to creat SAML response containing a holder-of-key authentication assertion, then this assertion can be used for message level authentication according to WS- Security SAML Token profile 1.1); Second branch, using SAML assetion only for attribute carraying (in this case, the transport level securiry should be configured).>

I have been contributing to the SAML-based VOMS via OMII-Europe by being the first using it...:-) So the idea in 2006 was to use WS-Security Extensions in SOAP Headers with n SAML Assertions. CAS of Globus works with SAML assertions inside proxies to largely support Shibboleth and SLCs. However here I would strongly disagree to put this into PGI. I know no infrastructure using it directly like that. (2)

Yes. The Strawman doc makes an initial stab at this by profiling a FQAN-style syntax/semantics for both X.509 ACs and SAML assertions. (VOMS already does that for the former, and the SAML examples in Morris' doc in GridForge resemble the latter.) That way both assertion-styles would be capable of conveying identical information.

Yeah - but of course, we should explicitly make a list and come to an agreement between all of our members. So, it looks we have identified the security experts from GENESIS-II, ARC, and UNICORE - so we could need an expert of gLite too for Friday. Thanks for sharing your thoughts. Take care, Morris ----- Original Message ----- From: Duane Merrill <dgm4d@virginia.edu> Date: Tuesday, March 17, 2009 4:29 pm Subject: Re: [Pgi-wg] Discussion about elements/priorities in the field of security

Comments inserted....

2009/3/17 weizhong qiang weizhongqiang@gmail.com

...

If we are talking about attributes carried inside SAML

assetion, getting

...

the attributes from attribute authority is not a challenge, for instance we can use the VOMS SAML service (client gets back SAML assertion that including attributes through SSL authentication with VOMS SAML service) as a candidate.

I propose that the "aquisition of tokens" in a push-style model is orthogonal to action-item (1). If we want to consider it, we should address it as a separate concern (in the same vein that aquisition-of-delegation-tokens has been broken out into a seperate issue). Action-item (1) should be about nothing more complicated than profiling a simple request-response message exchange between two endpoints in which all parties already possess the necessary credentials.

...

But how to push the SAML assertion from client side to service side could be a challenge (for which voms has not provided solution, IMO). I can see two ways: one ways is put the SAML assertion into X.509 proxy certificate's> extension, by which you can gurantee that the attributes information is binded with SSL authentication;

I believe that the use-case for attribute-bound SSL authentication involvesX.509 attribute certs (ACs) as per the original VOMS implementation rather than SAML attributes.

...

the other way is to put SAML assertion in the SOAP header, which furtherly cause two branches: First brach, using the SAML assertion for message (SOAP) level authentication + attribute carraying (in this case the VOMS SAML service should probably be improved to creat SAML response containing a holder-of-key authentication assertion, then this assertion can be used for message level authentication according to WS- Security SAML Token profile 1.1); Second branch, using SAML assetion only for attribute carraying (in this case, the transport level securiry should be configured).>

The second branch you describe ("bearer" style) is not viable: you need a "holder-of-key" approach in which the caller demonstrates possession of a private key corresponding to the public one signed into the attribute by the attribute authority. (You could potentially demonstrate this via an SSL signature, but I consider that to be an ugly hack and explicitly discouragedit in the Strawman document.)

Thus we arrive at two scenarios: ACs-via-SSL-authn and SAML-via- SOAP-authn. Confidentiality and integrity provided in both cases by SSL/TLS, of course.

...

(2) Agreement on Definition/Semantics/Structure of Attributes

Yes. The Strawman doc makes an initial stab at this by profiling a FQAN-style syntax/semantics for both X.509 ACs and SAML assertions. (VOMS already does that for the former, and the SAML examples in Morris' doc in GridForge resemble the latter.) That way both assertion-styles would be capable of conveying identical information.

Cheers,

Duane

------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------