[Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces

[Duane Merrill]

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 at 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 at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf
> > Of Morris Riedel
> > Sent: 19 March 2009 14:22
> > To: pgi-wg at 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 at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090320/4ec04aaf/attachment-0001.html