After completing Part One and Part Two,
you are ready to learn about Java Commerce Client (JCC) framework security. Electronic
commerce transactions must be secure. There is too much personal and financial
information involved for them not to be. Fortunately, the JCC framework
makes the security part easy.
This article explains how to create the gate and permit code, and sign the cassette Java ARchive (JAR) file with roles so access to a cassette and a cassette's access to JCC framework resources are limited in exactly the way you want.
Cassettes are bundled into JAR files and digitally signed for roles. Roles define how information is shared. One cassette can access only the information in another cassette or in the JCC framework that its role or roles allow.
Digital signatures use public and private key pairs. The private key is kept secret while the public key is generally available. The keys in the pair have a mathematical relationship, so if you encrypt a cassette with your own private key, the recipient of the cassette can decrypt it with your public key. Likewise, anyone can send another person a cassette encrypted with the recipient's public key, which the recipient decrypts with his or her private key.
As an example, a tax application vendor develops a tax preparation cassette,
and a banking vendor develops a home banking cassette. Both vendors agree
to allow the tax cassette to read tax information in the home banking cassette.
The bank signs the tax cassette with the TaxReport role using its
private key, and embeds the public key in its home banking cassette.
When the customer installs the two cassettes, the tax cassette calls into
the home banking cassette. The home banking cassette looks at the
list of roles in the tax cassette's directory and upon finding and verifying
the TaxReport role, passes the tax
cassette access to methods that allow the tax cassette to read the relevant
tax information in the home banking cassette.
You might recall the discussion in Part One on roles, tickets, gates, and permits, which are the coding elements that define and enable fine-grained interactions of this type between cassettes. You might want to review that section before going on to learn how to implement gates and permits.
The idea of gates and permits is based on the Limited Trust Model (LTM) where one cassette can interoperate with another cassette only in the ways specified by the contractual agreement between the parties that own the cassettes. The level of trust you have with another party is reflected in your security code, and likewise, the level of trust another part has in you is reflected in their security code.
Every cassette has one or more gates through which the cassette data or resources can be accessed. The gate is accessed by other cassettes to retrieve permits. A permit gives the requesting cassette the ability to access certain specific methods in the other cassette.
The JCC loads the first cassette and its role, loads the role into a ticket, and passes the ticket to the gate of the second cassette.
The code for the second cassette's gate is shown below. The first cassette does not need any code to explicitly access the gate in the second cassette. The whole process is handled by the JCC framework based on the dependency information provided by the JCM for the operation.
import javax.commerce.base.*;
public class ServerGate {
public static openPermit(Ticket tix) {
try {
// Get a copy of my exported role.
// The name of the role, W_USR,
// can be different
// from the name used by the first cassette.
Role role =
RoleMgr.getExportedRole(myCID, "W_USR");
if (role == null)
throw new ServerException(
"Cannot find exported role");
// Delegate Trust policy
// implementation to JCC
tix.stampTicket(role);
} catch (Exception e) {
e.printStackTrace(); throw e; }
// return the reference to the ultimate object
return new ServerPermitImpl();
}
}
Cassette JAR files are signed for specific roles.
The JCC framework supports a fixed set of roles that enable such
things as installation, commerce Bean registration, and access to the Java
Wallet. You can also create roles like the TaxReport
role so your cassette can share information with another vendor.
The JCC Role Manager does the signing in one of three ways.
Once a cassette is fully implemented and its JAR file signed, it is ready for installation where it will interoperate securely with the other signed cassettes it has been designed to work with. Note that the Java Commerce Message (JCM) is not part of the cassette, but part of the web server-side electronic commerce application.
This article completes the four steps to writing a cassette:
CassetteControl class and create a JCM.The overall procedure for creating a cassette is fairly straightforward once you know all the steps involved and the code you need. Most of the low-level programming issues are taken care of by the JCC framework, and as long as you stick to the model presented here, your code should work well according to design.
The JCC framework includes APIs for working with smart cards. JavaWorld is running a series that explains how to use them:
Java Card 2.0 is a framework and set of application programming interfaces (APIs) for designing and writing applets that implement smart card logic.
© 1994-2005 Sun Microsystems, Inc.