[gin-auth] Multiple VO membership (Some ramblings and 1 question).

[Dane Skow]

Probably would be a good practice for GIN resources to add the GIN VO  
entries last into their gridmapfiles so the GIN account mapping is  
not used for folks who have access through other VOs. This is  
consistent with the idea that the GIN VO is a bootstrapping VO and  
folks should be moving to use "real" VOs first.

I agree, the path out of this is to move to using the authorization  
information (eg. the VOMS extensions) to do the account mapping. How  
many grids are using that extended mapping today ? on resources they  
intend to make available across grids ?

I'd be very interested in operations experience of anyone who's gone  
the full way to REQUIRING VOMS extensions so that they could do the  
account mapping directly without having to have a gridmapfile preloaded.
Is anyone running that way now ? planning on it soon ? Would sure  
simplify maintenance and would seem reasonable for cross-grid  
resources in my view (though it may be too complex for the users just  
yet).

Dane

On May 3, 2006, at 4:03 PM, Mike 'Mike' Jones wrote:

>
> It dawned on me on the way to work this morning that in the current  
> implementation for accepting grid VOs through VOMS/LDAP/HTTPS where  
> resources construct a 'grid-mapfile', I as a user do not know  
> through which VO I will be accepted onto a resource.  I can find  
> this out by getting an interactive session some how on a resource  
> and poking around, but this is not easy.
>
> This is not a new problem, I know!  But, I can now see that signing  
> up to a low usage VO could mean that I might be expected to adhere  
> to those low usage rules that the VO was accepted for, even though  
> through another VO membership I would be allowed more resource.   
> For me this is now a distinct possibility.
>
> In the GIN case this problem will go away with the VOMS proxy  
> credentials somewhere down the line.  Some JDL might go some way to  
> helping too, but I do not currently know of any JDL-aware  
> middleware at this time that would help.  A resource broker could  
> also address this*, but I believe that so far resource brokers are  
> only aware of the VOs a resource supports and not in what order  
> they have been accepted.
>
> I guess the only immediate way round this is to hope that  
> participating resources all behave in the same way and configure  
> themselves to accept VOs in order of maximum usage.
>
> If I submitted a big job to the LCG (where I have access to the  
> resource) but am mapped to a low usage GIN account will the LCG  
> site my job ends up at try to have my GIN membership blacklisted?
>
> Mike
>
> *I however like to keep the idea that I might not always need or  
> want to go through a broker where the protocols allow.
>
> -- 
> http://www.sve.man.ac.uk/General/Staff/jonesM/