[voms-proc-wg] VOMSPROC WG session and strawman document

[Paul Millar]

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.