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

[weizhong qiang]

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.



> 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't
matter, what does matter is the content of the credential.

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?


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


>
>
> C. We deal with RFC ACs

Not VOMS AC?


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


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

Cheers
Weizhong

>
>
>
>
>
> 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/20090319/74950d66/attachment.html