globus-k5
program, which is invoked when the gatekeeper is started with the
-k
option. The "login" command is associated to a Globus
user ID (X509 DN) via yet another mapping file, the "globuskmap" file.
The name of the globuskmap file needs to be specified as a gatekeeper
option as well (-globuskmap
filename). /etc/globus-gatekeeper.conf
file:-k -globuskmap /etc/globus/etc/globus-kmapfile
.
"/C=IT/O=INFN/L=Milano/CN=Francesco Prelz/Email=francesco.prelz@mi.infn.it" /usr/afsws/bin/klog -principal prelz -password ******* -cell infn.it
The password needs to be specified in cleartext. The file can be made only
readable by root, but even this way this is obviously not an acceptable
solution.
The token lifetime can be specified with the -lifetime
option once for all only by the remote system administrator. There's no
provision for reissuing tokens (the Kerberos V4 token validity
cannot be "extended").
Another caveat: even if the system is able to obtain an AFS token, it's
up to the user to issue the approriate unlog
command
to remove valid tokens from the executing machine cache.
This (extremely bad) way of accessing AFS was tested with the current Globus toolkit and works.
Kerberos V5 provides ways to transfer and extend tickets, plus a
GSSAPI implementation that could be used in place of the Globus GSSAPI. The
trouble is that Transarc (commercial AFS) has no plans to adopt Kerberos V5,
and nobody knows whether OpenAFS will ever get there. There is a rather
makeshift tool, derived from MIT work (ak5log
) that can build
a Kerberos V4 AFS token based on Kerberos V5 authentication information.
This assumes there's a Kerberos V5 authentication infrastructure in
place, and we don't have one.
We could however use another Globus tool (sslk5
) that provides
a client/server pair where the server generates Kerberos V5 tickets
based on Globus (X509) credentials. If access to the user information
AND to the AFS/Kerberos private key is available, one could in
principle generate a V5 ticket based on the AFS private key, then
convert it to a V4 AFS token. Roberto Gomezel will try to understand
whether it is possible/feasible to access to these AFS internals.
Kerberos and GSI are actually two solutions to the same problem. In an ideal world we should have just one of them. The grid "should" provide the same level of delocalized file access that AFS provides.