Once you've taken steps to secure your communication devices and protocols, turn your attention to the software components that power Web services. One of the most compelling value propositions of Web services is that you can choose whichever development language best meets your requirements. Java, C++, and Visual Basic all interoperate (theoretically) equally well with Web services, as do more simpler scripting languages that aren't normally associated with enterprise application development, such as Perl and Python.
Of all the commonly used programming languages, only Java offers robust, enterprise-grade security features built directly into the language itself. This is largely due to Java's origins as a platform for mobile applet code. Java creators took several steps to ensure security in a network-computing environment. Pointer arithmetic was removed, unreferenced memory is automatically reclaimed by the virtual machine, and Java automatically checks illegal array offsets.
The original Java sandbox model treated code that was downloaded off the network as untrusted and only let it run in a highly constrained environment. This model, however, was too restrictive to be useful. To introduce more fine-grained trust and permissions in to the Java security model, Sun added full support for code signing to Java 2.
Code signing is a process by which public key cryptography and digital certificates are used to verify the identity of the author and distributor of a piece of software. The idea behind it is that users will be more likely to trust network services if they know who authored and is responsible for the code. Code signing is rarely important in the world of shrink-wrap software because, in general, software won't make it to the store shelf or inside the door of your enterprise unless it comes from a trusted source. But in the networked world of Web services, knowing where the code you're using came from is just as important as knowing what it does.
You can use tools that ship with Java 2 to sign Java Archive (JAR) files that you send out across the network, and to verify the authenticity of JAR files that you receive from the network. To do this, first you must create a signing key for yourself using the keytool application:
keytool -alias keyname -genkey
You are prompted to enter the password for the keystore. If this is the first time you're using the application, you can create the keystore password at this point. Then, you're prompted to enter standard X.509 certificate information, such as your first name, last name, organizational unit, organization, city, state, and country. Next, keytool creates a canonical entry that looks something like:
<CN=Paul Sholtz, OU=Engineering, O=PrivacyRight,
L=San Mateo, ST=CA, C=US>
You're asked to verify the entry's accuracy. Once you do this, you're prompted to enter a password for your key. Now you can digitally sign JAR files using your key. You can do this with one line using the jarsigner tool:
jarsigner package.jar keyname
Again, you are prompted for the password to the key before the JAR file is signed. If you receive a JAR file from an untrusted source on the network, you can use jarsigner to verify its authenticity:
prompt> jarsigner -verify unknown.jar