[OGSA-AUTHZ] Primary VO/group

Wed Nov 1 03:18:06 CST 2006

Joni Hahkala wrote:
> Hi David,
> 
> Yes, I didn't think of that way of handling it. :)
> 
> But, the VOMS extension currently and I would assume in the future is a 
> set of VOMS ACs.

Thats not a problem. Its just packaging. You make one of the set of ACs 
hold the primary attribute and the others are not.

  There can be several ACs from a VO and from several
> VOs. So, if the primary is defined inside an AC you would have (at least 
> a possibility for) several primary VOs/groups and you would have to 
> define primary primary over the set of the ACs.

So are you saying that after a user has collected his ACs from several 
VOMS servers, he can then select the order in which they put inside the 
proxy certificate? And it is this ordering which determines the primary 
attribute?

If this is the case then the "primary" tag would need to be separately 
shown inside the proxy cert.

regards

David

> 
> Also conceptually the primary VO/group for us is selected by the user, 
> so there is no security need to put it in the AC and get it signed by 
> the VOMS server.
> 
> Cheers,
> Joni
> 
> David Chadwick wrote:
>> Hi Joni
>>
>> Joni Hahkala wrote:
>>> Hi Tom, Valerio,
>>>
>>> Personally I have to say I like it, the pure access control systems 
>>> may then concentrate on the full list of vos/groups (as it includes 
>>> the primary) and the applications that need the primary info can 
>>> concentrate on that field. There might be a semantical difference in 
>>> the primary vo/group in VOMS and in the eduPerson as in VOMS the 
>>> primary vo/group is selected by the user and I couldn't find on the 
>>> links you sent whether the primaries were selected by the user or by 
>>> some other means. The primaryOrgUnitDN at least seems to be set by 
>>> the institution according to the description. Also as the VOMS 
>>> primary info is user defined, it can't be inside the VOMS ACs 
>>
>> Why cant it? I thought the ACs were created on demand for the user and 
>> were different for different grid jobs. In which case, when the VOMS 
>> server creates the AC for the particular job, it puts the two 
>> attributes (primary and all) inside the one AC.
>>
>> regards
>>
>> David
>>
>> (but could be inside the extension) and it
>>> would require a separate verification step to validate that this user 
>>> defined primary is among the valid vos/groups.
>>>
>>> But if you mean bringing this to the current VOMS system, that might 
>>> be a harder sell, as the explicit primary would probably mean a 
>>> change in the VOMS AC extension format, VOMS parsers and maybe in 
>>> VOMS api and in the software that uses VOMS. As the current system 
>>> works, it might be hard to sell even though this would be nicer way 
>>> of accomplishing the primary specification...
>>>
>>> I'm sure Vincenzo and Valerio have some comments.
>>>
>>> Cheers,
>>> Joni
>>>
>>> Tom Scavo wrote, On 10/31/2006 04:16 PM:
>>>> 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
>>> -- 
>>>   ogsa-authz-wg mailing list
>>>   ogsa-authz-wg at ogf.org
>>>   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
>>>
>>
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************