[OGSA-AUTHZ] Next Telecon

[Tom Scavo]

Thank you, Valerio and Joni, for the clarification.  I now understand
what you are trying to achieve with the ordering of VO membership
attributes.

Instead of relying on the ordering of attributes, which implicitly
conveys a primary attribute, even in those cases where a primary does
not exist, why not make the primary attribute explicit?  As an
example, consider the eduPerson specification

http://www.nmi-edit.org/eduPerson/internet2-mace-dir-eduperson-200604.html

on which the MACE-Dir SAML Attribute Profiles is  based

http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200604.pdf

There we have a multi-valued attribute called eduPersonAffiliation and
a corresponding single-valued attribute called
eduPersonPrimaryAffiliation.  The ordering of attribute values within
eduPersonAffiliation is unspecified while eduPersonPrimaryAffiliation
exposes a distinguished such attribute value.

Making the primary affiliation explicit is preferable to an implicit
ordering, I think.  Can VO membership be handled in this way?

Cheers,
Tom

On 10/31/06, Joni Hahkala <joni.hahkala at cern.ch> wrote:
>
> Just extending a bit with the reasoning we have used in EGEE...
>
> Yes, the "primary" VO and group etc are important for the accounting,
> for example who gets changed for the CPU time and the storage space.
> Also usually it is good to have a concept of file owner, which the
> primary group/vo facilitates.
>
> For the plain access control they are probably not so important, unless
> you think the obligations like account name etc are part of access control.
>
> Cheers,
> Joni
>
> Valerio Venturi wrote, On 10/31/2006 03:21 PM:
> > On Mon, 2006-10-16 at 13:25 -0400, Tom Scavo wrote:
> >> On 10/16/06, Valerio Venturi <valerio.venturi at cnaf.infn.it> wrote:
> >>> Attribute Authority Interface
> >>> We've red the OASIS draft that we were pointed to in Washington OGF by
> >>> Tom Scavo and found it good and detailed. It's pretty much like what we
> >>> were thinking about, so we dont' think there's need for producing
> >>> another doc which won't add much. We'll contact Tom with some concerns
> >>> we have.
> >> We look forward to your feedback regarding this draft document.
> >>
> >>> VOMS first attribute
> >>> Frank Siebenlist asked whether it would be possible to add a tag to mark
> >>> the first of VOMS attributes (both in the context of Attribute
> >>> Certificates and SAML Assertions) since it had a special semantic.
> >>> Actually, it is the order of the attributes that is meaningfull in VOMS,
> >>> not only the first. The voms client indeed have a mean of specyfing the
> >>> entire order in which attributes appear. In the context of AC, this is
> >>> not a problem since you can specify order in a ASN.1 SEQUENCE. It is in
> >>> the context of a SAML Assertion, since despite the fact that most of the
> >>> parser will return the child elements of AttributeStatement as they
> >>> appear in the doc, this is not mandatoiry. So we are thinking about how
> >>> to retain the same behaviour using SAML Assertion.
> >> The ordering of Attribute elements in a SAML AttributeStatement is
> >> unspecified.  If an ordering is required, a new XML indexing attribute
> >> is needed: index="1", index="2", etc.  Can you explain why such an
> >> ordering is required (or just point me to the relevant document where
> >> this is discussed)?
> > Sorry for the late reply Tom. Probably we won't need ordering of Attributes,
> > since we'll change the rendering of VOMS attributes using SAML.
> > (we will move the problem to AttributeValue ordering, and we'll probably be doing what you suggested).
> > However, in general, ordering of VOMS attributes is needed because it is
> > relevant to authorization decisions. VOMS may return a
> > list of groups in the VO that the user belong to and an authorization
> > function may want to know which groups are more relevant (if some are).
> > As a real life example, mapping to local accounts in gLite grid is done
> > after the first group present in the VOMS AC.
> >
> > Valerio
> >
> >
> > --
> >   ogsa-authz-wg mailing list
> >   ogsa-authz-wg at ogf.org
> >   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
>