Can the auditing problem be resolved for Web based applications ?
        -----------------------------------------------

 
Yes, the way to directly solve the problem is to enhance a browser program,
for example, Netscape. Several lines of code can provide the functionality:
get client data from a client machine and send this data with each URL.
That's not all: server developers must enhance HTTP program to recognize
this data and include it into the environment we can use for auditing purposes.
Such a direct solution can probably rise a legal questions about client rights...
 
So far, we can work around this problem in two ways.
 
        What is the most common solution ?
        -------------------------------------------
 
The most common solution is to ask a client for his name and a password
upfront before opening the very first Web page of the application.
Such an initial Web page often looks something like a regular UNIX login window,
with just two entry fields for a name and a password and a "Submit" button.
After a client enters her/his name and password and presses the "Submit"
button, the URL associated with the "Submit" button is issued
and the proper program on the server is called.
The name and password are sent as parameters (preferably in encrypted form)
and are processed by the program.
If the name and password match an existing set, the program will look into
the table of privileges and access will be granted according to the privileges
of that particular user.
 
Benefits:
        This solution covers all platforms.
        After the user is identified and confirmed by a password
        the game or business application can be started with proper
        privileges for the client.
        We don't need an application on the client side.
        All the application pieces are located on the server.
 
Disadvantages:
        The server machine must handle a file of passwords for
        all the users.
        In many cases this file will include duplicates from
        password files of the local machines
        (this way a client doesn't need a second password).
        For example, your local machine is UNIX, Windows NT,
        or Windows 95 with the password configured.
        In this case you have to synchronize password changes
        on your local machine to your server or force clients
        to issue a second special password to access your server.
        And anyway, you force clients to do an extra step
        entering their name and password the second time -
        the first time they did it was when starting a local UNIX
	or Windows NT session.

 
        Is there any other way ?
        -------------------------------------------------------------------
Definitely, for UNIX and Windows NT,
where secure technology can be provided with several procedures
described below.

1. You can start a client program, for example "webClient" on a local machine.
The program does the following:
    
 
    It gets client data from a local machine
    and sends it in encrypted form (via sockets) to a remote http server.
   

2. "webSupport" program running on a server machine intercepts this request
    and saves client data into a file returning the file name to a client.
    
    Then "webClient" gets the file name from a server and starts
    a Web browser with a proper URL including the file name as an argument.

The Web browser will start the "webSecure" package on the server machine.


The program will read the encrypted file and
verify the user's privilegies based on User ID.

It immediately deletes the encrypted file after the reading.


Then it starts a Web based application for a valid user only
giving proper privileges to acces sensitive data.

 
Benefits:
        We don't force a client to enter and send a name 
        and a password via the network.
        It greatly simplifies the client's job.
        Moreover, an application started on the client side can get 
        not only the client name but also other important data 
        from the client environment.
        This can later be stored in a log file and used for a client's protection.
        Moreover the same "webClient" application can support 
        not only the start-up process,
        but all the applications via socket communication to the server machine.
 
Disadvantages:
        This start-up application piece that I call "webClient" must be delivered
        to the client machine.
        Of course it can be easily downloaded with any Web browser,
        but this is a definite drawback as it takes some effort from the client.
======================================================

Back To Client auditing and passing objects