Re: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces
Hi Morris, I'm confused by the context here... are you suggesting we look to standardise the VOMS interface (or the service that serves up the proxy that) or the proxy and its content itself? Thanks, Steven Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse
-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Morris Riedel Sent: 19 March 2009 14:22 To: pgi-wg@ogf.org Subject: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces
Hi PGI security folks,
another issue I see is the supported attribute authorities and (more notably) their interfaces.
Taking our experience from GIN into account and addressing the message of Steven (EGEE) there are still two interfaces to consider in terms of VOMS. Also, as an alternative AA there is Shibboleth quite much used in the space.
### goal
(a) We are discussing which AA can be used in PGI to retrieve attributes...
(b) ...because we want to find out which interfaces have to be supported to get attributes...
(c) ... in order to know more precisely which types of attribute transport mechanisms we have to support in PGI.
### Possible scenarios
A. A user contacts a non-WS-based classic VOMS with a proprietary interface, but gets a standardized RFC AC back with the attributes signed by the VOMS. (later on these are used within extensions of RFC proxies for attr- authZ)
B. A user contacts a WS-based VOMS with SAML-REQUEST-interface standard and gets a standardized SAML Assertion back signed by the VOMS service. (later on these are used within WS-SecExt within SOAP Headers)
C. A user contacts a Shibboleth system (possibly w/o WAYF) using SLCs with SAML assertions inside its extensions.
D. A user contacts MyProxy with a stored proxy using ACs in its extension (implies no new attribute transport mechanism), but possibly a new interface of getting (indirectly) attributes.
I see the agreement on the elements of this e-mail thread as a prerequisite to agree on the mechanisms of which attribute formats we support and how we convey attributes precisely (separate email thread).
### Possible conclusion:
A. We only reference in our profile possible ways of retrieving either ACs or SAML assertions (e.g. by pointing to the SAML-request document that is in public comment currently as mentioned earlier). We do not intend to profile how exactly a user gets its attributes.
B. If we agree on A - we indirectly agree on attribute push since in the attribute pull mode - for interoperability reasons - the interface of getting attributes must be known so that the middleware can contact it on behalf of the user!
C. We deal with RFC ACs
D. We deal with SAML assertions
E. We only consider C+D in the first iteration of the profile
### open Questions
Q: Can we agree on these conclusions? Are there any comments - something I missed?
Q: Is there any production infrastructure that largely supports Shibboleth w/o supporting VOMS either in classic or WS style?
Please consider the attribute - and its transport mechanisms out of scope in this e-mail thread.
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)
My opinion is that we should strongly encourage the OGSA-Authz group to finalize *The VOMS Attribute Certificate Format*. OGSA-Authz Working Group, Open Grid Forum, September 11, 2006. http://forge.gridforum.org/sf/go/doc13797?nav=1 (Which has nothing to do with protocols or interfaces for credential retrieval.) -Duane On Thu, Mar 19, 2009 at 10:55 AM, Steven Newhouse <Steven.Newhouse@cern.ch>wrote:
Hi Morris,
I'm confused by the context here... are you suggesting we look to standardise the VOMS interface (or the service that serves up the proxy that) or the proxy and its content itself?
Thanks,
Steven
Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse
-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Morris Riedel Sent: 19 March 2009 14:22 To: pgi-wg@ogf.org Subject: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces
Hi PGI security folks,
another issue I see is the supported attribute authorities and (more notably) their interfaces.
Taking our experience from GIN into account and addressing the message of Steven (EGEE) there are still two interfaces to consider in terms of VOMS. Also, as an alternative AA there is Shibboleth quite much used in the space.
### goal
(a) We are discussing which AA can be used in PGI to retrieve attributes...
(b) ...because we want to find out which interfaces have to be supported to get attributes...
(c) ... in order to know more precisely which types of attribute transport mechanisms we have to support in PGI.
### Possible scenarios
A. A user contacts a non-WS-based classic VOMS with a proprietary interface, but gets a standardized RFC AC back with the attributes signed by the VOMS. (later on these are used within extensions of RFC proxies for attr- authZ)
B. A user contacts a WS-based VOMS with SAML-REQUEST-interface standard and gets a standardized SAML Assertion back signed by the VOMS service. (later on these are used within WS-SecExt within SOAP Headers)
C. A user contacts a Shibboleth system (possibly w/o WAYF) using SLCs with SAML assertions inside its extensions.
D. A user contacts MyProxy with a stored proxy using ACs in its extension (implies no new attribute transport mechanism), but possibly a new interface of getting (indirectly) attributes.
I see the agreement on the elements of this e-mail thread as a prerequisite to agree on the mechanisms of which attribute formats we support and how we convey attributes precisely (separate email thread).
### Possible conclusion:
A. We only reference in our profile possible ways of retrieving either ACs or SAML assertions (e.g. by pointing to the SAML-request document that is in public comment currently as mentioned earlier). We do not intend to profile how exactly a user gets its attributes.
B. If we agree on A - we indirectly agree on attribute push since in the attribute pull mode - for interoperability reasons - the interface of getting attributes must be known so that the middleware can contact it on behalf of the user!
C. We deal with RFC ACs
D. We deal with SAML assertions
E. We only consider C+D in the first iteration of the profile
### open Questions
Q: Can we agree on these conclusions? Are there any comments - something I missed?
Q: Is there any production infrastructure that largely supports Shibboleth w/o supporting VOMS either in classic or WS style?
Please consider the attribute - and its transport mechanisms out of scope in this e-mail thread.
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
I don't think we're going to get anything else out of the Authz group. If this document has value to the PGI group I would suggest (after pinging the Authz group) that we take ownership of it and move it forwards (as is?) within PGI. Steven Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse From: Duane Merrill [mailto:dgm4d@virginia.edu] Sent: 20 March 2009 13:37 To: Steven Newhouse Cc: Morris Riedel; pgi-wg@ogf.org Subject: Re: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces My opinion is that we should strongly encourage the OGSA-Authz group to finalize The VOMS Attribute Certificate Format. OGSA-Authz Working Group, Open Grid Forum, September 11, 2006. http://forge.gridforum.org/sf/go/doc13797?nav=1 (Which has nothing to do with protocols or interfaces for credential retrieval.) -Duane On Thu, Mar 19, 2009 at 10:55 AM, Steven Newhouse <Steven.Newhouse@cern.ch> wrote: Hi Morris, I'm confused by the context here... are you suggesting we look to standardise the VOMS interface (or the service that serves up the proxy that) or the proxy and its content itself? Thanks, Steven Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse
-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Morris Riedel Sent: 19 March 2009 14:22 To: pgi-wg@ogf.org Subject: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces
Hi PGI security folks,
another issue I see is the supported attribute authorities and (more notably) their interfaces.
Taking our experience from GIN into account and addressing the message of Steven (EGEE) there are still two interfaces to consider in terms of VOMS. Also, as an alternative AA there is Shibboleth quite much used in the space.
### goal
(a) We are discussing which AA can be used in PGI to retrieve attributes...
(b) ...because we want to find out which interfaces have to be supported to get attributes...
(c) ... in order to know more precisely which types of attribute transport mechanisms we have to support in PGI.
### Possible scenarios
A. A user contacts a non-WS-based classic VOMS with a proprietary interface, but gets a standardized RFC AC back with the attributes signed by the VOMS. (later on these are used within extensions of RFC proxies for attr- authZ)
B. A user contacts a WS-based VOMS with SAML-REQUEST-interface standard and gets a standardized SAML Assertion back signed by the VOMS service. (later on these are used within WS-SecExt within SOAP Headers)
C. A user contacts a Shibboleth system (possibly w/o WAYF) using SLCs with SAML assertions inside its extensions.
D. A user contacts MyProxy with a stored proxy using ACs in its extension (implies no new attribute transport mechanism), but possibly a new interface of getting (indirectly) attributes.
I see the agreement on the elements of this e-mail thread as a prerequisite to agree on the mechanisms of which attribute formats we support and how we convey attributes precisely (separate email thread).
### Possible conclusion:
A. We only reference in our profile possible ways of retrieving either ACs or SAML assertions (e.g. by pointing to the SAML-request document that is in public comment currently as mentioned earlier). We do not intend to profile how exactly a user gets its attributes.
B. If we agree on A - we indirectly agree on attribute push since in the attribute pull mode - for interoperability reasons - the interface of getting attributes must be known so that the middleware can contact it on behalf of the user!
C. We deal with RFC ACs
D. We deal with SAML assertions
E. We only consider C+D in the first iteration of the profile
### open Questions
Q: Can we agree on these conclusions? Are there any comments - something I missed?
Q: Is there any production infrastructure that largely supports Shibboleth w/o supporting VOMS either in classic or WS style?
Please consider the attribute - and its transport mechanisms out of scope in this e-mail thread.
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
participants (2)
-
Duane Merrill -
Steven Newhouse