[Pgi-wg] Discussion about elements/priorities in the field ofsecurity

[m.riedel at fz-juelich.de]

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-editor/tracker.submit_ggf_draft/artf6263?id=atch4681

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 at 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 at 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
-------------------------------------------------------------------
-------------------------------------------------------------------