"SfR Fresh" - the SfR Freeware/Shareware Archive

Member "root/README/README.GLOBUS" of archive root_v5.20.00.win32gcc.tar.gz:


As a special service "SfR Fresh" has tried to format the requested source page into HTML format using source code syntax highlighting with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. That can be also achieved for any archive member file by clicking within an archive contents listing on the first character of the file(path) respectively on the according byte size field.
    1 
    2 Using Globus certificates to authenticate to a remote rootd/proofd server
    3 =========================================================================
    4 
    5 To use Globus certificates for remote authentication, the Globus Tool Kit
    6 should  be installed both in client and server machines and ROOT should be
    7 compiled with  the relevant flags set (see below).
    8 
    9 Globus Authentication has been tested for the moment only on Linux.
   10 
   11 1) Globus Tool Kit (GTK) Version
   12 
   13    The interface has been developed using GTK version 2.2.3 and tested on
   14    machines with version 2.0, 2.0.21b, 2.4.3 and 3.2.1; it should work with
   15    versions 2.x and 3.x, at least until the C API's are kept ; however,
   16    vanilla versions 2.2.3 - 2.4.3 contain a bug which does not allow to 
   17    overload at the same time the defaults for the user certificate
   18    and key files. A patch has been provided by the Globus team (see Globus
   19    bugzilla #892) which is shipped with ROOT.
   20 
   21    If your system does not have GTK installed, you do not need to install
   22    all the GTK bundles but only the GSI one, i.e.
   23 
   24         globus-gsi-<GTK_version>-src_bundle.tar.gz
   25 
   26    Versions older than 2.1.2 and 3.x versions do not have a separate bundle
   27    for GSI: in such a case you need to install the 
   28 
   29         globus-resource-management-client-<GTK_version>-src_bundle.tar.gz
   30 
   31    If you plan to install binaries, the relevant code should be contained in
   32    the 
   33 
   34         globus-resource-management-client-<GTK_version>-<arch>-bin.tar.gz
   35 
   36    bundle.
   37    Please, refer to www.globus.org for any additional information about 
   38    installation and certificate acquisition. 
   39 
   40 2) Compiling ROOT with Globus support
   41 
   42    To compile ROOT with Globus support make sure, *before* running 'configure',
   43    that the environment variable GLOBUS_LOCATION is defined and points to the
   44    location with the 'bin', 'lib' and 'include' dirs for the GTK; 'configure'
   45    should then pickup the correct paths. While it is definitely better to have
   46    GLOBUS_LOCATION defined correctly (especially on the client side), for
   47    compilation purposes only it is possible to force a specific directory for
   48    GTK running 'configure' with
   49 
   50        --with-globus-dir=<GTK_path>
   51 
   52    The 'configure' script checks if the used GTK needs the patch mentioned 
   53    above. While running configure you should get the following printed
   54 
   55  ...
   56 Checking for globusdir ... no
   57 Checking for GLOBUS_LOCATION ... <GLBSLOC>
   58 Checking for openssl/x509.h ... <GLBSLOC>/include/<flavour>
   59 Checking for openssl/pem.h ... <GLBSLOC>/include/<flavour>
   60 Checking for globus_gss_assist.h ... <GLBSLOC>/include/<flavour>
   61 Checking for globus_gss_common.h ... <GLBSLOC>/include/<flavour>
   62 Checking for globus_gsi_credential.h ... <GLBSLOC>/include/<flavour>
   63 Checking for gsi version ... yes
   64 Checking for libglobus_gss_assist_<flavour> ... <GLBSLOC>/lib
   65 Checking for libglobus_gssapi_gsi_<flavour> ... <GLBSLOC>/lib
   66 Checking for libssl_<flavour> ... <GLBSLOC>/lib
   67 Checking for libcrypto_<flavour> ... <GLBSLOC>/lib
   68 Checking for libglobus_gsi_credential_<flavour> ... <GLBSLOC>/lib
   69 Checking for globus-user-env.sh ... <GLBSLOC>/etc
   70 Checking for grid-proxy-init ... <GLBSLOC>/bin
   71 Checking pkg_data_<flavour>_rtl.gpt ... <GLBSLOC>/etc/globus_packages/globus_gsi_credential
   72 Checking for of globus patch ... yes, version <globus_gsi_credential version>
   73 Checking for patch version consistency ... yes
   74 Checking for globus_gsi_system_config.h ... <GLBSLOC>/include/<flavour>
   75 Checking for globus_gsi_cert_utils.h ... <GLBSLOC>/include/<flavour>
   76 Applying experimental patch to globus_gsi_credential.c
   77  ...
   78 
   79    where <flavour> is either gcc32 or gcc32dbg, and <GLBSLOC>
   80    is the env $GLOBUS_LOCATION. 
   81    The last 3 lines appear only if the patch is needed and activated.
   82 
   83    If globus_gsi_credential.c does not compile correctly, it may be that
   84    the patch version found by configure is not correct. Check in the 
   85    globusauth/src/patches/globus_gsi_credentials/README if the printed
   86    <globus_gsi_credential version> matches the one expected for your 
   87    GTK version (ask the latter to your site administrator if you do not
   88    it). If the version is wrong you should copy the right patched version
   89    of the globus_gsi_credentials.c file
   90 
   91 cd  globusauth/src
   92 cp -rp patches/globus_gsi_credentials/<right version>/globus_gsi_credentials.c .
   93 cd ../..
   94 
   95    and substitute the right version for the wrong one in the variable 
   96    GLBPATCHFLAGS defined in config/Makefile.config; re-compile *without* 
   97    running configure. If the problem persists, mailto: gerardo.ganis@cern.ch.
   98 
   99 3) Before running, after compilation/installation
  100 
  101    3.1) On the CLIENT side
  102 
  103         Make sure that valid certificates are in the correct places and that
  104         valid credentials can be initialized; this can be tested by running
  105 
  106                grid-proxy-init
  107 
  108         and entering the pass phrase; you may have to source the relevant shell
  109         file to have this command recognized:
  110 
  111            source $GLOBUS_LOCATION/etc/globus-user-env.csh
  112         or
  113            source $GLOBUS_LOCATION/etc/globus-user-env.sh .
  114 
  115         If you are sure about your capabilities to get valid credentials, you
  116         don't need to initialize them outside the root session, for ROOT checks
  117         the credentials and prompts for the pass phrase if they are missing or
  118         invalid.
  119 
  120         There are three files/dirs relevant for proxy initialization:
  121 
  122         a) user certificate file; default is $HOME/.globus/usercert.pem ; can
  123            be  changed by setting the variable "X509_USER_CERT" to the full
  124            path
  125 
  126         b) user private key file; default is $HOME/.globus/userkey.pem ; can
  127            be  changed by setting the variable "X509_USER_KEY" to the full path
  128 
  129         c) directory with certificates of the known Certificate Authorities;
  130            default is /etc/grid-security/certificates ; can be changed by
  131            setting the variable "X509_CERT_DIR" to the full path.
  132 
  133         All this variables can be changed by the user before running root or
  134         during a root session. Globus authentication can be requested by:
  135 
  136         1) Setting
  137 
  138                 Rootd.Authentication   3
  139                 Proofd.Authentication   3
  140 
  141            in the $HOME/.rootrc file; other parameters can be changed at this
  142            level:
  143 
  144           - the proxy duration, in hours
  145 
  146                 Globus.ProxyDuration :    <hours>
  147 
  148           - the number of bits to be used for the key (should be a power of 2)
  149 
  150                 Globus.ProxyKeyBits:      1024
  151 
  152           - a Globus login defining the relevant files mentioned above:
  153 
  154                 Globus.Login:             cd:~/.globus cf:usercert.pem  \
  155                                           kf:userkey.pem  ad:certificates
  156 
  157                 with the meaning of the different keys being:
  158 
  159                 "cd"    defines the directory with the user certificate and
  160                         private key; default: $HOME/.globus
  161                 "cf"    user certificate file (in the dir specified by "cd");
  162                         default: usercert.pem
  163                 "kf"    user key file (in the dir specified by "cd");
  164                         default: userkey.pem
  165                 "ad"    directory with certificates of the known Certificate
  166                         Authorities; default: /etc/grid-security/certificates
  167 
  168                 Both "cd" and "ad" can be given as absolute paths (starting
  169                 with '/'), relative to  $HOME (starting with ~/) or relative to
  170                 $HOME/.globus (in the other cases).
  171 
  172         2) Specifying an entry in .authrootrc (see README.AUTH for more details)
  173 
  174            This allows to be host and user specific and to initialize proxies
  175            for two or more different users in the same session.
  176 
  177         3) During a ROOT session by creating (or modifying) a THostAuth
  178            instantiation (see README.AUTH for more details)
  179 
  180         Upon successful authentication the user is logged on remotely with the
  181         user name  specified in the gridmap file on the remote server; if there
  182         is no entry is found in  the gridmap corresponding to the client DN, an
  183         attempt is made to guess it from the  CN part of the DN.
  184 
  185 
  186    3.2) On the SERVER side
  187 
  188         The servers daemons (rootd/proofd/TServerSocket) need a valid service-type 
  189         certificate and key pair to handshake mutual authentication with the
  190         client.
  191 
  192         By default, the search for a such a certificate/key pair is done in
  193         the following order:
  194 
  195           - ROOT specific {certificate,key} under /etc/grid-security/root;
  196             file names: rootcert.pem, rootkey.pem ;
  197 
  198           - host {certificate,key} under /etc/grid-security;
  199             file names: hostcert.pem, hostkey.pem ;
  200 
  201           - user proxy {certificate,key} under /tmp, file name: x509up_<uid>;
  202 
  203         The reason to have the last one is to allow unprivileged users to
  204         run GSI authentication for their own local server. Make sure that
  205         the time validity of the proxy is long enough for the purposes of 
  206         the server. Proxies can initialized for any time duration (within
  207         the time validity of the certificate) with
  208              
  209             grid-proxy-init -valid <large_number_of_hours>:0
  210 
  211         The proxies *must be* initialized before the daemon tries to use
  212         them, i.e. there is no prompt for proxy initialization as on the 
  213         client side.
  214 
  215         Any other service certificate may be used in place of the ROOT one:
  216         the important point is that the key file can be read by the daemon.
  217         To create a request for a ROOT specific certificate use
  218 
  219         grid-cert-request -service root -host <machine_FQDN>
  220 
  221         The certificate request will be placed under /etc/grid-security/root .
  222         If you do not have write permission of /etc/grid-security, you can
  223         redirect grid-cert-request to write on a different directory using
  224         '-dir <alternative_directory'.
  225 
  226         Alternative location(s) for the certificates to use can be specified
  227         by means of the hostcert.conf file. By default this file is searched
  228         for in /etc/root/hostcert.conf or in $ROOTSYS/etc/hostcert.conf .
  229         However, daemon servers accept the argument
  230 	    
  231                         -C <server_globus_conf_file>
  232 
  233         to specify an alternative location; for daemons based on TServerSocket
  234         the ROOT environment variable 
  235 
  236                         SrvAuth.HostCert <server_globus_conf_file>
  237 
  238         is provided.
  239         The hostcert.conf contains record lines specifying
  240 	    
  241         <certificates_dir> <host_cert_file> <host_cert_key> <grid_mapfile>
  242 	    
  243         See the header of $ROOTSYS/etc/hostcert.conf for any details about
  244         the syntax and sue of the file; as an example:
  245 	    
  246 < bof >
  247 # This is an example of hostcert.conf to use the ldap service certificate
  248   * /etc/grid-security/ldap/ldapcert.pem /etc/grid-security/ldap/ldapkey.pem *
  249 < eof >
  250 
  251         This file provides also a convenient way to specify certificate settings
  252         corresponding to different Certificates Authorities and potentially
  253         to different DN-to-UserName mappings. When a request for globus
  254         authentication arrives, the daemons look among their own certificates
  255         if there is one issued by the same CA which has issued the client
  256         certificate; if the search is successful they communicate the related
  257         subject name to the client and setenv the relevant variables using to
  258         the chosen configuration set.
  259 
  260         The hostcert.conf file can also be used to specify non-standard locations
  261         for the user proxy files.
  262 
  263 
  264         .2.1) Using user proxies when running as 'root' (or with su privileges)
  265 
  266         If a valid host certificate is not available, the server administrator 
  267         can still decide to run as 'root' and use the valid proxies of a user
  268         registered on the machine to authenticate a client. 
  269         To activate this, the user certificate and key location should be
  270         specified in the relevant hostcert.conf file, e.g.
  271 
  272         < bof >
  273         # This is an example of hostcert.conf ...
  274          * /home/<user>/.globus/usercert.pem /home/<user>/.globus/userkey.pem *
  275         < eof >
  276 
  277         The program will then look for the proxy file associated with the owner
  278         of the certificate and key files and use that to acquire the credentials
  279         needed for authentication; as above, the proxies must be initialized
  280         before the relevant software tries to use them.
  281 
  282 4) Trying out
  283 
  284    Trying to access a remote file should give this on the client side (assuming
  285    globus credentials have not been initialized before):
  286 
  287 root [1] TFile *f1 = TFile::Open("root://<remote_FQDN>/test.root","read")
  288 Your identity: /O=Grid/OU=GlobusTest/OU=simpleCA-arthux.cern.ch/OU=cern.ch/CN=qwerty
  289 Enter GRID pass phrase for this identity:
  290 Creating proxy ....................... Done
  291 Your proxy is valid until Wed May 28 02:46:12 2003
  292 root [2]
  293 
  294    In the /var/log/messages on the server you should get something like ( with -d 3 in 'rootd')
  295 
  296 May 27 12:49:46 pcepsft43 rootd[24031]: RootdLoop: kind:2033 -- buf:'11820 -1 2 4 None' (len:17) -- Auth:0
  297 May 27 12:49:46 pcepsft43 rootd[24031]: RpdDefaultAuthAllow: default list of secure methods available:  4 1 2 3
  298 May 27 12:49:46 pcepsft43 rootd[24031]: RpdGlobusAuth: user: /O=Grid/OU=GlobusTest/OU=simpleCA-arthux.cern.ch/OU=cern.ch/CN=qwerty   authenticated
  299 May 27 12:49:46 pcepsft43 rootd[24031]: RpdGlobusAuth: logging as qwerty
  300 May 27 12:49:46 pcepsft43 rootd[24031]: RootdLogin: user qwerty authenticated (OffSet: -1)
  301 May 27 12:49:46 pcepsft43 rootd[24031]: RootdLoop: kind:2004 -- buf:'/test.root read' (len:10) -- Auth:1
  302 
  303    The first authentication to a (remotehost,username) entity may be perceived
  304    as slow;  this is because a lot of exchanges are need to establish the
  305    security context; however,  the security context is kept until is valid, so
  306    subsequent access to the same entity  will be much faster (if this is not
  307    so, make sure that you do not have set the 'reuse'  flag to '0' or 'no'; see
  308    README.AUTH).
  309 
  310    In a PROOF cluster, if the master requires Globus credentials for
  311    authentication  to slaves, these are automatically transmitted using a
  312    shared memory.
  313 
  314 5) If it does not work ...
  315 
  316    Some tips:
  317 
  318    .1) make sure that local and remote times are synchronized within 5 minutes
  319    .2) if GlobusAuthenticate is not found and you are using /etc/ld.so.conf for
  320        shared libraries you may need to run /sbin/ldconfig -v after compilation.
  321    .3) Make sure that remote node accepts Globus authentication from your
  322        local host
  323    .4) Check location of certificate and private key files and certificate
  324        directories; make sure they can be read by the root process
  325    .5) If you get the error message:
  326 
  327         init.c:497: globus_gss_assist_init_sec_context_async: 
  328                     Error during context initialization
  329         init_sec_context.c:187: gss_init_sec_context: 
  330                                 Unable to verify remote side's credentials
  331         globus_i_gsi_gss_utils.c:898: globus_i_gsi_gss_handshake: 
  332                     SSLv3 handshake problems: Couldn't do ssl handshake
  333         OpenSSL Error: s3_clnt.c:836: in library: SSL routines, 
  334                     function SSL3_GET_SERVER_CERTIFICATE: certificate verify failed
  335         globus_gsi_callback.c:349: globus_i_gsi_callback_handshake_callback: 
  336                     Could not verify credential
  337         globus_gsi_callback.c:435: globus_i_gsi_callback_cred_verify: 
  338                     Could not verify credential: 
  339                     self signed certificate in certificate chain (error code 7)
  340 
  341        your certificate issuer is not recognized as trusted.
  342        Most likely this means that its CA certificate has not been found. 
  343        Either you don't have it or one of the followings holds:
  344  
  345         o your $HOME/.globus/certificates does not exist or is empty
  346         o your X509_CERT_DIR is either undefined or points to the wrong
  347           directory
  348 
  349        Solution: you should localize the certificate of the CA issuing your 
  350        certificate: this is in the form <HASH>.0 and a possible alternative
  351        location in /etc/grid-securiy/certificates; you can check the content
  352        using the openssl command:
  353 
  354           openssl x509 -in <HASH>.0 -text
  355 
  356        Do the same with your $HOME/.globus/usercert.pem and make sure the 
  357        Issuer is the same. 
  358        Once you have localized the directory with your CA certificate, setenv
  359        X509_CERT_DIR to point to that directory, for example
  360 
  361           setenv X509_CERT_DIR /etc/grid-securiy/certificates
  362 
  363        (or export X509_CERT_DIR=/etc/grid-securiy/certificates for a bash shell). 
  364 
  365    .6) If ROOT has been built on a different machine, make sure that the correct
  366        (if any) GTK patch has been applied; a version mismatch may cause very 
  367        strange failures, quite difficult to debug / identify.
  368         
  369    .7) mailto: gerardo.ganis@cern.ch.
  370 
  371 --------------------------------------------------------------------------------------
  372 Last update: February 22, 2005