Enabling authentication

WARNING : page under construction

Introduction

In this section we describe how to enable authentication for a PROOF cluster. By default authentication is switched off and needs to be explicitely enabled in the xrootd configuration file.

Authentication is performed using the security modules delivered with xrootd. A set of dedicated directives (sec.protocol, sec.protbind, ...) are used to configure security services. By default these directives apply to both services, data-serving and PROOF. However, it is possible to configure differently PROOF authentication by prefixing the 'sec.' directives by 'xpd.' . This is done in the following of this section, so that the sample directives below apply to PROOF only.

Authentication at the different tiers can be configured differently. For example, a system administrator may decide that a client needs to authenticate only to the master, implicity assuming that all workers trust their master. This may be a good assumption for clusters closed from outside, where only the machines but the master are protected by a firewall. However, this may not work if the workers need credentials to access data files: in such a case the client credentials need to be forwarded to workers in a secure way. While it is possible to envisage secure channels to perform this task, usually the easiest way to achieve credential forwarding is to perform authentication at all steps. When all the handshakes are successful the forwarded credentials will be automatically available on all the machines. Credential renewal is another issue that may become relevant at some point. This is not currently implemented.

In the next sections we dissect the settings that allow to achieve credential forwarding in PROOF for the three authentication protocols currently available: password-based, Kerberos, GSI.

All the protocol plug-ins need the general security framework to be loaded, so all the directives below need to be preceded by the following generic directive

xpd.seclib libXrdSec.so

Password authentication

The password-based authentication module can either use a dedicated password file, a user private file (like $HOME/.rootdpass) or the system password file. The way to do this is detailed elsewhere, and will be only recalled here. Credential forwarding in PROOF requires the server to save the credentials somewhere. Xrootd provides the possibility to save them in memory and to retrieve them when needed. For the password-based protocol this is triggered by passing the parameter '-keepcreds' to the sec.protocol line:

xpd.sec.protocol pwd -keepcreds

The credentials are saved in memory and passed to proofserv in hexadecimal form as an environment variable. The above directive expects that the dedicated password file $HOME/.xrd/pwdadmin exists. To use a different file - for example /etc/xrd/pwdadmin - the option '-dir' must be used (the file name must always be 'pwdadmin')

xpd.sec.protocol pwd -keepcreds -dir:/etc/xrd

To enable user-private files for users recognized by the system (i.e. with an entry in /etc/passwd) the option '-upwd' must be used: for example, the following settings to enable the well-known $HOME/.rootdpass files:

xpd.sec.protocol pwd -keepcreds -dir:/etc/xrd -upwd:2 -cryptfile:.rootdpass

Finally, to enable checking against /etc/passwd (or /etc/shadow for systems using shadowed passwords)

xpd.sec.protocol pwd -keepcreds -syspwd

The daemon must be able to read those files, which is typically achieved by starting is as superuser.

AFS

For an AFS-enabled cluster there is the possibility to use the AFS API to authenticate a client. ROOT (and xrootd) must be built enabling AFS, which is done by passing '--enable-afs' to ROOT/configure (the setting is automatically transmitted to xrootd/configure; it requires the dlevel AFS package on RH systems which is not installed by default).

The directive to be used is the same as the one used to enable system password files above. In this case, however, there is no need to start the daemon as superuser. The AFS token will be also instantiated inside the TProofServ instances , so that the master and worker sessions will all be able to access files over AFS, if needed.

Kerberos authentication

Full credential forwarding for a Kerberos-enabled system requires the system to run Kerberos V. This is because, while xrootd provides also a kerberos IV plug-in, it is only with kerberos V that support for forwardable tickets has been provided. The client ticket must be forwardable: this is checked by the plug-in on the client side and the client is asked to re-initialize the token if the forwardable bit is not set.

On the server side, the option '-exptkn[:cache_location]' must be used to request the forwarding of the token and to indicate where to cache it so that it can be used by proofserv. By default the name of the file is /tmp/krb5cc_. The cache location can contain keywords and/or to be expanded on per-user base. The following is a typical setting:

xpd.sec.protocol krb5 -exptkn:/tmp/proof//.creds/krb5cc_  xrd/pcepsft43.cern.ch

the cache with the exported credentials of user 'pippo' with uid 3456 will be created at

/tmp/proof/pippo/.creds/krb5cc_3456

The server automatically exports this path in the variable KRB5CCNAME .

GSI authentication

GSI (Globus Security Infrastructure) authentication uses X509 certificates to perform single sign-on authentication. To enable the creation of a proxy certificate representing the client on the server machine we need to pass the option '-dlgpxy:1'

xpd.sec.protocol gsi -dlgpxy:1

The dlgpxy option requires clients to sign a proxy certificate to be used by the server on their behalf. The proxy certificate is kept in memory and delivered to proofserv via an environment variable.

It may be more appropriate in some cases to export the proxy into a file. This is done using '-dlgpxy:2' and the switch '-exppxy' to control the location of the file; to be fully effective, the environment variable X509_USER_PROXY needs to point to new location; this can be done using the xpd.putenv directive. For example:

xpd.sec.protocol gsi -dlgpxy:2 -exppxy:/tmp/proof//.creds/x509up_u
xpd.putenv X509_USER_PROXY=/tmp/proof//.creds/x509up_u