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@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