EDG gatekeeper
Grid job submission and file access using GridFTP have traditionally been protected using a simple version of the Grid Security Infrastructure (GSI). Authorization in traditional GSI is based on a single user access list, explicitly naming individuals that are allowed to access a service. For those services that need a system-local principal associated with the service instance, this list also provides a mapping between the user’s distinguished name and that of the local principal.
The components LCAS (Local Centre Authorization Service) and LCMAPS (Local Credential MAPping Service) discriminate between two functions. The main incentive for this split is to enable global (co-)authorization decisions to be made without the need to interact with system-local credential services. Such local services are likely to be more resource-intensive than the pure authorization decision itself.
In order to provide the LCAS system with the capability to inspect the job request (and take decisions accordingly), the request processing order in the gatekeeper was changed. In the traditional version, authorization took place (and credential mapping was applied) before the job request itself was accepted from the client side. To enable forwarding of the job request to the LCAS plug-ins, all input data are now read in-full, and the job request data are made available to the plug-ins alongside the Grid security context.
The EDG-gatekeeper is the product that contains the patches used to link LCAS and LCMAPS (at run-time) into a GT2.x gatekeeper. The sources are still available at http://jra1mw.cvs.cern.ch/cgi-bin/jra1mw.cgi/fabric_mgt/gridification/edg_gatekeeper/. Similar patches were applied to the gsi-enabled wu-ftpd GridFTP server, see http://jra1mw.cvs.cern.ch/cgi-bin/jra1mw.cgi/fabric_mgt/gridification/edg-gridftpd/.
