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

[weizhong qiang]

hi,

On Tue, Mar 17, 2009 at 4:29 PM, Duane Merrill <dgm4d at virginia.edu> wrote:

> 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.)
>
Yes. However the "bearer" style is not so inviable, while we can not look at
it with the same security guarantee as "holder-of-key". And it is the
easiest way to implemented.


>
> 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.
>
I think if "SAML-via-SOAP-authn" is compliant to WS-Security SAML profile,
then SSL/TLS (between the client and the service to which this client sends
SOAP message with protection from SAML Token) can be optional since
"SAML-via-SOAP-authn" has already provided independent message-level
authentication.


Weizhong


>
>
>
>>  (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/20090320/31d2404f/attachment-0001.html