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

[m.riedel at fz-juelich.de]

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?!







> 
> 
> 
> > 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? 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.


> 
> 
> >
> >
> > 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?!


> 
> 
> >
> >
> > 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?

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
-------------------------------------------------------------------
-------------------------------------------------------------------