FREE ESSAY ON SECURING CLIENT/SERVER TRANSACTIONS

SECURING CLIENT/SERVER TRANSACTIONS

Securing Client/Server Transactions
Securing Client/Server Transactions
The three basic ways that security is implemented in the area of client/server
transaction. The first area is firewalls. The basic idea of a firewall to monitor traffic
from a trusted network ( a company's internal network) to an untrusted network (such as
the Internet). Firewalls fall into two categories, "proxies" and "packet-filtering"
firewalls. Packet-filtering determines whether a packet is allowed or disallowed
depending on the source of the packet and the contents of it. Packet-filtering also looks
at the source and destination ports, and to determine if a packet is part of an ongoing
conversation. 
An application-level firewall, better known as a proxy acts as an intermediary between
the client and the server. The client application connects to the proxy. The proxy opens
a connection to the server and passes information back and forth between the server and
the client (refer to Figure 1.).
Figure 1.
Both firewalls have their advantages and disadvantages. In most cases both categories
will be implemented on the same firewall. A packet-filtering firewall tends to be less
secure than a proxy based firewall, since complete knowledge of the protocol is used by
the application. However packet filtering can allow a concept known as masquerading.
Masquerading is when the firewall takes the outgoing source address on the packets and
converts the address so the receiver thinks they are talking to the firewall. The
receiver's packets will have it's address on it coming back so the firewall can determine
which sender gets the packet. The advantage of masquerading is that a company's internal
network can be hidden behind the firewall. 
Another security implementation is encryption. Encryption is the process of modifying
information so that it can not be read by anyone except the intended recipient. This is
done by applying mathematical algorithms that require a "key" to unlock, or decrypt, the
original data. Algorithms that use the same key to encrypt and decrypt data are known as
"symmetric" encryption algorithms. Algorithms that use different keys to encrypt and
decrypt data are known as "asymmetric" or "public-key" encryption algorithms. Encrypted
data comes in two forms 40-bit and 128-bit. 40-bit encryption uses a 40 bits of space to
encrypt data and 128 bits of space for the 128-bit form. 
The process of verifying the sender's identity is known as "authentication".
Authentication can be performed with a user name and password, or with a piece of
information known as a "digital certificate". A digital certificate contains encryption
parameters, which can be used to uniquely identify a user or a host system. Verifying
that an external party has not modified data is known as "integrity checking". Integrity
checking is done by applying a mathematical algorithm, known as a "hash", to data before
it's sent and computing the same hash when the data is received. If the two hashes map to
the same result, then the data hasn't been modified. 
How do these areas affect client/server transaction? Client/server transaction deals with
the everyday transactions that people engage in on the Internet. With each transaction,
personal information is sent from client to vendor. The information has a tendency to be
sensitive in nature and not something shared with anyone except the vendor. Such
information may include social security numbers, credit card numbers, and possibly
information for monthly bills (account numbers and balances specifically). Businesses
have to save-guard their customers in order for their customers to feel secure in buying
products and services from them. Businesses understand this importance. Some businesses
and development groups have evolved from the need to make business transactions more
secure on the Internet. In doing so, business presence has grown exponentially over the
last decade. Commercials on TV tell business owners if they aren't on the web, they won't
survive. 
Programmers face difficult and exciting challenges in the areas of security for
client/server transaction. One of the most popular languages used on the Internet is
Java. Java runs on many different platforms, which makes it very versatile in Internet
applications. JavaSoftTM has introduced the Java Commerce Client (JCC) framework. The JCC
provides a secure, robust, and reliable platform that enables software vendors to write
electronic commerce applications. With a framework, you focus on the application-specific
business logic and let the framework handle the low-level programming details. 
Application-specific code is organized into modules called cassettes. A cassette
represents one part (or module) of a transaction. Cassettes are mixed and matched to lay
the foundation for an electronic transaction. A cassette designed by one vendor can
interact with one or more cassettes by that same vendor or by agreement with a cassette
from another vendor. The JCC framework orchestrates cassette interoperations and enforces
the high level of security required for reliable transactions between clients and
merchant servers. 
The framework and cassette innovation supports a full range of large and small
money-based applications such as personal finance software, tax calculation programs, and
retail sales applications--all of which can run on any Java-enabled platform with the JCC
framework installed.
The JCC framework consists of commerce-related classes, interfaces, and cassettes for you
to implement your own application-specific electronic commerce code, and an environment
within which the application code runs. Clients with an installed and configured JCC
framework can initiate transactions on a commerce server that execute on the client
machine. 
The JCC framework enables the cassette interoperations that form a transaction. A
cassette is a signed Java ARchive (JAR) file containing the compiled classes that
implement one part of an electronic commerce transaction on the client side. One
transaction typically involves several interoperating cassettes. Cassette functionality
is defined primarily by the code in a commerce Bean. There are several types of commerce
Beans, but the following three types that provide the basic functionality for a purchase
transaction: 
? An operation Bean to implement an action such as a purchase. 
? A protocol Bean to implement the electronic transfer standard to use. 
? An instrument Bean to implement the form of payment such as VISA. 
An electronic purchase transaction requires a purchase operation cassette, one or more
protocol cassettes, and one or more instrument cassettes. 
Note that a commerce Bean is similar to but not exactly like a standard JavaBean.
Commerce Beans are not currently written to the same specifications as JavaBeans, and
support additional security and other functions required by the JCC framework. 
To create the cassettes for a transaction, you can write your own cassette(s), and use or
modify any of the following types of cassettes that come with the JCC framework: 
? User Interface (including the Java Wallet) 
? Purchase operation 
? Protocol 
? Instrument 
? Service (for local operations) 
The JCC framework uses roles, tickets, gates, and permits to ensure that only authorized
cassettes have limited access to information and resources in other cassettes and the JCC
framework. This model is called the Gateway Security model because access to sensitive
data within a cassette is permitted through specific controlled gateways only. Roles
define what a cassette can do. A cassette is signed for a role or set of roles. For
example, every cassette is signed for the Cassette role because this role is required to
install the cassette. If a cassette is not installed, the cassette cannot work with the
JCC framework. Operation cassettes are signed with the Operation role, protocol cassettes
are signed with the Protocol role, and instrument cassettes are signed with the
Instrument role so they can register themselves in the JCC framework cassette registry. 
A ticket is a use-once token of the capabilities authorized by a given role. An operation
cassette depends on one or more specific protocol cassettes. Protocol cassettes implement
the functionality to carry out online commerce protocols. 
Gates are authentication methods. All communication with a cassette takes place through
its gate. For example, the protocol cassette gives the ticket it received from the
operation cassette to the JCC Role Manager, which checks that the ticket has not been
altered since it was first loaded. If the security check passes, the cassette is given a
permit. 
Permits are objects returned by the gate. For example, if the ticket has not been
altered, the JCC framework stamps the ticket and passes it back to the protocol
cassette's gate. 
To summarize, a cassette is signed with a role, which gets it a ticket, which gives the
cassette a permit to do something. The JCC framework manages the interoperations between
the operation, protocol, and instrument cassettes with tickets, gates, and permits. 
Four Steps to Writing a Cassette 
The short example for this series describes how to create the operation, protocol, and
instrument cassettes for a simple purchase transaction. A purchase transaction might be
initiated when a web store shopper chooses an item and selects the Pay button on a
merchant server. The Java Commerce Message (JCM) contains information on valid
instruments for that shopper. The JCC framework finds the intersection of valid
instruments for the shopper and instruments recognized by the merchant server and
displays those instruments on the merchant server so the shopper can choose the mode of
payment. The JCC framework sends the JCM, which contains other information about the
transaction, to the client machine where the correct cassettes are loaded (or installed
and loaded) to execute the transaction. 
The four steps to writing a cassette are as follows: 
1. Implement a CassetteControl class and create a Java Commerce Message (JCM) file. This
step is covered below. 
2. Implement the operation, protocol, or instrument commerce Bean to go with the
CassetteControl class. 
3. Implement gates and permits. 
4. Sign the JAR file with roles. The JAR file bundles the compiled CassetteControl class,
commerce Bean class, and other related files into a cassette. 
teControl Class 
Every cassette must have exactly one CassetteControl class that extends
java.commerce.cassette.Cassette. This class is the first class loaded by the
CassetteClassLoader. The installer uses this class to install the registry database for
registering operations, protocols, and instruments. The cassette runtime uses this class
to update the cassette with new software versions. 
The code below implements a CassetteControl class for a cassette that handles a
purchasing operation. The operation cassette works with one or more protocol cassettes,
which in turn work with one or more instrument cassettes. 
The CassetteControl methods are called by the JCC framework during cassette installation
based on information provided in the installed Java Commerce Message (JCM), which is
created in the second part of Step 1 below. Note that cassettes can only interoperate
with cassettes upon which they have a designated dependency as specified in the JCM for
the operation. This dependency information is returned by the get*Identifier methods. 
import java.net.URL;
import.java.util.Date;
import javax.commerce.*;
import javax.com.sun.commerce.*;
public final class CassetteControl extends Cassette {
private static final CassetteIdentifier 
myCassetteIdentifier = 
new CassetteIdentifier(purchase, 1, 1);
private static final CassetteIdentifier[] 
dependencyIdentifiers = null;
public CassetteControl() {}
/* Cassete abstract method redefinitions */
protected CassetteIdentifier 
getCurrentVersionIdentifier() {
return myCassetteIdentifier;
}
protected CassetteIdentifier[] 
getDependencyIdentifiers() {
return dependencyIdentifiers;
}
protected void install() {
registerOperation(
PurchaseOperation.OPERATION_NAME,
com.sun.commerce.purchase.PurchaseOperation);
}
/* These methods are not implemented yet. */ 
protected void init() { }
protected void shutdown() { }
protected URL[] getJCMForLatestVersion() { 
return null; }
protected Date getExpirationDate() { 
return null; }
protected boolean doUpdate(Date lastUpdate) { 
return false;}
protected void uninstall() { }
}
Create the Java Commerce Message for the Purchase Operation 
Every operation requires an associated Java Commerce Message (JCM). A JCM is an
electronic message sent from the web server to the client JCC framework. There are many
ways to structure a JCM transaction. One scenario for a purchase transaction initiated in
an applet could be as follows: 
A shopper makes a selection that triggers the electronic purchase operation. The web
server applet then queries the shopper for payment and other relevant information, plugs
that information into a JCM template, and sends the JCM to the JCC framework installed on
the initiating client's system. The JCM contains a body of name=value pairs that describe
the transaction. 
When the JCC framework finds the operation=purchase line in the JCM, it searches for the
purchase operation cassette specified in the CassetteIdentifier method in the
CassetteControl class. In this example, the purchase cassette is purchase_1.1. The JCC
framework then passes the JCM to that operation Bean, which in turn parses the JCM. 
Here is the JCM for the Purchase operation. The purchase operation cassette uses
MasterCard and VISA as instruments, and the Secure Electronic Transfer (SET) and Secure
Socket Layer (SSL) protocols. The JCM for the purchase operation also includes product
and price information. 
#Specify the Operation
Operation=Purchase
#Specify the valid instruments and protocols
ValidInstruments=Visa, MasterCard
ValidProtocols=SSL, SET
#Parameters for the purchase operation
purchase.item=widget
purchase.price=2.24 USD
#Parameters for the SSL and SET protocols
SSL.Submit=http://somecgi
SET.MerchantServer=http://setserver
Create the Java Commerce Message for the Install Operation 
Here is the JCM for the install operation. If the correct purchase cassette is not found
on the local system, the correct purchase cassette is downloaded from the web server and
automatically installed. The purchase and installation operations are separate operations
each requiring their own JCM. The install JCM is usually a flat file because it does not
normally contain any dynamic information. 
#Install the cassette
Operation=Install
CassetteIdentifier=purchase_1.1
CassetteLocators.1=http://www.sun.com/purchase.jar
DependencyCassetteLocators.1.1=
http://www.sun.com/set.jcm
The CassetteIdentifier parameter is the unique identifier passed to myCassetteIdentifier
method in the CassetteControl class implementation. 
The CassetteLocators parameter is the location of the JAR file that contains the
cassette, and the DependencyCassetteLocators parameter points to the insall JCMs for the
cassettes on which this cassette depends.
References
Article: Jackson, Richard. Running Down the Up-escalator: Regional Inequality I n Papua
New Guinea. Australian Geographer 14 (May 1979): 175-84.
Pitts, David and Ball, Bill Red Hat 6 Unleashed. Sams, 1999.
Stapleton, Lisa and Pawlan, Monica.  Electronic Commerce, Part One: Getting into the Game
*http://developer.java.sun.com/developer/index.html *. May 1992. 
Bibliography
References
Article: Jackson, Richard. Running Down the Up-escalator: Regional Inequality I n Papua
New Guinea. Australian Geographer 14 (May 1979): 175-84.
Pitts, David and Ball, Bill Red Hat 6 Unleashed. Sams, 1999.
Stapleton, Lisa and Pawlan, Monica.  Electronic Commerce, Part One: Getting into the Game
. May 1992.