Web services test code generator
Klaus Berg has recently released a test-code generator for JUnit-based Web service clients. If you're developing Web services using Axis2 and XMLBeans this wizard could turn your JUnit test client coding into a powerful code generation process. It also has uses for those using GUI-based testing tools like soapUI.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com

Secure your Java apps from end to end, Part 3

Build better networked applications

By Todd Sundsted, JavaWorld.com, 08/10/01

In this series, I have encouraged you to look at security from three different directions. In the first two articles, I focused on virtual machine security and application security. This month, I will discuss the final security context -- network security.



Network security deals with securing the communication channel between two entities so they can communicate -- each entity confident in the other's identity and in the integrity of the messages exchanged over the channel.

A number of reasons make building secure networked applications a challenge. The difficult subjects upon which modern security is built (such as cryptography) can sometimes confuse developers. Also puzzling are the opaque presentations of key standards and technologies -- such as the X.509 certificate standards. However, at the end of the day, network security is difficult because the characteristics of the network medium itself prove hard to understand. The following analogy illustrates why:

When we converse in everyday life, information about the party with whom we communicate comes through multiple mediums, such as sight and sound. We use this information to authenticate the other party's identity and to judge the channel's quality. Even when we converse over the phone, we can adeptly judge the identity of the party on the other end from nuances in tone, speed, and inflection, not to mention the conversation's context.

Communication over a medium such as the Internet provides far fewer clues. Imagine speaking with a friend in another room through a tin can telephone. Its poor signal quality obliterates many of the audible clues we use to identify each other. The tin can scenario resembles the situation that most applications experience on the Internet or other networks.

Security in the network context consists of authenticating the other entity over this anonymizing channel, and protecting the communicated information from eavesdropping and accidental or malicious modification.

I have written extensively about the tools and technologies used to secure communication at the network level (see Resources). I focus this article on practical guidelines to follow and issues to consider when designing and implementing a network security solution.

Understand what you want to protect

Designing a security solution begins with the information you need to protect. Moving financial transactions across the Internet requires much stronger security than downloading a Webpage full of last week's sports scores. When selecting the technology and creating a design, you should consider the following design issues:

  • Security adds complexity to a product's design and implementation, its installation and configuration, and often to the user interface. While security is usually a desirable feature, complexity is not. How much complexity are you willing to introduce in the name of security?
  • Security, particularly the encryption and decryption operations, is often a CPU-intensive process. Most desktop and server systems have more than enough horsepower to outrun the network, but resource-constrained devices such as cell phones and PDAs often lack that strength. Can your target platform handle the load?
  • Likewise, security increases application size. While not as critical in desktop and server settings, size remains a real concern in embedded applications, especially those built for the platforms the Java 2 Platform, Micro Edition (J2ME) targets. Once again, can your target platform handle the load?

    As an excellent case in point, the first version of the Mobile Information Device Profile lacked SSL (secure socket layer) support -- an essential component of an end-to-end Web security solution -- primarily because of the perception that SSL proves too heavy for mobile devices. In response to this concern, Vipul Gupta of Sun Microsystems Laboratories built a standards-compliant SSL implementation for J2ME. His work demonstrates that small devices can achieve acceptable SSL performance. Gupta's implementation achieves that goal because it supports only a reduced set of the most popular cipher suites, lacks support for client authentication by the server (an operation with a costly client-side component), and reuses expensive RSA (Rivest-Shamir-Adleman) computations across multiple connections to the same server. See Resources for more information.



Use the right technology

It almost goes without saying that selecting the right technology is important when implementing a network security solution. The choice affects the longevity and quality of the security offered as well as an application's ability to integrate into an existing security infrastructure. The JDK provides a broad range of security APIs. The following list will help you identify and select the right technology for your problem:

  • Authentication and digital signatures: Java Cryptography Architecture (java.security)
  • Encryption/decryption and message authentication codes: Java Cryptography Extension (javax.crypto)
  • X.509 certificates: Java Cryptography Architecture (java.security.cert)
  • SSL support, HTTPS URL support: Java Secure Socket Extension (javax.net.ssl)
  • Pluggable authentication and authorization: Java Authentication and Authorization Service (javax.security.auth)


The JDK 1.4 beta includes:

  • Kerberos: GSS (Generic Security Service) API (org.ietf.jgss)
  • Certificate path validation: Certificate Path Validation API (java.security.cert)


These standard APIs will handle many of your security-related Web application and enterprise integration tasks.

Understand the network

It is not wise to design a network security solution without considering the network. The systems on which an application runs and the network over which it communicates all place their mark on a design.

Consider this edge case: You build an application that runs completely within a secure network. If the network proves secure -- and this means the network is physically protected, and the users are trusted and only carefully granted access -- then you have little need to secure the application itself. In many cases the network is not as secure as believed, and developers fail to secure the application because leaving security mechanisms out is easier than building them. However, some situations justify this approach. For example, in a clustered environment with multiple instances of an application running and communicating to balance load, it's often sufficient to secure the cluster as a whole, not the application.

Resources
  • "Java Security Evolution and Concepts," Raghavan N. Srinivas (JavaWorld):