Dear all, In preparation for the VOMSPROC WG session, the Redmine project for the WG has been populated (finally), and the list of documents and the agreed rough outline added to the Wiki http://redmine.ogf.org/projects/voms-proc-wg/wiki There is also a strawman document for the first work item ("VOMS Attribute Certificate Parsing Rules for Chained Identity Credentials") which I admit it incomplete (it lacks a description of how today the 'primary FQAN' is determined), but at least should have enough controversial material in it to trigger discussion. Please go to the OGF redmine project at http://redmine.ogf.org/projects/voms-proc-wg and forward this information as relevant. Everyone is welcome to subscribe to the mailing list (http://www.ogf.org/pipermail/voms-proc-wg/) and lets hope we can get this done. In particular, we will soon need a discussion on the second work item regarding SAML delegation and how to interpret effective attributes in that context. VOMS can produce SAML statements, but I think the issue is slightly wider and would benefit from such wider input. Hope to see many of you at the VOMSPROC WG session! Best, DavidG. -- David Groep ** Nikhef, Dutch National Institute for Sub-atomic Physics,PDP/Grid group ** ** Room: H1.50 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **
Hi David, just a couple of preliminary comments (unfortunately I will not attend the meeting) - I've already shared at large my perplexities about having more than one AC in the VOMS extension. I think that was a design flaw. There are no use cases. The VOMS AC format and all documents in preparation should be updated to address this flaw, as the VOMS libraries are. - Computing the intersection of a set of attributes coming from several ACs in the chain poses the problem of stating how the order of the attributes is computed when is different in the ACs. The document should address this, e.g. proposing that the the order of the AC result of the original user delegation is enforced. Cheers, Andrea Il 10/10/12 21.47, David Groep ha scritto:
Dear all,
In preparation for the VOMSPROC WG session, the Redmine project for the WG has been populated (finally), and the list of documents and the agreed rough outline added to the Wiki
http://redmine.ogf.org/projects/voms-proc-wg/wiki
There is also a strawman document for the first work item ("VOMS Attribute Certificate Parsing Rules for Chained Identity Credentials") which I admit it incomplete (it lacks a description of how today the 'primary FQAN' is determined), but at least should have enough controversial material in it to trigger discussion.
Please go to the OGF redmine project at http://redmine.ogf.org/projects/voms-proc-wg and forward this information as relevant. Everyone is welcome to subscribe to the mailing list (http://www.ogf.org/pipermail/voms-proc-wg/) and lets hope we can get this done.
In particular, we will soon need a discussion on the second work item regarding SAML delegation and how to interpret effective attributes in that context. VOMS can produce SAML statements, but I think the issue is slightly wider and would benefit from such wider input.
Hope to see many of you at the VOMSPROC WG session!
Best, DavidG.
-- INFN-CNAF --------- Andrea Ceccanti Via Ranzani 13/2 40127 Bologna, Italy phone: +39 051 6092845, fax: +39 051 6092916 skype: andreaceccanti andrea.ceccanti@cnaf.infn.it
Hi Andrea, all On 2012-10-11 10:39, Andrea Ceccanti wrote:
- I've already shared at large my perplexities about having more than one AC in the VOMS extension. I think that was a design flaw. There are no use cases. The VOMS AC format and all documents in preparation should be updated to address this flaw, as the VOMS libraries are.
The multiple-VO eature might actually be useful if only to copy data between two VOs by the user, but I think Mike as some actual current use cases for it. Generalising, the VOMS ACs are just a source of attribute, and as long as you can identify which attributes come from which source (the FQANs and tags are scoped to the VO), I don't yet see why this would be a design flaw ;-)
- Computing the intersection of a set of attributes coming from several ACs in the chain poses the problem of stating how the order of the attributes is computed when is different in the ACs. The document should address this, e.g. proposing that the the order of the AC result of the original user delegation is enforced.
Fully agree: the ordering section of the document is still missing, and we should think about what a user 'expects' in this case. Should a downstream service be able to 'select' a new primary FQAN by itself (i.e. on a service then selecting a new primary when writing data files)? But then the user may not 'know' this was to happen. I can see cases for either option, and the document should indeed be explicit in what is to be allowed. And: thanks a lot for the comments! Cheers, DavidG.
Cheers, Andrea
Il 10/10/12 21.47, David Groep ha scritto:
Dear all,
In preparation for the VOMSPROC WG session, the Redmine project for the WG has been populated (finally), and the list of documents and the agreed rough outline added to the Wiki
http://redmine.ogf.org/projects/voms-proc-wg/wiki
There is also a strawman document for the first work item ("VOMS Attribute Certificate Parsing Rules for Chained Identity Credentials") which I admit it incomplete (it lacks a description of how today the 'primary FQAN' is determined), but at least should have enough controversial material in it to trigger discussion.
Please go to the OGF redmine project at http://redmine.ogf.org/projects/voms-proc-wg and forward this information as relevant. Everyone is welcome to subscribe to the mailing list (http://www.ogf.org/pipermail/voms-proc-wg/) and lets hope we can get this done.
In particular, we will soon need a discussion on the second work item regarding SAML delegation and how to interpret effective attributes in that context. VOMS can produce SAML statements, but I think the issue is slightly wider and would benefit from such wider input.
Hope to see many of you at the VOMSPROC WG session!
Best, DavidG.
-- David Groep ** Nikhef, Dutch National Institute for Sub-atomic Physics,PDP/Grid group ** ** Room: H1.50 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **
Hi all, I haven't read the document yet (sorry, but it is on the list) On 10/11/2012 06:08 PM, David Groep wrote: [...]
- Computing the intersection of a set of attributes coming from several ACs in the chain poses the problem of stating how the order of the attributes is computed when is different in the ACs. The document should address this, e.g. proposing that the the order of the AC result of the original user delegation is enforced.
Fully agree: the ordering section of the document is still missing, and we should think about what a user 'expects' in this case. Should a downstream service be able to 'select' a new primary FQAN by itself (i.e. on a service then selecting a new primary when writing data files)? But then the user may not 'know' this was to happen. I can see cases for either option, and the document should indeed be explicit in what is to be allowed.
Just a comment on what dCache does, which may be relevant. (I can't remember, have I already said this?) We take the first FQAN as primary and all others as non-primary. If there are multiple ACs then (iirc) the first FQAN of the first AC is primary and all others (from all other ACs) are non-primary. We do not preserve the order of FQANs, only that one is primary and the others are not. In the ideal situation, the primary FQAN is mapped to a primary gid and all non-primary FQANs are mapped to non-primary gids. A primary gid is used to determine what group-owner newly written files will have. All gids (primary and non-primary) may be used to authorise an operation (e.g., read a file). dCache requires that all users have a primary gid. If there is no mapping for the primary FQAN then we adopt (what we hope is) a "principle of least surprise" algorithm. We define the 'parent FQAN' as the FQAN formed by removing the last element if it has more than one element; for example, "/atlas/higgs" is the parent of "/atlas/higgs/Role=production", "/atlas" is the parent of "/atlas/higgs", and there is no parent of "/atlas". Since FQANs are hierarchical and a VOMS server always returns all group-membership it is guaranteed that if an FQAN is present (in the set of FQANs from the VOMS server) then the parent FQAN, if it exists, is also present. The "least surprise" algorithm is that, if there is no mapping from the primary FQAN to a gid then the parent FQAN is tried. This continues until a mapping is found or the FQAN has no parent. So, if the user has an AC with "/atlas/higgs/Role=production", we try mapping "/atlas/higgs/Role=production", if that fails, we try "/atlas/higgs" and, if that fails, we try "/atlas". Currently, if the "least surprise" algorithm fails to find a primary gid then another FQAN that has a mapped gid is promoted to be the primary FQAN. The choice of which FQAN, although deterministic, is "unspecified". Although it is unlikely (given current usage) for the least surprise algorithm to fail, leaving the behaviour as unspecified is unsatisfactory. Some other behaviour options are: a) Fail the request outright, b) Remove the primary-gid requirement and demote the user to read-only access, c) Use the next-in-sequence FQAN as primary FQAN. I think this boils down to a question of what is the intended semantics of FQANs. Are they an ordered list or not? (I think currently, the answer is "sometimes, for some of them") For me, it seems that options a) or b) would be preferable, but I'm interested what other people think. Cheers, Paul.
Hi Paul, Il 12/10/12 15:49, Paul Millar ha scritto:
Hi all,
I haven't read the document yet (sorry, but it is on the list)
On 10/11/2012 06:08 PM, David Groep wrote: [...]
- Computing the intersection of a set of attributes coming from several ACs in the chain poses the problem of stating how the order of the attributes is computed when is different in the ACs. The document should address this, e.g. proposing that the the order of the AC result of the original user delegation is enforced.
Fully agree: the ordering section of the document is still missing, and we should think about what a user 'expects' in this case. Should a downstream service be able to 'select' a new primary FQAN by itself (i.e. on a service then selecting a new primary when writing data files)? But then the user may not 'know' this was to happen. I can see cases for either option, and the document should indeed be explicit in what is to be allowed.
Just a comment on what dCache does, which may be relevant. (I can't remember, have I already said this?)
We take the first FQAN as primary and all others as non-primary. If there are multiple ACs then (iirc) the first FQAN of the first AC is primary and all others (from all other ACs) are non-primary.
We do not preserve the order of FQANs, only that one is primary and the others are not. I like how you define primary FQAN (first fqan of first AC).
In a single AC FQANs are ordered by definition. voms-proxy-init provides an option to request a specific ordering from the server, applications could take advantage of that. In practice people just rely on the primary FQAN. However the point above is different, and is related to how the VOMS ACs are extracted and parsed from a chain. Currently VOMS attributes are extracted only from the VOMS extension found in the latest delegation in the chain. The proposal instead suggests AFAIU that all the valid ACs in the chain (not only the one in the latest delegation) are considered when parsing to ensure that the attributes returned are a subset of the attributes originally requested by the user from the VOMS server. In the end the application will always have an ordered list of ACs as result, that can be processed as you are describing now, but such list will be composed from several "levels" in the chain, not simply taken from the last delegation. VOMS APIs will do this composition work for you. However, this composition needs to be properly defined not only to ensure that the attributes returned are a subset of the ones originally requested but also to address the ordering (which may be different at different levels of the chain). The more natural approach to me is to keep the order as originally requested by the user. Other approaches are also possible and will be discussed here, I guess. Cheers, Andrea
Hi Andrea
No comment on your first comment but on the second, we are going to come up
with a precise description version of the algorithm. The current doc is
meant to outline the idea and we then make it more precise (no doubt
discovering interesting questions that we had not thought about before in
the process.)
Cheers
--jens
On Oct 11, 2012 4:34 AM, "Andrea Ceccanti"
Hi David,
just a couple of preliminary comments (unfortunately I will not attend the meeting)
- I've already shared at large my perplexities about having more than one AC in the VOMS extension. I think that was a design flaw. There are no use cases. The VOMS AC format and all documents in preparation should be updated to address this flaw, as the VOMS libraries are.
- Computing the intersection of a set of attributes coming from several ACs in the chain poses the problem of stating how the order of the attributes is computed when is different in the ACs. The document should address this, e.g. proposing that the the order of the AC result of the original user delegation is enforced.
Cheers, Andrea
Il 10/10/12 21.47, David Groep ha scritto:
Dear all,
In preparation for the VOMSPROC WG session, the Redmine project for the WG has been populated (finally), and the list of documents and the agreed rough outline added to the Wiki
http://redmine.ogf.org/**projects/voms-proc-wg/wikihttp://redmine.ogf.org/projects/voms-proc-wg/wiki
There is also a strawman document for the first work item ("VOMS Attribute Certificate Parsing Rules for Chained Identity Credentials") which I admit it incomplete (it lacks a description of how today the 'primary FQAN' is determined), but at least should have enough controversial material in it to trigger discussion.
Please go to the OGF redmine project at http://redmine.ogf.org/**projects/voms-proc-wghttp://redmine.ogf.org/projects/voms-proc-wg and forward this information as relevant. Everyone is welcome to subscribe to the mailing list (<http://www.ogf.org/**pipermail/voms-proc-wg/http://www.ogf.org/pipermail/voms-proc-wg/
) and lets hope we can get this done.
In particular, we will soon need a discussion on the second work item regarding SAML delegation and how to interpret effective attributes in that context. VOMS can produce SAML statements, but I think the issue is slightly wider and would benefit from such wider input.
Hope to see many of you at the VOMSPROC WG session!
Best, DavidG.
-- INFN-CNAF --------- Andrea Ceccanti Via Ranzani 13/2 40127 Bologna, Italy phone: +39 051 6092845, fax: +39 051 6092916 skype: andreaceccanti andrea.ceccanti@cnaf.infn.it
______________________________**_________________ voms-proc-wg mailing list voms-proc-wg@ogf.org https://www.ogf.org/mailman/**listinfo/voms-proc-wghttps://www.ogf.org/mailman/listinfo/voms-proc-wg
participants (4)
-
Andrea Ceccanti -
David Groep -
Jens Jensen -
Paul Millar