GAMA Seeks to Simplify the User's Security Experience

Published 03/13/2006

The Globus Consortium Journal
March 2006

Interviews guest experts:

Kurt Mueller
Researcher, San Diego
Supercomputer Center

Abel Lin
Technical Lead for the Telescience Project

In geology and microscopy, Grid users are showing interest in a new GSI credential management and integration solution that "makes Grid security as easy to use as any commercial web site, while maintaining the security and delegation capabilities of GSI." This month, the GCJ caught up with Kurt Mueller, the lead developer behind the GAMA ( Grid Account Management Architecture ) project, and Abel Lin, the lead developer of the Telescience Portal, to learn more.

GCJ: Can you talk about the genesis of Grid Account Management Architecture (GAMA)? What motivated the project?

Mueller: Grid systems rely on a collection of back-end software packages to create and manage Grid credentials for users. Installation and maintenance of these packages can be complicated for system administrators, and oftentimes users are required to explicitly manage their own Grid credentials through command-line interfaces. Our idea was to package the required tools together, make them easy to install, and then provide a nice user interface for users to request accounts, and for administrators to manage the whole account approval process. We provide a web services interface to the entire server infrastructure, so that the Grid can be accessed by many different types of client applications, including web portals, stand-alone applications, handheld devices, etc.

Basically, GAMA unifies a number of Grid components into a single tool, making Grid security as easy to use as any commercial Web site while maintaining the security and delegation capabilities of GSI. It provides an appropriate, simplified interface to end users, and to portal and application developers.

Lin: We started out designing GAMA from the end user's perspective, making it easier to use. But along the way, it was apparent that with this service interface, it also became a lot easier for our applications developers to use as well. Ultimately we want the Grid to expand beyond the applications folks who are actually interested in the Grid, but also to folks who might not be as interested in the Grid yet require their code to be launched out within this infrastructure. Most of these people didn't really care about the complexities of something like GSI or how it worked. They just wanted a single function that allows them to log on and do whatever they needed to do. GAMA provides that sort of functionality.

GCJ: The Telescience Project and the Geosciences Network are two of your big installations. Can you tell us about how GAMA works in those two Grid sites?

Lin: The Telescience Project started out as a project to remotely enable instrumentation use for our end users. We had these big electron microscopes that are pretty rare and distributed across the states, and the idea was how could we get users to log onto the system without being physically located in front of the instrument? After a few years, we realized that although it's great they can use the instrument remotely, why not give them a system where they could also go down the line and compute and visualize and manage their data as well? With GAMA - now there's a web portal where users can sign on, control the instrument, launch jobs on the TeraGrid resources, and manage jobs using something like SRB ( Storage Resource Broker).

Mueller: The Geosciences Network ( GEON) is a collection of research groups in the field of geoinformatics. Its aim is to help scientists in this distributed collaboration who have a lot of different plate tectonics data and other geology-related data. They want to share this data, and do analysis on it. Like the Telescience Project, they need a secure way to log into a portal interface that's been constructed for them. They need security when they access Grid resources, such as the database that's exposed through the system and the compute resources that they're using for their modeling.

So the requirements of both the Telescience Project and GEON are similar. They're both using a Globus infrastructure for management, so they can also benefit from GAMA. In fact, GEON is one of the pilot applications that really helped us in the early development of GAMA.

GCJ: Have you made any progress with the implementation of user authorization tools in GAMA?

Mueller: GAMA originally did support CAS ( community authorization service), and it's still built into the GAMA that you can download now. However, it was never proven to be useful to the end application developers because the rest of the tools that they needed in order to make use of CAS-signed GSI certificates were not in place and were not stable at the time we developed GAMA, which was a year and a half ago. The release of GAMA 2, which should be available in the next few months, will support other sorts of authorization mechanisms.

GCJ: Can you elaborate a bit more on the differences between GAMA 1 and GAMA 2?

Mueller: GAMA 1 was constructed for a very specific purpose, and for specific application groups. It was created exactly to their specifications without a lot of thought put into making it more widely useful to other groups who might want to adopt it for their own purposes. Specifically, we were supporting a CA system developed at SDSC for credential creation. We were supporting MyProxy for credential storage and CAS for the authorization system.

This technology was used by the projects we supported, but of course there may be other people who want use the software that have their own existing infrastructures; they may already have a certificate management system, they may already have users with certificates in place, and they may have additional sorts of systems that are already installed at their locations. They may have an LDAP server that they use for authentication. They may support SRB, and they may need SRB accounts for users. So GAMA 2 has removed all of the hard coding of the very specific technologies we implemented for GAMA 1 and has replaced that with a plug-in system whereby people who use and implement GAMA at their site can, without much difficulty, create a custom plug-in that will do whatever task they need. They can create a plug-in for their existing LDAP authentication infrastructure, or they can create a plug-in to interface with their SRB account system, for example.

Unlike GAMA 1, which has a singular log-in function, GAMA 2 includes the notion of sequences of tasks that are designed in a work flow manner to perform a single function. With GAMA 2, a log-in could consist of retrieving a credential from MyProxy, opening a socket connection to an SRB server, and retrieving some other information from an LDAP server all at once. So the administrator of GAMA will be able to combine smaller tasks into more complex sequences and make those available, through simple Web services interfaces, to any applications or portals or other GAMA clients. We are increasing the ability of GAMA significantly and making it easier to use and integrate with existing infrastructures.