Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

Construct secure networked applications with certificates, Part 4

Authenticate clients and servers, and verify certificate chains

By Todd Sundsted, JavaWorld.com, 04/13/01

  • Print
  • Feedback
.
Over the course of the last several months, you've learned about public-key cryptography, X.509 certificates, and certificate revocation lists. You've surveyed their associated Java classes, and you've come to understand their importance. Now you need to learn how to use them, and that's where you're headed this month.

You can read the whole series on certificates:



Imagine the following scenario: You're building a distributed application for the health insurance industry. The HIPPA (Health Insurance Portability and Accountability Act of 1996) Security Guidelines require secure access to sensitive information stored in compliant systems. Those requirements encompass both access by individuals and access by other applications. Therefore, in your distributed system, interactions between the components must be secure. Client applications must be able to authenticate the servers they connect to before transmitting sensitive information. Servers must be able to authenticate client applications before accepting and operating on sensitive information provided by clients.

One way to provide authentication is to use SSL (Secure Socket Layer). SSL, which is available for Java in the JSSE (Java Secure Socket Extension), handles authentication among communicating processes using X.509 technology and provides encryption support using various encryption algorithms of assorted strengths. For many applications, honestly, this is the way to go, especially if you want an out-of-the-box solution and can guarantee that both sides provide SSL support. However, SSL won't work in some cases; maybe you don't need it, can't use it, or don't want to use it. In those cases you have to provide similar functionality yourself.

Authentication

Let's take a high-level look at the problem. Consider the following interactions between a client and a server, which are typical of both SSL-enabled applications (although hidden from view) and the custom applications built using X.509 technology:

  1. The client opens a connection to the server and asks the server to authenticate itself.
  2. The server authenticates itself and -- optionally -- asks the client to authenticate itself. Client authentication, while possible with SSL, is seldom used in most SSL transactions. However, for enterprise applications, in which auditing of all transactions is important, client authentication provides the only way to determine for sure that the client's claimed identity is legitimate.
  3. The client authenticates itself. If the client desires an encrypted connection, it takes steps to establish one. I won't describe the process of establishing an encrypted connection at this time.
  4. The client begins the transaction.


Server authentication and client authentication essentially mirror each other, so it's sufficient to talk about one or the other. Let's look closely at the server authentication process (steps 1 and 2).

  • Print
  • Feedback

Resources