Skip to content

SSL legacy Authz with Condor23/EL9

Due to GLOBUS' business change, HTCondor 23 and HTCondorCE 6, respectively, do not support proxy based authz anymore. While the primary authz method is (WLCG) tokens, it is in principle possible to authz as client with a plain X509 certificate (in the following called " SSL authz "). However, since SSL authz has not been intended as actual, in production authz method, the usage is not straight forward.

SSL authz requires preparations on both ends, on the CE server as the user/client sides.

Client Side

To submit a test job on the CLI to a CondorCE 6, please install the htcondor-ce-client package from the Condor stable repository. Since the SSL submission is not the intended authz method, it is necessary to have a proxy certificate present under the X509_USER_PROXY environment variable (this proxy is not used for the actual authz with the CondorCE but is necessary for the client tools, since they expect a proxy certificate).

The DN of the user/robot certificate has to be communicated to the CondorCE administrators as the DN has to be mapped on the CE onto a local user.

Client Environment Set Up

A number of Condor environment variables have to be set (or explicitly configured on the client's Condor configuration). This includes the envvars to the user or robot certificate and key file, the envvars to use SSL as method but not proxies as well as the paths to the IGTF CA certificates (assuming that the CE is part of the IGTF CA hierarchy and that the robot or user certificate is also signed by one of the IGTF CAs). 

####
# enforce SSL as authz method and do not use proxy certificates
#
export _condor_SEC_CLIENT_AUTHENTICATION_METHODS=SSL
export _condor_AUTH_SSL_USE_CLIENT_PROXY_ENV_VAR=false
####

####
# set the paths to an IGTF compatible user or robot certificate and key 
#
export _condor_AUTH_SSL_CLIENT_KEYFILE=~/.globus/userkey.pem
export _condor_AUTH_SSL_CLIENT_CERTFILE=~/.globus/usercert.pem
####

####
# set the CA file variables to an empty string as normally IGTF certificates are distributed as individual files in a common CA directory 
#
export _condor_AUTH_SSL_SERVER_CAFILE=''
export _condor_AUTH_SSL_CLIENT_CAFILE=''
####

####
# set the path to IGTF CA baseline certificates etc.
# if no CVMFS is available, installation of the necessary ca metapackages would be required
#
export _condor_AUTH_SSL_CLIENT_CADIR=/cvmfs/grid.cern.ch/etc/grid-security/certificates/
export _condor_AUTH_SSL_SERVER_CADIR=/cvmfs/grid.cern.ch/etc/grid-security/certificates/
export X509_CERT_DIR=/cvmfs/grid.cern.ch/etc/grid-security/certificates/
export X509_VOMS_DIR=/cvmfs/grid.cern.ch/etc/grid-security/vomsdir/
####

Client Test Job Submission

With the environment and the user/robot certificate in place on the client, the robot/user certificate DN communicated to the CE administrators, as well as a "helper" proxy certificate created on the client side, one should be able to submit a trace test job to the CE, e.g., running

condor_ce_trace -debug condor-ce-01.test.null:9619

during the submission procedure, the client will ask for the password to unlock the key (provided that the user/robot key is secured with a password)

Server Side

On the CondorCE side, SSL authz has to be enabled with

> cat /etc/condor-ce/config.d/99_SSLprep.conf
AUTH_SSL_ALLOW_CLIENT_PROXY = false
AUTH_SSL_REQUIRE_CLIENT_MAPPING = false
USE_VOMS_ATTRIBUTES = False

# AUTH_SSL_ALLOW_CLIENT_PROXY = True
# AUTH_SSL_REQUIRE_CLIENT_MAPPING = True
# USE_VOMS_ATTRIBUTES = False

AUTH_SSL_CLIENT_CADIR = /etc/grid-security/certificates
AUTH_SSL_SERVER_CADIR = /etc/grid-security/certificates

AUTH_SSL_CLIENT_CAFILE=
AUTH_SSL_SERVER_CAFILE=

(assuming that the IGTF CA certificates are installed locally).

The user/robot certificate DN, that had been communicated beforehand by the client user to the CE administrator has to be mapped to a local user, that exists on the CE as well as the local cluster, e.g.,

> cat /etc/condor-ce/mapfiles.d/99_SSLmapping.conf

SSL "/DC=org/DC=terena/DC=tcs/C=DE/O=ExampleInstitute/CN=Max Musterman" foousr009

to map the user certificate from Max Musterman onto the local user foousr009

CE Job Route

A CE administrator will probably need to add a job route to submit a job from the CE to the underlying batch system. Since job routes can be very site specific, the actual implementation will probably look different than the following example job route

> cat /etc/condor-ce/config.d/99_SSLRoute.conf

SSLEXAMPLEROUTE @=end
[
 TargetUniverse = 5;
 set_SSLEXAMPLEROUTE =  True;
 name = "SSLEXAMPLEROUTE";
 Requirements = Owner =?= foousr009;

 set_default_xcount = 1;
 set_default_maxWallTime = 5760;
 set_default_maxMemory = 2048;

 set_requirements=NODE_IS_HEALTHY;

 eval_set_MyAcctGroup = ifThenElse(regexp("foo", owner),  "group_FOO")

 set_AccountingGroup = strcat(MyAcctGroup, ".", Owner);
 set_ConcurrencyLimits = strcat(MyAcctGroup, ".", Owner);
]
@end

JOB_ROUTER_ENTRIES = $(JOB_ROUTER_ENTRIES) $(SSLEXAMPLEROUTE)
JOB_ROUTE_NAMES = $(JOB_ROUTE_NAMES) $(SSLEXAMPLEROUTE)

LRMS Condor mapping

Depending on the local set up, another mapping rule might be necessary for the underlying Condor batch system. I.e., the mapping of the user to the accounting group has to match the mappings configured in the CE's configs

> grep foousr009 /etc/condor/mapfiles.d/99_SSLmaps.conf
 * foousr009  group_FOO