[gin-auth] Debugging Globus SSL (Was: Re: start Savannah run)

[Mike 'Mike' Jones]

Hi JP,

The approach we took in the UK NGS was to head down the pool accounts 
method (a patched gatekeeper and gridFTP server e.g. from the VDT). NGS 
has had VOMS Authz on the road-map for some time and either pool accounts 
or just-in-time account creation are the only ways in which VOMS makes 
sense in our current operating environment. (btw, I do not believe there 
is an off-the-shelf production JIT account creation system available at 
the moment).

With the pool account approach there are two options either to lease 
and recycle accounts or to create a set of accounts that number more than 
the VO can use.  Recycling is hard to do securely: processes and files 
e.g. crontab, ~/.ssh/authorized_keys and all other persistent and 
temporary personal files all need to be removed across all a resources batch 
systems before a lease can be relinquished.

NGS chose to go the route of the pool account patch some time ago, so 
the infrastructure has been available throughout the GIN project.  For 
other members of GIN this will not be so easy: the security implications 
of pool accounts have only really been explored within the Grid community. 
Experience suggests that existing service providers don't like the grid 
security models. That is, amongst others, the hosting of unfamiliar 
services, the breaching firewalls and the adoption of abstract 
authorisation methods and trust models. These all frighten the willies out 
of our production system managers.

That said the UK NGS uses the pool account methods and assign accounts to 
incoming authorised gin members.  There are, I believe, 50 static accounts 
on each core resource.  These are not recycled; they are assigned once. 
When they run out NGS will have to make a decision to create more, or 
further explore the recycling possibilities, This seems to be 
a semi-technical -- semi-political decision.

I can't really say what resources like the TG should do to address authZ 
(authS!) other than to relay our experiences. But, as a "grid savvy" user 
I would be very worried about who has access to my files and delegated 
credentials before using a resources which is on one of our grids.

We must literally avoid leading our potential users into a false sense of 
security.

I'd like to hear what other resource providers of the GIN team are doing 
for authZ. Maybe the way forward is to summarise/these authZ experiences, 
and derive the various weaknesses and lacking functionalities.  Are 
resources polling the VOMS servers? Are accounts mapped on the fly? Do 
sites understand VOMS ACs? What versions of gatekeepers are we using 
(patched unpatched branched)? Can we compare and contrast systems like 
LCAS/LCMAPS and GUMS/PRIMA? etc. etc.

Cheers,
Mike

On Mon, 5 Feb 2007, JP Navarro wrote:

> On Feb 5, 2007, at 5:00 AM, Mike 'Mike' Jones wrote:
>> By the way, mapping all users to one account is a serious security flaw.
>
> Mike,
>
> You are very correct.  My understanding is that mapping all GIN users to
> a single account was a temporary approach to get GIN off the ground. It
> certainly wasn't intended to be a long-term solution, or to be used for
> more than proof-of-interoperability demos.
>
> Perhaps it is now time to come up with a more secure long term solution
> for GIN participants.  Since there are only a few GIN users today, should
> we create individual accounts for all GIN users on all GIN participating
> grids?  Or is there a better option that will scale better? Any suggestions
> on what that next, more secure, approach should be?
>
> Regards,
>
> JP
> ------------------------------------------------------------------------------
> John-Paul Navarro                                               (630) 
> 252-1233
> navarro at mcs.anl.gov 
> http://www.mcs.anl.gov/~navarro
> TeraGrid Software Integration                Univ of Chicago/Argonne Nat. 
> Lab.
> GPG: 4EA9 C86B C0F0 113D 6306  98B7 3649 D6CB EFA8 4133
>
>
>
>
>
>