Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
Duane, in addition I forgot to mention that we already agreed in PGI that we only do attribute-based authorization for those that would like to be PGI-compliant while still supporting identity-based authZ of course. It's not related here for AuthN - but helps to understand my circumvention of the complicated 'additional' scope. It makes sense - but allows too much flexibility I think that break possibly interop again. You may want to support still purely identity-based authZ in the non-PGI-compliant part. At least that is my suggestion. Otherwise we end up of standardizing each functionality purely out of our systems. Sorry for not mention that again, Morris -------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel 'We work to improve ourselves and the rest of mankind.' ----- Original Message ----- From: Duane Merrill <dgm4d@virginia.edu> Date: Thursday, March 19, 2009 2:40 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
I don't understand the strict "either-or" wording below with regards to PCs versus PKCs in a *proxy-plus-embedded-AC* conformance target. You make it sound like their use would be unilaterally mutually exclusive. Both types of certificates can embed attribute certificates, and there is an "is-a"/polymorphic relationship here: a PKC is a PC of delegation depth zero (and therefore does not have the extension OID set).
A *proxy-plus-embedded-AC* conformance target should describe implementations that allow both. In the strawman document, the goal of layering the *pgi-tls-proxy* conformance target on top of the *pgi-https*target was to add functionality (not take it away): *pgi-tls-proxy* describes SOAP implementations that perform mutual SSL/TLSauthentication with certificates, and these certificates MAY have proxy extensions (making them PCs) and MAY have AC extensions (embedding attributecertificates).
Perhaps I am just misinterpreting your language.
-Duane
2009/3/19 Morris Riedel <m.riedel@fz-juelich.de>
Hi security folks,
reading certain elements of the IIRM, strawman, and following discussions> on the list - I see there is still no common agreement on SOAP / HTTP(S) in some areas.
### Goal:
(a) We are discussing if SOAP / HTTPS can be used in PGI to contact a functional interface (like BES)...
(b) ...because we want to find out if there is any important service in the PGI context that is not capable of using SOAP (over SSL layer)...
(c) ... in order to find out if we can agree on SOAP/HTTPS or to understand> requirements from other non WS-based interfaces in PGI.
Therefore the aim of this thread is to get to an agreement in this context, while considering Attribute authorities like VOMS as a supportive service and not an functional interface (also separate thread).
### Contacting functional implementations with SOAP
If we consider the case that we communicate with an functional interface> like OGSA-BES - we agree on SOAP.
### TLS/SSL Layer:
# <strawman> Foundational: Conveying identity for authentication. SOAP over HTTPS (PGI_HTTPS). SOAP-over-HTTP communication using a SSL/TLS transport protocol in which endpoints are mutually authenticated by X.509 end-entity public key certificates (PKCs). # </strawman>
# <simple plumbings: authentication> We use authentication either based on identities inside X.509 end-entity public key certificates or X.509 proxies (including restrictions, encoding handled separately in another thread).
This refers of using either one or the other of these certificate types on the SSL/TLS level.
For simplification of the profile - there should be no direct dependencies> with attribute-transport used for authorization. # </plumbings>
### Possible scenarios:
# A. TLS with end-entity certificate, SOAP in message -> authN check with CA
# B. TLS with (restricted) proxy certificates, SOAP in message - authN check with proxy signer chain
### Possible Conclusion:
# We use SOAP inside a message to contact functional interfaces.
# We use either full X.509 end-entity certificates OR X.509 proxies (with restrictions)
### Open Questions:
Q: There are WS interfaces for functional specifications that matter to PGI (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree on SOAP based on HTTPS as mentioned above?
Q: If not - are there any important functional interfaces (except support interfaces from AAs like classic VOMS) that do not support SOAP in the PGI ecosystem?
Please feel free to comment but let the question of attributes+restrictions> outside - I propose to deal with it in separate threads because of their complexity.
Take care, Morris
------------------------------------------------------------ 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
------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------
Authorization *policy *is out of scope for this conversation. How a callee decides to perform allow/deny checks is irrelevent in a push-style model. I strongly suggest that we take a "zero-or-more" approach to both: - Proxy chain depth - Attribute certificates You are suggesting a "one-or-more" approach, which is a Bad Idea because it increases complexity while reducing the number of supportable use-cases. There is nothing good about a one-or-more mandate for either. -Duane On Thu, Mar 19, 2009 at 1:40 PM, <m.riedel@fz-juelich.de> wrote:
Duane, in addition I forgot to mention that we already agreed in PGI that we only do attribute-based authorization for those that would like to be PGI-compliant while still supporting identity-based authZ of course.
It's not related here for AuthN - but helps to understand my circumvention of the complicated 'additional' scope. It makes sense - but allows too much flexibility I think that break possibly interop again.
You may want to support still purely identity-based authZ in the non-PGI-compliant part. At least that is my suggestion. Otherwise we end up of standardizing each functionality purely out of our systems.
Sorry for not mention that again,
Morris
-------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany
Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel
Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656
Skype: MorrisRiedel
'We work to improve ourselves and the rest of mankind.'
----- Original Message -----
From: Duane Merrill <dgm4d@virginia.edu> Date: Thursday, March 19, 2009 2:40 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
I don't understand the strict "either-or" wording below with > regards to PCs versus PKCs in a *proxy-plus-embedded-AC* conformance target. You make it sound like their use would be unilaterally mutually exclusive. Both types of certificates can embed attribute certificates, and there is an "is-a"/polymorphic relationship here: a PKC is a PC of delegation depth zero (and therefore does not have the extension OID set).
A *proxy-plus-embedded-AC* conformance target should describe implementations that allow both. In the strawman document, the goal of layering the *pgi-tls-proxy* conformance target on top of the *pgi-https*target was to add functionality (not take it away): *pgi-tls-proxy* describes SOAP implementations that perform mutual SSL/TLSauthentication with certificates, and these certificates MAY have proxy extensions (making them PCs) and MAY have AC extensions (embedding attributecertificates).
Perhaps I am just misinterpreting your language.
-Duane
Hi security folks,
reading certain elements of the IIRM, strawman, and following discussions> on the list - I see there is still no common agreement on SOAP / HTTP(S) in some areas.
### Goal:
(a) We are discussing if SOAP / HTTPS can be used in PGI to contact a functional interface (like BES)...
(b) ...because we want to find out if there is any important service in the PGI context that is not capable of using SOAP (over SSL layer)...
(c) ... in order to find out if we can agree on SOAP/HTTPS or to understand> requirements from other non WS-based interfaces in PGI.
Therefore the aim of this thread is to get to an agreement in
while considering Attribute authorities like VOMS as a supportive service and not an functional interface (also separate thread).
### Contacting functional implementations with SOAP
If we consider the case that we communicate with an functional interface> like OGSA-BES - we agree on SOAP.
### TLS/SSL Layer:
# <strawman> Foundational: Conveying identity for authentication. SOAP over HTTPS (PGI_HTTPS). SOAP-over-HTTP communication using a SSL/TLS transport protocol in which endpoints are mutually authenticated by X.509 end-entity public key certificates (PKCs). # </strawman>
# <simple plumbings: authentication> We use authentication either based on identities inside X.509 end-entity public key certificates or X.509 proxies (including restrictions, encoding handled separately in another thread).
This refers of using either one or the other of these certificate types on the SSL/TLS level.
For simplification of the profile - there should be no direct dependencies> with attribute-transport used for authorization. # </plumbings>
### Possible scenarios:
# A. TLS with end-entity certificate, SOAP in message -> authN check with CA
# B. TLS with (restricted) proxy certificates, SOAP in message - authN check with proxy signer chain
### Possible Conclusion:
# We use SOAP inside a message to contact functional interfaces.
# We use either full X.509 end-entity certificates OR X.509
2009/3/19 Morris Riedel <m.riedel@fz-juelich.de> > this context, proxies (with
restrictions)
### Open Questions:
Q: There are WS interfaces for functional specifications that matter to PGI (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree on SOAP based on HTTPS as mentioned above?
Q: If not - are there any important functional interfaces (except support interfaces from AAs like classic VOMS) that do not support SOAP in the PGI ecosystem?
Please feel free to comment but let the question of attributes+restrictions> outside - I propose to deal with it in separate threads because of their complexity.
Take care, Morris
------------------------------------------------------------ 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
------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich
Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------
participants (2)
-
Duane Merrill -
m.riedel＠fz-juelich.de