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

[Duane Merrill]

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 involves
X.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 discouraged
it 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090317/b31ae85d/attachment.html