By: Kunal Jaggi
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
tag contains a
tag indicating the security requirements.
|
Example Security Constraint
Secure Area
/secure/*
GET
POST
manager
admin
CONFIDENTIAL
Here, the
tag has two legal values, INTEGRAL and 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.
FORM
/login.jsp
/error.jsp
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.
Source: PCQuest