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

Thu Mar 19 19:00:14 CDT 2009

On Thu, Mar 19, 2009 at 6:57 PM, <m.riedel at fz-juelich.de> wrote:

> ok let dive into them...,
>
>
> ----- Original Message -----
> From: weizhong qiang <weizhongqiang at gmail.com>
> Date: Thursday, March 19, 2009 4:57 pm
> Subject: Re: [Pgi-wg] Sec: Agreement on supported Attribute Authority
> Interfaces
>
> > hi,
> > I have some questions as following.
> >
> > 2009/3/19 Morris Riedel <m.riedel at fz-juelich.de>
> >
> > > 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
> >
> > Do you proposed to use the stadardized RFC AC, instead of the VOMS
> > AC which
> > is known as a simplified RFC while de-facto AC. If so, I think it
> > is not
> > needed. We can use VOMS AC, because we already have a few
> > production Grid
> > systems which have supported it.
>
> Well I was aware that VOMS AC are compliant with RFC AC's - I didn't know
> that they reduced the complexity of the specification. Can you point me to a
> standard specification of AC VOMS then - or this really purely de-facto?!

I meant this documentation:
https://forge.gridforum.org/sf/go/doc13797
At least from this documentation, there is a statement " Customizations used
by VOMS will be discussed in individual subsections."

 But I am not the one who has quality to assure this.

>
>
>
>
>
>
>
>
> >
> >
> >
> > > 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.
> >
> > Shibboleth itself does not support SLCs, and you need to develope some
> > system to issuing SLCs by using Shibboleth as ONE part of this
> > system. You
> > can also get SLCs credential through otherway except Shibboleth-
> > based. IF we
> > use "push" model, I think how does the client get the credential
> > doesn'tmatter, what does matter is the content of the credential.
>
> Yes, of course, I was referring with Shib to the full palette of it
> [GridShib, ShibGrid, ***whateverSHIB]
>
> I didn't go so much into detail because I hoped Shib* was out of scope
> here, which in turn means that we do not have to deal with credential
> formats in that context - my experience is clearly related to GridShib
> (X.509 + Shib IDP) and rather Globus-driven, which is putting SAML
> assertions in SLC extensions to be checked by CAS.
>
> Q: However, is there  precise demand to support Shib from ARC or could this
> be the non-PGI elements of ARC?

There is no "precise demand", and it is just one module of the development
version. And it is not mandatory for PGI, also not mandatory for other ARC
services.

> Are there users in your production Grid using Shib as AA?

>
> Q: What is the plan of EGEE in this context? Are there already users in
> production using Shib as AA?
>
> Info: UNICORE has been enabled with Shibboleth in DEISA, but part of the
> implementation relies on GridShib to the best of my knowledge following the
> mentioned approach above. So far - we see no precise demand that Shib-* part
> should be part of the PGI profile - especially Shib access is not in
> production in DEISA now, only planned for the next years (-> our of scope of
> PGI from our viewpoint).
>
>
>
>
>
>
> >
> > Futhermore, I can see two different problems here about
> > interoperability in
> > PGI in terms of credential/attributes:
> > a.The interoperability of getting a credential (with attributes
> > inside);    The points you mentioned above are all about this problem.
> > b.the interoperability of using a credential (with attribute inside).
> >    One user or client (on behalf of user) get the credential, it
> > needs to
> > use it and  interoperate with services.
> >
> > I guess PGI is supposed to solve both of them?
>
> I think a might be out of scope since it have to then include proprietary
> protocols such as classic VOMS?! Part of this discussion is to find this out
> - maybe there is a way for it?! (e.g. what do you do once your AC-based
> proxy lifetime ended?! Renewal problem, which interface you use of renewal
> then?)
>
> b. Absolutely!
>
>
> >
> >
> > >
> > >
> > > 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!
> >
> >
> > So we are only going to solve the second sub-problem I concluded
> > above?
>
>
> Maybe - its actually only my suggestion by now - I'm happy to discuss ways
> of how we could standardize point (a) mentioned by you.
>
> >
> > >
> > >
> > > C. We deal with RFC ACs
> >
> > Not VOMS AC?
>
> Please provide a reference for this standard.

See above.

>
>
>
> >
> >
> > >
> > >
> > > 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?
> >
> > Changing VOMS AC to RFC AC?
> > Plus Supporting SAML Assertion?
>
> That is the input for the next e-mail thread then - which types of
> attribute transport formats we have to support - I guess that's hopefully
> all of them, while hopefully avoid using SAML assertions within X.509
> extensions?!

If avoiding using SAML assertion within X.509 extension, a way for carrying
it should be defined ( maybe it is not in this thread? :) )

>
>
>
> >
> >
> > >
> > >
> > > Q: Is there any production infrastructure that largely supports
> > Shibboleth> w/o supporting VOMS either in classic or WS style?
> >
> >
> > In terms of ARC,
> > The production ARC supports VOMS classic
> > The development ARC supports VOMS classic and WS style, and has it
> > own SLCs
> > service which is based on Shibboleth IdP.
>
> ok - useful information - the question would be then when you plan to move
> from development to production with the WS-style?

Since it is optional, no plan to put it into production currently, I think.
And Again, the second problem  (how to push/carry the SAML assertion) which
we need to focus on is orthogonal to the Shibboleth scenario, I think

Weizhong

>
>
> Nevertheless, we have to support VOMS Classic since Steven stated clearly
> that EGEE will not directly move soon to the WS-style - and even if they do
> - there would be probably a lot of services that will be only Classic VOMS
> compliant.
>
>
> >
> > Cheers
> > Weizhong
>
> Thanks for your sharing your thoughts!
>
> >
> > >
> > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> >
>
>
>
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> 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
> -------------------------------------------------------------------
> -------------------------------------------------------------------
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090320/4aca3c61/attachment-0001.html 