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

[Mike 'Mike' Jones]

Comments on using LCAS and LCMAPS from a production grid (UK NGS is 
my nearest) point of view.

They both look quite usable, but NGS uses VDT middleware, Globus 
Toolkit 2.4.3 or Globus Toolkit 4 Pre Web services.  Patching LCAS and 
LCMAPS into the gatekeepers running on these resources is a bit 
heavyweight. NGS is looking at moving towards it but it's 
still very much in the planning and testing mode.

For the time being I agree with David, we're stuck with grid-mapfiles 
and just have to be very careful.  For the future, perhaps VDT might patch 
the GT gatekeeper and support it like they already do with the EDG pool 
account patch (this would be a really helpful step IMHO).

For GIN Authz to work well it's got to be based upon Authz that resources 
are willing to install.  I believe that LCAS and LCMAPS aren't as yet 
integrated into the common middleware stacks well enough for most 
production resource providers to switch away from mapfiles.

I think the same is true for Shib integration into out current Authz. 
mechanics, assuming middleware of the calibre of GT2, VOMS callouts and 
Shib Callouts aren't going to work without rolling our sleeves up and 
getting out hands dirty!  I think this is perhaps not a production grid 
attitude.

Don't get me wrong though, I like rolling my sleeves up and tinkering 
(Gosh, I hope that idiom translates properly :-S ).  It's just that for an 
inter-operation effort, the more cool stuff we put in there the more sites 
like the UK NGS will have trouble following suit quickly enough.

Mike

On Wed, 3 May 2006, Oscar Koeroo wrote:

> Hi David,
>
> There are some solution already in production status.
>
>
> David Bannon wrote:
>
>> Dane, we've been looking at that but have decided, at least for now, the
>> end to end use is just not ready. So we'd dependant on gridmap files and
>> they really are a very, very blunt weapon!
>> 
>> The issues :
>> 
>> 1. Gridmap files don't allow a user to be in several VOs and chose at
>> launch time.
>> 
>> 2. VOMRS allows users to put themselves into any group/role they wish.
>> Indications are that this will be fixed in a July release.
>> 
> There is also VOMS Admin software, where only the VO-Admin can set the 
> groups/roles according to its own desire and for the GIN VO there is no use 
> of VOMRS only the VOMS Admin.
>
>> 3. Nothing seems to adequately interpret VOMS attributes at the glous
>> level.
>> 
> We have, the VOMS-api-c stuff, the c++ libs, there is Bouncycastle where the 
> Java version for VOMS extraction is, there is the Globus VOMS PDP.
>
> For implementation: one can look at LCAS (pure authZ) and its VOMS module and 
> how that works for example, and for DN+VOMS to uid/gid(s) translation there 
> is LCMAPS and GUMS and probably some more...
>
>
> Maybe I didn't understand the context.
>
>
> cheers,
>
>   Oscar
>
>> David
>> 
>> On Wed, 2006-05-03 at 16:36 +0800, Dane Skow wrote:
>> ....
>> 
>>> 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
>>> 
>>
>> 
>
>

-- 
http://www.sve.man.ac.uk/General/Staff/jonesM/