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
|
Here, the
CONFIDENTIAL. The former requires that the data is guaranteed not to change in
transit and the later requires that the data be guaranteed not to have been read
by an unauthorized third party in transit. A CONFIDENTIAL guarantee implies
INTEGRAL.
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.
Configure Tomcat
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 -->
port="8443" minProcessors="5" maxProcessors="75"
enableLookups="true" disableUploadTimeout="true"
acceptCount="100" debug="0" scheme="https"
secure="true"
clientAuth="false" sslProtocol="TLS"/>
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.
Conclusion
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.
Kunal Jaggi