Dear All the next teleconference is scheduled for Monday 16 October at the following times 7:00 US West Coast 10:00 US East Coast 15:00 UK 16:00 Europe 23:00 Japan Frank S circulated a set of numbers to be used in his last email message of 13 Sept. They are
Skype number is <skype:+99008275780044>
If you want to use a regular phone in the US, call *#1-712-432-4000
with
Conference Room Number: *5780044*
It seems they have the following alternative "local" regular phone call-in numbers available for some European countries: Austria 0820 400 01562 Belgium 0703 59 984 France 0826 100 266 Germany 01805 00 7620 UK 0870 119 2350 I suggest the following provisional agenda 1. Discussion of updated CVS Requirements document (to be circulated soon) 2. Discussion of revised Authorisation Functional components doc (to be circulated soon) 3. Update on suggested changes to VOMS attribute profile 4. Update on documentation of GT4 interfaces 4. Any other topics? Once we can get reasonable agreements on 1 and 2 above, I would then like to move onto discussing protocols between the various authorisation components. But I suggest that this will be at the next telecon after this one. If you have any comments on the above prior to the telecom, please circulate the list regards David -- ***************************************************************** 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@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 *****************************************************************
Hi David, Apologies for asking, but are updated documents available somewhere. Can you specify issues that we will discuss at the telecon? I beleive we will have enough topics to discuss. Yuri David Chadwick wrote:
Dear All
the next teleconference is scheduled for Monday 16 October at the following times
7:00 US West Coast 10:00 US East Coast 15:00 UK 16:00 Europe 23:00 Japan
Frank S circulated a set of numbers to be used in his last email message
of 13 Sept. They are
Skype number is <skype:+99008275780044>
If you want to use a regular phone in the US, call *#1-712-432-4000
with
Conference Room Number: *5780044*
It seems they have the following alternative "local" regular phone call-in numbers available for some European countries:
Austria 0820 400 01562 Belgium 0703 59 984 France 0826 100 266 Germany 01805 00 7620 UK 0870 119 2350
I suggest the following provisional agenda
1. Discussion of updated CVS Requirements document (to be circulated soon) 2. Discussion of revised Authorisation Functional components doc (to be circulated soon) 3. Update on suggested changes to VOMS attribute profile 4. Update on documentation of GT4 interfaces 4. Any other topics?
Once we can get reasonable agreements on 1 and 2 above, I would then like to move onto discussing protocols between the various authorisation
components. But I suggest that this will be at the next telecon after this one.
If you have any comments on the above prior to the telecom, please circulate the list
regards
David
Hi Yuri thanks for reminding me. I have uploaded the CVS requirements now, and will do the functional components next David Yuri Demchenko wrote:
Hi David,
Apologies for asking, but are updated documents available somewhere.
Can you specify issues that we will discuss at the telecon? I beleive we will have enough topics to discuss.
Yuri
David Chadwick wrote:
Dear All
the next teleconference is scheduled for Monday 16 October at the following times 7:00 US West Coast 10:00 US East Coast 15:00 UK 16:00 Europe 23:00 Japan
Frank S circulated a set of numbers to be used in his last email message
of 13 Sept. They are
Skype number is <skype:+99008275780044>
If you want to use a regular phone in the US, call *#1-712-432-4000
with
Conference Room Number: *5780044*
It seems they have the following alternative "local" regular phone call-in numbers available for some European countries: Austria 0820 400 01562 Belgium 0703 59 984 France 0826 100 266 Germany 01805 00 7620 UK 0870 119 2350
I suggest the following provisional agenda
1. Discussion of updated CVS Requirements document (to be circulated soon) 2. Discussion of revised Authorisation Functional components doc (to be circulated soon) 3. Update on suggested changes to VOMS attribute profile 4. Update on documentation of GT4 interfaces 4. Any other topics?
Once we can get reasonable agreements on 1 and 2 above, I would then like to move onto discussing protocols between the various authorisation
components. But I suggest that this will be at the next telecon after this one. If you have any comments on the above prior to the telecom, please circulate the list regards
David
-- ***************************************************************** 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@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 *****************************************************************
Dear David, I won't be able to attend the telecon today. Since there where some pending issues from the discussione we had in Washington, I'm sending you an update. 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. 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. State I don't have progress to report on this matter. Last month we were very busy. My plan is still to circulate some use case to the list, and I hope I can do it soon, but I'm not able to tell now how soon. Valerio On Mon, 2006-10-16 at 13:17 +0100, David Chadwick wrote:
Hi Yuri
thanks for reminding me. I have uploaded the CVS requirements now, and will do the functional components next
David
Yuri Demchenko wrote:
Hi David,
Apologies for asking, but are updated documents available somewhere.
Can you specify issues that we will discuss at the telecon? I beleive we will have enough topics to discuss.
Yuri
David Chadwick wrote:
Dear All
the next teleconference is scheduled for Monday 16 October at the following times 7:00 US West Coast 10:00 US East Coast 15:00 UK 16:00 Europe 23:00 Japan
Frank S circulated a set of numbers to be used in his last email message
of 13 Sept. They are
Skype number is <skype:+99008275780044>
If you want to use a regular phone in the US, call *#1-712-432-4000
with
Conference Room Number: *5780044*
It seems they have the following alternative "local" regular phone call-in numbers available for some European countries: Austria 0820 400 01562 Belgium 0703 59 984 France 0826 100 266 Germany 01805 00 7620 UK 0870 119 2350
I suggest the following provisional agenda
1. Discussion of updated CVS Requirements document (to be circulated soon) 2. Discussion of revised Authorisation Functional components doc (to be circulated soon) 3. Update on suggested changes to VOMS attribute profile 4. Update on documentation of GT4 interfaces 4. Any other topics?
Once we can get reasonable agreements on 1 and 2 above, I would then like to move onto discussing protocols between the various authorisation
components. But I suggest that this will be at the next telecon after this one. If you have any comments on the above prior to the telecom, please circulate the list regards
David
On 10/16/06, Valerio Venturi <valerio.venturi@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)? Thanks, Tom Scavo NCSA/University of Illinois
BTW, on the call this morning there was some uncertainty as to the specific document under discussion here. Could a pointer please be sent to the list. Thanks, Von On Oct 16, 2006, at 12:25 PM, Tom Scavo wrote:
On 10/16/06, Valerio Venturi <valerio.venturi@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.
This is the message I shared with Valerio on Sep 12: http://www.federation.org.au/pipermail/shibgrid-bof/2006-September/000070.ht... Tom On 10/16/06, Von Welch <vwelch@ncsa.uiuc.edu> wrote:
BTW, on the call this morning there was some uncertainty as to the specific document under discussion here. Could a pointer please be sent to the list.
Thanks,
Von
On Oct 16, 2006, at 12:25 PM, Tom Scavo wrote:
On 10/16/06, Valerio Venturi <valerio.venturi@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.
On 10/16/06, Valerio Venturi <valerio.venturi@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
On Mon, 2006-10-16 at 13:25 -0400, Tom Scavo wrote: 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
Hi, 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 10/16/06, Valerio Venturi <valerio.venturi@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
On Mon, 2006-10-16 at 13:25 -0400, Tom Scavo wrote: 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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
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-... 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@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 10/16/06, Valerio Venturi <valerio.venturi@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
On Mon, 2006-10-16 at 13:25 -0400, Tom Scavo wrote: 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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
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 (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-...
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@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
On Mon, 2006-10-16 at 13:25 -0400, Tom Scavo wrote:
On 10/16/06, Valerio Venturi <valerio.venturi@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,
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
Valerio Venturi wrote, On 10/31/2006 03:21 PM: this is 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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
Hi Joni, On 10/31/06, Joni Hahkala <joni.hahkala@cern.ch> wrote:
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.
No, I wasn't suggesting that VOMS be modified, but I would recommend that any mapping of VOMS ACs to SAML attribute assertions incorporate the notion of "primary" VO membership attribute. There is precedence for this in the SAML world, which is all I was trying to communicate previously. Cheers, Tom
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-...
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@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
On Mon, 2006-10-16 at 13:25 -0400, Tom Scavo wrote:
On 10/16/06, Valerio Venturi <valerio.venturi@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,
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
Valerio Venturi wrote, On 10/31/2006 03:21 PM: this is 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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg -- ogsa-authz-wg mailing list ogsa-authz-wg@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@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 *****************************************************************
On Oct 31, 2006, at 3:59 PM, David Chadwick wrote:
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.
They're different for every voms-proxy-init, which is basically a grid-proxy-init step that contacts a VOMS server. Thus they will be different for every issuance of v-p-i but may be the same across jobs. A typical use case might be that the user wants to submit to a given VO's resources, does a v-p-i with argument -voms (VO VOMS server) including possibly the assertion of group membership or role, does the submissions, which could be a large number. May use that VOMS proxy for an extended period of time for multiple operations. Up[on wanting to switch to a different VO or a different group or role within the VO, does a new voms-proxy-init and gets a new proxy. repeat as necessary. VOMS proxy certs can be extended, destroyed, etc. just as grid proxies. Alan Sill, Ph.D TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
Alan I dont think your use case disagrees with what I am suggesting, which is on every v-p-i the user says which attribute is to be primary one (or not) regards David Alan Sill wrote:
On Oct 31, 2006, at 3:59 PM, David Chadwick wrote:
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.
They're different for every voms-proxy-init, which is basically a grid-proxy-init step that contacts a VOMS server. Thus they will be different for every issuance of v-p-i but may be the same across jobs.
A typical use case might be that the user wants to submit to a given VO's resources, does a v-p-i with argument -voms (VO VOMS server) including possibly the assertion of group membership or role, does the submissions, which could be a large number. May use that VOMS proxy for an extended period of time for multiple operations. Up[on wanting to switch to a different VO or a different group or role within the VO, does a new voms-proxy-init and gets a new proxy. repeat as necessary.
VOMS proxy certs can be extended, destroyed, etc. just as grid proxies.
Alan Sill, Ph.D TIGRE Senior Scientist High Performance Computing Center TTU
==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
-- ***************************************************************** 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@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 *****************************************************************
I agree. Not saying that is the most flexible (or desired) architecture, just saying that is how it works now. In essence, the user decides that attributes he/she wants to assert on a given transaction. Whether or not v-p-i is the most elegant way to achieve this, it does achieve it and it works. Alan On Nov 1, 2006, at 10:02 AM, David Chadwick wrote:
Alan
I dont think your use case disagrees with what I am suggesting, which is on every v-p-i the user says which attribute is to be primary one (or not)
Alan Sill, Ph.D TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
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. 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. 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-...
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@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
On Mon, 2006-10-16 at 13:25 -0400, Tom Scavo wrote:
On 10/16/06, Valerio Venturi <valerio.venturi@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,
> 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
Valerio Venturi wrote, On 10/31/2006 03:21 PM: this is 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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg -- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
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-...
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@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
On Mon, 2006-10-16 at 13:25 -0400, Tom Scavo wrote: > On 10/16/06, Valerio Venturi <valerio.venturi@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,
>> 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
Valerio Venturi wrote, On 10/31/2006 03:21 PM: this is 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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg -- ogsa-authz-wg mailing list ogsa-authz-wg@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@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 *****************************************************************
David Chadwick wrote, On 11/01/2006 10:18 AM:
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.
True, but there is no way of enforcing it and thus you would probably have some nice error situations where there are several primaries within this set of ACs. :)
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?
Correct. I think that currently the primary VO is the VO of the first VOMS AC and the primary group is the first group within this first AC. Of course the VOMS FQAN includes the VO name as the first part of the string, so everything is defined by the first FQAN within the first VOMS AC. I don't know what happens if the first VOMS AC is invalid, if the primary is the first valid FQAN or if that is considered as an error situation.
If this is the case then the "primary" tag would need to be separately shown inside the proxy cert.
Yes, if ordering would not be used as the deciding factor then there would be need for a separate tag either as a proxy extension or within the VOMS extension structure, for example within (or end of) the list of ACs. Cheers, Joni
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-...
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@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@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@ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-authz-wg -- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
Joni Hahkala wrote:
If this is the case then the "primary" tag would need to be separately shown inside the proxy cert.
Yes, if ordering would not be used as the deciding factor then there would be need for a separate tag either as a proxy extension or within the VOMS extension structure, for example within (or end of) the list of ACs.
If this is the case, then I can see little benefit in doing it via the proxy cert, since the AC validating component will need to tag the first attribute in the first AC as the primary one in an internal implementation dependent way, regardless of whether this is based on ordering of the ACs or a tag in the proxy cert. What Frank was suggesting was that the primary flag was incorporated into the attribute type of an AC so that no special implementation dependent way of processing was needed by the service provider. So, I suggest the following as an improved way of working. 1. The user knows prior to job submission which attribute he wants to be his primary one for this grid job. 2. The user contacts the various VOMS servers in any order he chooses and asks for the various attributes to be put into ACs and returned to him. 3. The user signals the VOMS server that holds his primary attribute for this grid job, to flag this chosen attribute as the primary one, and to return this inside the AC marked as the primary attribute (using a method similar to the eduPerson one outlined earlier). 4. The ACs are packaged into the proxy cert in a random order, since now we have a primary flag embedded into one of the attribute types in one of the ACs, so ordering is no longer needed. regards David
Cheers, Joni
regards
David
-- ***************************************************************** 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@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 *****************************************************************
David, are the call-in details the same as on 13 Sep? These were as follows... Thanks, Alan On Sep 30, 2006, at 6:18 AM, David Chadwick wrote:
Frank S circulated a set of numbers to be used in his last email message of 13 Sept. They are
Skype number is <skype:+99008275780044>
If you want to use a regular phone in the US, call *#1-712-432-4000
with
Conference Room Number: *5780044*
It seems they have the following alternative "local" regular phone call-in numbers available for some European countries:
Austria 0820 400 01562 Belgium 0703 59 984 France 0826 100 266 Germany 01805 00 7620 UK 0870 119 2350
Alan Sill, Ph.D TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
We need Frank to confirm that they are. Over to you Frank... David Alan Sill wrote:
David, are the call-in details the same as on 13 Sep? These were as follows...
Thanks, Alan
On Sep 30, 2006, at 6:18 AM, David Chadwick wrote:
Frank S circulated a set of numbers to be used in his last email message of 13 Sept. They are
Skype number is <skype:+99008275780044>
If you want to use a regular phone in the US, call *#1-712-432-4000
with
Conference Room Number: *5780044*
It seems they have the following alternative "local" regular phone call-in numbers available for some European countries:
Austria 0820 400 01562 Belgium 0703 59 984 France 0826 100 266 Germany 01805 00 7620 UK 0870 119 2350
Alan Sill, Ph.D TIGRE Senior Scientist High Performance Computing Center TTU
==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
-- ***************************************************************** 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@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 *****************************************************************
I am connected now (9:00 am US/Central) -- only getting the hold message... Alan On Oct 31, 2006, at 4:00 PM, David Chadwick wrote:
We need Frank to confirm that they are. Over to you Frank...
David
Alan Sill wrote:
David, are the call-in details the same as on 13 Sep? These were as follows... Thanks, Alan On Sep 30, 2006, at 6:18 AM, David Chadwick wrote:
Frank S circulated a set of numbers to be used in his last email message of 13 Sept. They are
Skype number is <skype:+99008275780044>
If you want to use a regular phone in the US, call *#1-712-432-4000
with
Conference Room Number: *5780044*
It seems they have the following alternative "local" regular phone call-in numbers available for some European countries:
Austria 0820 400 01562 Belgium 0703 59 984 France 0826 100 266 Germany 01805 00 7620 UK 0870 119 2350 Alan Sill, Ph.D TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
--
***************************************************************** 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@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
*****************************************************************
Alan Sill, Ph.D TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
participants (7)
-
Alan Sill -
David Chadwick -
Joni Hahkala -
Tom Scavo -
Valerio Venturi -
Von Welch -
Yuri Demchenko