Electronic Commerce, Part Three: Making It All Secure

Print-friendly Version

Articles Index

After completing Part One and Part Two, you are ready to learn about Java^TM 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.

Security and the JCC Framework

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.

Step 3: Implement the 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.

package javax.commerce.cassette;
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(); 
  } 
} 
 

Step 4: Signing a Cassette with Roles

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.

Conclusion

This article completes the four steps to writing a cassette:

1. Implement a CassetteControl class and create a JCM.
2. Implement the related commerce Bean.
3. Implement the gates and permits.
4. Sign the cassette JAR file with roles.

Related Articles

The JCC framework includes APIs for working with smart cards. JavaWorld is running a series that explains how to use them:

• Smart Cards: A Primer
• Smart Cards and the Open Card Framework
• Get A jumpstart on the Java Card

Java Card 2.0 is a framework and set of application programming interfaces (APIs) for designing and writing applets that implement smart card logic.

Monica Pawlan, a staff writer for the Java Developer Connection (JDC), is author of Essentials of the Java Programming Language: A Hands-On Guide (Addison-Wesley, 2000), and co-author of Advanced Programming for the Java 2 Platform (Addison-Wesley, 2000).