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:
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:
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.
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:
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 |
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 |
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