Authentication

Philosophy and Implementation

One of the primary concerns in a system like WebSubmit is security.  The definition of security varies with context, but usually encompasses authentication, authorization, and encryption.  In the context of WebSubmit, the primary concern from a security standpoint is authentication.  Since the user is executing commands in the user's accounts on remote systems using the WebSubmit server as a proxy, it must be possible to establish the user's identity with certainty.  Without strong authentication, hackers impersonating valid users could use WebSubmit to access user accounts, possibly corrupting the user's data and compromising the integrity of systems in the WebSubmit cluster.  Most users and administrators would probably not consider this to be a feature, so a system has been incorporated into WebSubmit to prevent such breaches of security.

The second public release of WebSubmit used a combination of basic HTTP authentication (using HT Access), to restrict access to a private user copy of the main WebSubmit cgi scripts, with an SUID wrapper utility (CGIWrap) to allow execution of these and subsidiary CGI scripts as the  user.  This architecture provided inadequate security, since basic authentication via HT Access is subject to simple dictionary attacks and to sniffing and spoofing.  The first, limited release of WebSubmit used what ammounted to a home grown version of basic HTTP authentitcation.

The third release incorporates a new, more robust security architecture, which works in several stages:

  1. Client-Server SSL authentication
  2. WebSubmit Verification
  3. UserID Translation
  4. Remote Execution via the Secure Shell (SSH)
Client-Server SSL Authentication: Overview
An HTTP server capable of using the Secure Sockets Layer (SSL) protocol, an HTTPS server, handles all requests involving user account access via WebSubmit.  This server resides on the WebSubmit server system.  It is configured to require bi-directional authentication  (server-to-client and client-to-server).  SSL is the current de facto standard for security, although this may change in the future to Transport Layer Security (TLS).  A transition to TLS will not affect operation of the server since the two protocols are very similar and support the same functionality.

The HTTPS server is configured to accept only certificates signed by Certificate Authorities (CAs) that are considered trusted by the local installation of WebSubmit.  This list of trusted CAs should be as restrictive as possible, and should probably comprise a single in-house or association CA that controls all WebSubmit registration, perhaps also handling other site or association certifcation needs.

The user accesses WebSubmit with a browser on a client system.  The user's certificate is available to the browser, at the present normally installed in the browser's encrypted database where the user can access it with the aid of a passphrase.  If the client's certificate is accepted by the HTTPS server, and the client is requesting data in the WebSubmit directory hierarchy, then additional actions are performed.  Specifically, a base-64 encoded version of the client certificate is placed in the CGI environment.  The WebSubmit authentication package constructs a 128-bit message digest of the encoded certificate using the MD5 algorithm.  This 128-bit hash acts as the user's identification number for WebSubmit.  This method for establishing WebSubmit user id's provides in principle for a 1:1 mapping between a certificate and a user.  It has the advantage of not requiring a specially-formatted certificate for use with WebSubmit, and it provides for the possibility of multiple CAs for use with WebSubmit.  It does present a minor drawback in that there may be multiple entries in the authentication database (see next section) for a single user.

WebSubmit Verification
To recapitulate, once a client's certificate is available in the environment, an MD5 hash is created to obtain the userID.  This userID is then compared against IDs in the authentication database (auth.db).  Entries in the authentication database specify the userID as key.  The rest of the record consists of information about the user (name, email address), the kind of privileges the user has on the system (user or admin), and the login names of the user on each of the systems in the WebSubmit cluster.

A person is allowed access to the WebSubmit system if the following conditions are met:

  1. System was accessed via the secure protocol (HTTPS)
  2. userID is contained in the database
  3. Access privileges have not been revoked for userID
Failure to meet any of these criteria will result in a denial of access to WebSubmit services and an error message.  The complete process of SSL authentication and WebSubmit verification is illustrated below.

WebSubmit Authentication and Verification:  The client connects to the WebSubmit HTTP server via  SSL, and in the process provides their certificate.  The HTTP server makes the certificate data available in the CGI environment.  The WebSubmit authority determines a user ID based on this data and then consults with an authentication database.  Access is granted or denied to the client depending on whether their identification matches that in the database.

UserId Translation
Once a user has been validated with the system, the user can use all visible application modules.  Commands contained in these modules will then be executed on the appropriate remote system (remHost).  However, it is imperative that they be executed under the login name corresponding to userID on remHost.  User name translation is thus required , to allow for clusters in which user login names are not uniform across all machines in the cluster.  To accomplish this, userID is translated into the appropriate login name using the authentication database.

The authorization database contains, for each user, a username attribute for each machine in the WebSubmit cluster.  If a user does not have an account on the selected remote system, the database reflects this fact, and the user cannot execute commands on this system.  Otherwise, remLogin is set to match the correct entry in the database, and commands are executed as this user.  If the user has no account a cryptic message appears in the user home directory display reading "<system> does not appear to be listening on sshd port 22...Exiting".

SSH Execution
Commands are executed on remote systems by the WebSubmit server using the Secure Shell (SSH) protocol. This protocol was chosen in order to prevent unauthorized users from executing commands on the remote host bu using IP or DNS spoofing.  To avoid requiring users to enter passwords to execute commands on these systems, the home directory for remLogin must contain an .shosts file that allows the WebSubmit server user to execute commands in the user's account.  For example, if the WebSubmit HTTP server is running as nobody, then the .shosts file must contain the following line:

    serverName.serverDomain nobody

This approach limits us for the present to SSH1, since SSH2 eliminates the .shosts file.  We will correct this in the next release.

Enabling and Disabling Security
If for some reason, you do not wish to use the security features of WebSubmit at your site, it is possible to disable user verification.  The package webSubmit ($wsRootDir/lib/webSubmit.tcl) contains a variable called securityOn, set within the webSubmit namespace.  To disable user verification at your site, simply set this variable to have the value 0.  Once user verification has been disabled, the WebSubmit system will set the WebSubmit security information to the following: wsID = generic, userName = Generic User.  All activities performed as this user will be stored in a generic user directory.

Certificate Authorities and WebSubmit

For SSL authentication of clients to be meaningful, the public-key certificate possessed by a client must be signed by a trusted third party (i.e., CA).  Instead of trusting users to present valid information to the system, the issue then becomes trusting this certificate issuer to vouch for the identity of the client.  The difficulty in the WebSubmit context is then to decide who (or what) should act as the CA.  The solution we have adopted is to require the site or association that installs WebSubmit to select their own CA, either in-house or a commercial service.  This is specified to the WebSubmit HTTPS server when it is set up.   Discussions of certificate authorities and the difficulties involved in public key distribution can be found Applied Cryptography (2nd Ed.) by Bruce Schneier.

Authentication Database Configuration

The WebSubmit authentication database ($wsRootDir/lib/auth.db) contains information about the Certificate Authorities (CAs) accepted by WebSubmit, the valid administrative users, the regular users registered with the system, and the machines contained in the WebSubmit cluster.  A sample version called $wsRootDir/lib/auth.db.example is supplied.  To use it, rename it auth.db.  It is essential that this database is configured properly for your site.  If it is improperly configured, then either WebSubmit will not work, or its security measures will be vitiated.  The following sections explain the configuration of this database.  The Configuration Manager provided with WebSubmit contains a database manager that allows administrators to add and remove users from the system easily and quickly.  More information about the Configuration Manager is contained in the Configuration Manager documentation.

General Database Structure
The authentication database follows the same basic structure used for other WebSubmit databases.  It contains an attribute specification and records to hold data based on this attribute list.  The following attributes are required in the attribute specification:

Each record within the database is then a colon-delimited collection of the data that matches these attributes.  A * is used to indicate that the data is not applicable for a particular attribute (e.g., for login names).  The number of fields in a record must exactly match the number of attributes specified for the database.
 

Configuring Database Attributes
As specified above, the list of machine names in the WebSubmit cluster must be provided as attributes in the database.  The fully-qualified name of each machine in the cluster should be appended to the list of database attributes.  For example, if your cluster contains zeus.greek.com, and athena.greek.com, then the line specifying database attributes should appear as follows:

::DB_ATTRIBUTES:: key:wsID userType userDir userName email status
  zeus.greek.com athena.greek.com

Database attributes should be specified on a single line within the database.  If a user does not have an account on every system in the cluster, the systems on which the user does not have an account should have asterisks for login names.
 

Database Records
For each of the following classes of users, the way to fill out each field of the database is specified.  The Configuration  Manager provides an easy way to add and remove users from the system, provided the MD5 hash of the user's certificate is known.  A mechanism for hashing certificates is contained with the Configuration Manager, and contacts from any certificate not already present in the database produce email referring to a saved
 

Administrative Users
 
Field Record Data
wsID MD5 hash of the admin user's certificate (32 hex characters)
userType admin
userDir * or desired directory
userName Name of the administrator
email E-mail address of the administrator
status active or inactive
Cluster Machine * (for all machines) or login names if desired

Regular Users
 
Field Record Data
wsID MD5 hash of the user's certificate (32 hex characters)
userType user
userDir Directory to hold this user's session and config data (relative to $wsRootDir/user)
userName Full name of the user
email E-mail address of the user
status active or inactive
Cluster Machine Login name of the user on the specified system or * if not available

Here is a sample auth.db file, $wsRootDir/lib/auth.db.example from the distribution.

::RECORD_ATTRIBUTES:: key:wsId userType userDir userName 
  email status hostA hostB

*CERTHASH* : admin : admin1 : WebSubmit Administrator A 
: websubmit@yourdomain :
 active : hostAadminAusername : hostBadminAusername
*CERTHASH* : user  : ws001  : John Q. UserA             
: usera@yourdomain     :
 active : hostAuserAusername  : hostBuserAusername
*CERTHASH* : user  : ws002  : Quentin J. UserB          
: userb@yourdomain     :
 active : hostAuserBusername  : hostBuserBusername