This is an old revision of the document!
Authentication in Condor is flexible and robust, but it must be properly configured. Authentication allows a server process (not necessarily a process on the central manager) to confirm the identity and therefore validity of a client processes. Fancy forms of authentication are supported by Condor, such as certificate-based SSL authentication and Kerberos, but the basic forms of authentication are local and remote filesystem methods and password-based authentication.
Local filesystem authentication is perhaps the strongest form of username-based authentication when administrative access to a computer is properly limited. It is performed when both the server and client processes are running on the same physical machine. This form of authentication will only be performed if the client's SEC_CLIENT_AUTHENTICATION_METHODS configuration variable and the server's SEC_DEFAULT_AUTHENTICATION_METHODS (or the appropriate SEC_*_AUTHENTICATION_METHODS) both list “FS” and they mutually agree to perform this form of authentication. If so, the client will write a file to the /tmp/ folder. Assuming the client does not have root access1), the file's ownership will be that of the effective user and group IDs. The server process then checks the user and group ownership against the user accounts of the local computer and/or user domain. If the ownership is what the server process expected, the server considers the client authenticated and uses the client's credentials to decide if the client has the proper permissions to have its request fulfilled by the server. The form of the credentials are in the form <username>@<hostname>/<domain>. Thus, if a client process's “<username>@<hostname>/<domain>” is listed in the appropriate ALLOW_* configuration variable, the client's request is fulfilled by the server.
Remote filesystem authentication is another form of username-based authentication. Like local filesystem authentication, remote filesystem authentication involves the client creating a file in a specific location and the server authorizing the client based on the file's ownership. Unlike local filesystem authentication, the location where such a file is created is not limited to the /tmp/ folder but is in an administrator-specified location, ideally a shared filesystem. Since the location is on a shared filesystem, this allows for greater flexibility of authentication while also posing security concerns that must be addressed. The main reason for using remote filesystem authentication is because the client can be authenticated to the server even if the client and server processes are running on two separate machines. Since a shared filesystem typically the commonality between machines, remote filesystem authentication is the easy yet reasonable way to authenticate processes that are running on separate machines.
Remote filesystem authentication is not foolproof. The security of this type of authentication is directly related to the amount and type of access-control provided by the remote filesystem location and its surrounding infrastructure. For example, if a group of computers share user account information through a Unix home directory service it may be tempting to assume that one username is persistent across all of the computers in the domain. To allow one user access to Condor from any of the computers in the domain, you would tell Condor to allow any client that matches user@*/cs.wlu.edu. This could be problematic if the remote filesystem does not control which computers are allowed to access and modify its files. If any unauthorized computer is allowed to access and modify the files in the shared filesystem, a malicious computer can connect to the shared filesystem and use its local root account to make the file with whatever arbitrary ownership it wants and therefore spoof the server into thinking that the file's owner actually wrote the file instead of a malicious root account writing that file. Thus, authentication would map and allow “user” to login to the computers condor1 as user@condor1/cs.wlu.edu and condor2 as user@condor2/cs.wlu.edu correctly but the asterisk mask of the hostname in user@*/cs.wlu.edu would also allow access to the malicious “user” that authenticated as “user@EVIL_COMPUTER/cs.wlu.edu”. Since the malicious computer could pretend to be any arbitrary username, the malicious computer could effectively gain access to any permission level in the ALLOW_* configuration variables that ends in “@*/cs.wlu.edu”, which would be very bad. In order to avoid all of this, only allow specific computers to access the shared filesystem and don't allow untrusted users to have root access or sudo privileges on those computers. To be more secure, avoid using the asterisk “*” in any of the ALLOW_* configuration variables in order to be as specific as possible when specifying which users and machines are allowed to access any part of Condor.
Password-based authentication 
Unix home directory service
Password authentication in Condor has its downsides.
root administrative account is able to change the ownership and permissions of any file in the system. Thus, this form of authentication can be spoofed if a malicious client process has root access (God forbid!) since it would simply need to create the file and change its ownership to be whatever the server process expects.
