NPAC System

 

 

 

Foreword

Resources

Code Listings

Foil Sets

Assignments

Solutions

External Resources

SiteMap

Search

Home

Up ] [ NPAC System ] Secured NPAC System ]

Distributed Client-Server Management System (Draft based on simple online banking transactions)

Secured Version

This experimental system is developed using idltojava (Sun's version of CORBA-JAVA compiler) under Sun's JDK1.2beta3. This system can be easily modified to be adopted into comercial client-server applications.
This system is at preliminary stage. More functionalities will be added.
To play the following example, please

  1. download JDK1.2 Beta 3 from Sun
  2. set JAVA_HOME to where JDK1.2 Beta 3 locates. (e.g., setenv JAVA_HOME /usr/local/jdk1.2beta3)
  3. setup CLASSPATH properly.
  4. include JDK1.2's bin path.
    (e.g., set path = ($path /usr/local/jdk1.2beta3/bin))
  5. Please download the client-related classes before playing, (client.tar.gz) then follow the instructions listed below.
    1. uncompress and untar this file ("client.tar.gz") to your specified directory (e.g., ~your_username/NPAC)
    2. change to this directory (e.g., cd ~your_username/NPAC)
    3. start appletviewer of the version in JDK1.2 as follows
      To start the demo example:
      appletviewer http://osprey8.npac.syr.edu:1965/NPACSystem/demo.html
      To start extra Client applet:
      appletviewer http://osprey8.npac.syr.edu:1965/NPACSystem/client.html or
      appletviewer client.html locally
      To use the demo Account: ct1234 and Password: ct1234. There is no password-protection on Monitor and Console. (You are only allowed to see the current server status.)

Note: The secured version of the system has been implemented. It is currently under documenting and will be available soon.

To be done: secured JAR (using keytool and Jarsinger) file will be provided for client to download.
Client/Server communication will based on the design of Public Key system and Digital Signature to secure the data transmission between the client and the server. (Secured Electronic Transaction - SET and SSL is under consideration)
  1. Verification:
    1. Option I:
      1. the client sends its certificate (x.509 v3) to the coordinator with password
      2. Coordinator verify the client certificate and reply the server (company) certificate to the client
      3. the client verifies the server certificate and send a random message to the server with the client's signature

      This is based on the assumption that all clients and the server are issued certificates by a CA (Certificate Authority) or CAs. Or the server (company) can become as a CA (i.e. purchase Certificate Server from Netscape) to issue and to sign certificates.

      Option 2:
      1. Server generate all clients' keypairs and store them in the key store at the server side.
      2. the client receives the server public key (can be dynamically generated) either access the applet through web browsers or obtains it by running the client application
      3. the client send its assigned public key, password, and a random message to the server
    2. the server verifies the key and compute the Message Digest (MD)
    3. the server returns a SignedObject (including the MD encrypted with the server signature):
      SHA-1 algorithm for Message Digest (other algorithms like MD2, MD5)
      DSA for Signature Verification
      Create a SignedObject with the above, encrypt this object with the private key
    4. the client verifies the SignedObject
  2. Secret Key Exchange
    1. the server generates a keypair using DH algorithm
    2. DES, ECB and PKCS#5 algorithms is used for sending the public Key
    3. DH protocol for Key Agreement to exchange the Secret Key

    Another generated keypair for exchange the secret key is used to provide another level security. This keypair doesn't need to be generate for every connection between the client and the server. Periodically change should be reasonable (i.e. every hour or day).

  3. DSA algorithm is used to encipher the message with the Secret Key
  4. HMAC/SHA-1 algorithm is used for Message Authentication Code (MAC) to authenticate the message
  5. SealedObject (in JCE 1.2) is created to include the above and sent within the local network
  6. create a SignedObject whivh incudes the above SealedObject, MAC, and sender's signature for secured communication between the client and server.
Server/Administrator communication can be designed based on the Secret Key system (start from Step 2 to Step 5) for better performance. This seems not necessary because the internal communication usually happens behind the firewall. Exceptions always exist such as internal thieves, hackers, etc.

If this system is not up and running, please email me at cwou@npac.syr.edu. Thanks in advance!

Developed by Chao-Wei Ou

Architecture

Client Applet

(See detail)

Actions

1 A Client applet accesses Coordinator to obtain an ORB reference to connect to one of the servres.
3 Once obtaining the ORB reference, the client starts the connection to the one of the servers which assigned by Coordinator.

Functions

username/password authentication
connection to the server determined at run-time
locally printing the current transaction information to a log file
querying current account information
transferring amount between Checking and Saving accounts
auto-disconnect when applet die (without clicking Exit)
real-time action checking (auto-disconnect if no action after 30 seconds)

Future Work

Socket-connected communication between Client and Coordinator/Server will be implemented to reduce Client's downloading time
Better security solutions are always under investigation.

Console Applet/Public Coordinator

(See detail)

Actions

2 Coordinator verifies the client by checking username/password, returns a unique transaction number and an available server reference.
5 Console connects to Coordinator to start/stop the system.

Functions

Console
sending transaction number and verification information to the deticate server
periodically pulling the system status
refreshing/maintaining all server status
startup/shutdown all registered servers
start/stop each individual server
Public Coordinator
accepting clients' connections by verifying users' username/password
locally generating a unique transaction number by a local counter
determining one available server according to the Server status
accepting console's connection by verifying console's username/password
periodically checking the system status (including all servers and database servers)
displaying the system status for users without console's password

Administrators/Internal Coordinator

(See detail)

Actions

6 Administrator obtains customers' information. Then it connects to Internal Coordinator to register customers' information.
7 Internal Coordinator obtains customer data. Then it connects to Servers to insert customers' records into database.

Functions

Administrator
username/passwrod verification
adding new customer into database
updating existing customer data
deleting existing customer
searching existing customers
printing operation logs
Internal Coordinator
periodical administrator online checking
login/privilege verification
connecting to database server

Monitor Applet/Servers

(See detail)

Actions

4 Server proceeds clients requests (query, transfer, etc.) and send these requests to database server through JDBC. Then return results back to clients.
8 Monitor connects to a dedicated Server to monitor the current status of the server.

Functions

Monitor
displaying the server status
Server
username/password and transaction number
checking clients' actions (auto-disconnect if client is idle for a period verification of time or browser is closed)
proceeding querying/transfering requests
recording all transactions
showing the current usage status by monitoring the server
connect to Database Servers by JDBC

Database Servers

(See detail)

(Partially completed - need real data to complete)

Actions

JDBC connects to database servers through the Oracle JDBC driver (oci7 server-side driver). (This also can be done using thin driver for workstations have SQL*Net installed.)

Functions

database owned by a system user
the client access/update the view which prevent the client from obtaining others' information
periodically changing database accessing verifications (username/password) to protect the system
indexing
using stored PL/SQL packages to increase the performance
generating transaction logs in database for comparing with logs on Servers
auto-daily flushing transaction logs and backup