Most Web applications conform to a three-tier architecture working over a disconnected protocol (HTTP), which maintains the state and information on the server. Because of this remote and disconnected nature, Web applications can become vulnerable to hackers. Here comes the need of data integrity and confidentiality.
Data integrity means that the data that arrives is the same as the data that
was sent. In other words, nobody tampered with it along the way.
Data confidentiality, on the other hand, includes all mechanisms used to protect data during transmission. In this article we'll combine form-based authentication with SSL, and show you how to protect your data during transit. We'll also roll our own; self-signed digital certificate that will enable us to run Web traffic on HTTPS (secure HTTP). Configure the Web deployment plan To leverage the SSL protocol, the DD web.xml file, shown
below, should be modified so that the
|You can roll out your own self-signed digital certificate to enable you to run Web apps on HTTPS|
We also need to kick start form-based authentication, which requires the following configuration changes to the Web deployment plan.
Designing custom login and error pages Form-based authentication is a part of servlet API 2.2. It has some basic requirements. Note that the following three entries in the form are the key to communicating with the container.
- The form must POST the request to j_security_check
- The container requires that the HTTP request will store the user name in j_username
- The container requires that the HTTP request will store the user name in j_password
The code below goes into login.jsp.
Please Login to Enter
The error page is defined on error.jsp and it contains:
Sorry buddy, wrong ID/Password
Prepare a digital certificate
The HTTPS service of most Web servers will not run unless a digital certificate has been installed. So we need to create a keystore file, which encapsulates a digital certificate for Tomcat. A keytool is a 'self-signed' certificate. These are simply user-generated certificates, which have not been officially registered with any well-known CA (Certificate Authority).
Follow the commands given below to generate a keystore file. Use the first command in Windows and the second in UNIX.
%JAVA_HOME%\\bin\\keytool -genkey –alias tomcat –keyalg RSA
$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
Remember, JAVA_HOME is the environment variable that indicates your JDK installation. This command will create a new file, in the home directory of the user under which you run it, named '.keystore'. After executing this command, you will first be prompted for the keystore password. The default password used by Tomcat is 'changeit'.
Next, you will be prompted for general information about this Certificate, such as company, contact name, and so on. This information will be displayed to users who attempt to access a secure page in your application, so make sure that the information provided here matches what they will expect.
Note that this is only for testing. The command-line keytool is not authentic at all, as its not signed by a CA. In your production environment you would consider buying a certificate from a CA like VeriSign or Thawte (NIC, IDRBT etc in India). The CA will vouch for the authenticity of the certificates that it grants.
Tomcat can now use the keystore file. But, first you have to configure your servlet container to enable SSL. Then, enable SSL in the CATALINA_HOME\\conf\\server.xml file. You have to comment out the connector element as shown below.
<-- Define a SSL Coyote HTTP/1.1 Connector
on port 8443 -->
acceptCount="100" debug="0" scheme="https"
This step requires you to restart the Tomcat server.
Under the hood
The first time a user attempts to access a secured page on your site, he is presented with a dialog containing details of the certificate (such as company and contact name), and asked if he wishes to accept the Certificate as valid and continue with the transaction. Netscape Navigator provides an option for permanently accepting a given Certificate as valid, so that the user is not bothered with a prompt each time he visits your site. Any page within an application can be requested over a secure socket by simply prefixing the address with https instead of http.
Note that the SSL connector uses a different port number (8443) than that used by the insecure HTTP connections (8080). The internal intricacies are completely transparent to servlet developers.
HTTP over standard TCP is a bad idea. A safer approach is to use HTTP over SSL. Secure Socket Layer or SSL sits between the application-level protocol (HTTP) and lower-level transport protocol (TCP/IP).
The SSL technology allows Web browsers and Web servers to communicate over a secure connection. It handles the details of security management using PKC (Public Key Cryptography) to exchange symmetric keys that encrypt all client/server communication.
From a performance standpoint, encryption/decryption is a computationally expensive process. It is not necessary to run an entire Web application over SSL. With the help of servlet mapping, a developer can pick and choose which pages require a secure connection and which do not.