Re: [Pgi-wg] Discussion about elements/priorities in the field of security
hi, Thanks for throwing out those points. 2009/3/17 Morris Riedel <m.riedel@fz-juelich.de>
Hi PGI security folks,
currently I see five major elements in terms of security related to PGI:
(1) Authentication/Attribute-based Authorization (i.e. plumbings as named earlier), maybe first push-based before looking at pull-based models - although, this of course, can be discussed as well among us.
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. 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; 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 heard that VOMS attribute service is used in UNICORE, could some collegues provide some details about how the above scenario is processed? In case of ARC, it can get back SAML assertion from VOMS SAML service, and it can put the SAML assertion as extension of proxy certificate; It also support WS-Security (SAML Token profile, as well as UsernameToken and X.509 Token), but how to getting a SAMLToken is lacked. Maybe people from OGSA-AuthZ group can give some suggestions.
(2) Agreement on Definition/Semantics/Structure of Attributes
Has the usage of SAML attribute assertion been decided?
(3) Encoding of delegation restriction/constraints
The restriction is about what kind of policy will be used?
(4) Interface of delegation service (maybe based on subset of WS-Trust)
(5) Agreement on third party credentials transportation (e.g. a delegated GridFTP proxy/SAML assertion-based access for data-staging during BES submissions)
As a starting point - have I forgot something in this enumeration? If so - please answer to this thread.
In terms of priorities, I would suggest to focus first on number one, but of course feel free to comment within this thread.
Agree, IMO, the whole profile which will be adopted is mostly important. Regards, Weizhong
Your co-chair, Morris
P.S. I cc'ed the area director of security (David Groep) to ensure that we did not duplicate efforts done elsewhere (i.e. in the OGSA-AuthZ group). We have been in touch about a few security issues raised in GIN earlier. CIAO.
------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany
Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656
Skype: MorrisRiedel
"We work to better ourselves, and the rest of humanity"
Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
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 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
hi, On Tue, Mar 17, 2009 at 4:29 PM, Duane Merrill <dgm4d@virginia.edu> wrote:
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 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
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.
"Guarantee" is the operative word here. There are likely to be organizational (if not legal) obligations to be protected from simple conspiracy attacks.
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.
Yes, the peer identity obtained from the SSL handshake is [intended to be] disregarded in favor of the (perhaps multiple) identities and attributes authenticated at the SOAP level. But there seems to be strong political pressure to use transport-level (as opposed to message-level) encryption in the majority of grid usage scenarios, almost to the point where it's easier to say "we should always use it". We could consider down-grading to "client-anonymous" TLS/SSL for this "SAML-via-SOAP-authn" compliance target. -Duane
participants (2)
-
Duane Merrill -
weizhong qiang