[gin-auth] Multiple VO membership (Some ramblings and 1 question).
Mike 'Mike' Jones
mike.jones at manchester.ac.uk
Wed May 3 09:11:07 CDT 2006
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
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.
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
> 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.
>> 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).
More information about the gin-auth