Advertisment

Securing Web Apps on Tomcat with SSL

author-image
CIOL Bureau
Updated On
New Update

By: Kunal Jaggi

Advertisment

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.


Direct

Hit!
Applies

to:
Java EE developers
USP:

Roll out your own digital certificates to enable SSL with Tomcat
Links:

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security6.html 
Google

keywords:
Java EE security, web-tier security
Advertisment








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.

Advertisment
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















Advertisment

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.

Advertisment

Please Login to Enter











Advertisment

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).

Advertisment

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 -->



className="org.apache.coyote.tomcat5.CoyoteConnector">
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

tech-news