Overview
General Architecture
WebSubmit is a framework for a secure, Web-based interface that provides
access to diverse applications across a (heterogeneous) cluster of networked
computers. A simple transaction model governs the way in which resources
are accessed and utilized, and a security framework has been put in place
to determine whether a client is allowed to perform transactions. The software
itself is the combination of a collection of CGI scripts (written with
the aid of Don Libes' cgi.tcl library) and a large body of Tcl
code to provide functionality for these scripts. It is modular, flexible
and extensible; hooks exist for including existing CGI code and for developing
and adding new applications. The code is highly portable and can be modified
to suit the needs of a given site quickly and easily.
Figure 1: The basic WebSubmit architecture. A client contacts
the WebSubmit server using a Web browser, which then forwards requests
to any number of target computing resources.
Transaction Model
WebSubmit is designed as a tool to help users accomplish specific tasks
on one or more computer systems. Each of these tasks is achieved within
a basic three-party transaction model (see Figure 1): (1) the client
that is attempting to access resources, (2) the WebSubmit server
that formats and routes client requests, and (3) the target computer
on which the request (or task) is processed. The client uses a Web browser
to form a secure connection with the WebSubmit server's master page, then
loads the application module for the task of interest. This module
is presented as a simple HTML form that the user fills out and then submits
to the WebSubmit server. The server processes the form, performs error
checking on the input data, and then executes the task specified. Output
from the request is then returned to the user's browser for viewing. This
process is detailed in Figure 2.
Figure 2:A simple WebSubmit transaction. The client connects
to the WebSubmit master page and then selects the link for the desired
application module. The module is an HTML form, which is filled out and
submitted to the server. The server processes the raw form data and sends
an action request to the target system. The system executes commands based
on form data, then returns the output to the server, which is then forwarded
back to the user's browser.
In principle, any type of client system (UNIX, PC, Macintosh) could
be used to connect with the WebSubmit server, provided the browser software
on the client supports the Secure Sockets Layer (SSL) protocol and HTML
3.0. The WebSubmit server resides on a single UNIX machine running an HTTP
server configured to provide the necessary security facilities. The
WebSubmit server is configured to interact with a group of one or more
target systems (hereafter referred to as the WebSubmit cluster)
specified by the administrator of the system. For security reasons, modules
can interact only with systems within this cluster.
Primary Interface
The primary interface to WebSubmit consists of a master page containing
links to all of the application modules available on your site. This
main entry point is generated using the websubmit.cgi script;
the URL to access this script depends on how you have configured your HTTP
server to reference the WebSubmit CGI scripts (see the section on Installation).
websubmit.cgi generates
three separate frames (using link.cgi,
master.cgi, and footer.cgi).
The central frame (master page) contains links to application modules
and its appearance is controlled using a master database.
The frame along the left border of the browser (the toolbar) contains
links to WebSubmit information, information relevant to modules, a configuration
module, and all application modules. The footer contains a mail link
to the WebSubmit administrator, thus allowing users to send bug reports
or comments on the system.
Modules
Modules provide the functional interfaces in WebSubmit that allow users
to accomplish tasks on remote systems. Each separate module
is generated from a CGI script, either hand-written by developers in the
scripting language of choice, or automatically-generated using the WebSubmit
form generation facilities. The master database
is used to specify the way in which a form is generated (manual or auto).
The module is presented to the user as an HTML form, which is filled out
and submitted to the server for processing. The server then
executes commands related to the content submitted by the user.
There is a collection of modules that are applicable to all systems within
the WebSubmit cluster: file transfer, file editing, and simple command
execution. These modules are contained in the WebSubmit distribution
and can be used at any site. Platform- or application-specific modules
are used to perform more focused tasks. Templates modules are included
with the distribution that deal with job submission on systems that use
Load Leveler, NQS, or LSF as their batch queuing systems. Additional
modules can be developed on an as-needed basis and simply plugged into
the WebSubmit master page using the master database.
In an effort to address the needs of both advanced and novice users,
some application modules have a modality assocaited with them. The
modules can be switched between two modes (BASIC and ADVANCED) depending
on the needs of the user. The difference between the two modes
is basically just in the set of form elements that are presented to the
user. In general, modules added to the WebSubmit hierarchy by other
developers will not possess this functionality, although it could be added
in principle.
Configuration
The WebSubmit system was designed around the philosophy that different
sites have different needs in terms of application modules.
The master database provides not only for adding new modules, but also
for activating and deactivating existing modules so that they don't appear
in the interface. In addition, users at a given site may wish to
configure the interface so that only certain modules appear on the master
page. A special configuration page (accessed through the toolbar)
allows users to activate and deactivate modules for their own interface,
as well as controlling the mode in which forms appear by default (only
valid for modal forms). User configuration information is changed
by accessing the script config.cgi.
Authentication
The WebSubmit system is used to execute commands on remote systems for
a specified user. As such, it is imperative to obtain the true
identity of the user accessing the system. WebSubmit provides
seamless access to a whole group of computer systems (the cluster), but
only requires users to enter a single password when they initially
log in to the WebSubmit system. The secure WebSubmit server was designed
to be used with an HTTP server that requires bi-directional authentication
(client-to-server and server-to-client) using the Secure Sockets Layer
(SSL) protocol. The server places the client certificate into
the CGI environment, which allows for analysis by WebSubmit.
Valid WebSubmit users are given access to the system as long as their certificate
data matches that contained in a local WebSubmit authentication database.
Details on the security architecture and maintenace of the authentication
database can be found in the section on Authentication.
Databases
Databases serve as a simple technique for storing data about various aspects
of WebSubmit configuration and functionality. They are human-readable,
can be easily accessed and modified, and can contain data for a wide array
of uses. Two of the primary aspects of WebSubmit (the master page
and authentication) are controlled via simple databases. In addition,
they can be used for automatic form generation, automatic form processing,
and automated task construction. The databases in WebSubmit are ASCII
files that contain a collection of records. Each record possesses
a unique key (atomic or composite) and a group of attributes, specified
using colon-delimited fields. More information on databases and their
use and configuration in WebSubmit can be found in the sections on Data
Storage Implementation, the Master Page,
and Authentication.
Sessions
As previously stated, each module is an HTML form filled out by the user.
Each time a user fills out a form, this constitutes a session for
that module. To aid users with form input, sessions can be archived
and restored as desired. System-wide and user default sessions exist
for many of the forms provided with the WebSubmit distribution, and these
default values are loaded each time a module is accessed. In addition,
users can save named sessions in a library for each module and then load
them at a later time. This reduces the amount of effort required
to fill out forms, especially if the form input does not vary greatly from
invocation to invocation. A more detailed discussion of sessions
can be found in Sessions.