java Web Application Security

  1. Impersonators, upgraders and Eavesdroppers are the main bad guys a web application developer needs to worry about.
  2. As per the servlet specification, the security of web application is about authentication, authorization, confidentiality and data integrity.
  3. Security is to be kept out of the code to support component-based development.
  4. Servlet specification does not mention anything about how the container should implement support for authenticating data. Usually, the container vendor will support a vendor-specific table containing usernames, passwords and roles. Vendors also provide a way to hook your application to the company specific authentication data in a LDAP System or relational database. The data in LDAP or relational database respective to security is maintained by administrator.

What does Realm means with respect to security?

Realm is nothing but a place where authentication information is stored. In tomcat it is tomcat-users.xml which is located in <tomcat installation directory>/conf/. It is known as memory realm. Not recommended for production.

How to enable authenticaton?

Add the following code in  deployment descriptor(web.xml)




There are four types of authentications. They differ in how securely the username and password info is transmitted.

  • BASIC: Transmits login info in an encoded form. Provides very weak security.
  • DIGEST: Transmits login info in a more secure way. As encryption is not widely used, you cannot trust J2EE containers to support this feature.
  • CLINET-CERT: Transmits login info in an extremely secure form, using public key certificates (PKC). Clients need to have certificate before they can login. Used mainly in business-business scenarios.
  • FORM: You can create custom login form in HTML. Login Info is transmitted in a least secure way among all the four as username and password are transmitted in the HTTP with no encryption. Turn on SSL or session Tracking, or the container might not recognize the login form when it is returned.

Configuration for form based authentication.








Inside the login.html page

<form method=”post” action=”j_security_check”>

<input  type=”text” name=”j_username”>

<input type=”password” name=”j_password”>

<input type=”submit”     value=”Enter”>


Inside loginError.html

<html><body>Wrong User Name and password</body</html>

How to define roles?

Add the following code in deployment descriptor(web.xml)




The role names has to match what is defined in the tomcat-users.xml

How to define resource/method constraints?

Add the following code in  deployment descriptor(web.xml)



<!–   Mandatory name used by tools. You do not see this name any where else–>


<!– Defines the resources to be constrained –>



<!– Describes which HTTP methods are constrained for the resources defined by  the url –>



<!–lists who is allowd to do  GET and POST on the specified URL pattern –>






You must specify at least one <url-pattern>

If no HTTP methods are specified then all methods will be constrained. This means that the resources can be accessed only by the roles in <auth-constraint>

You can have more than one <web-resource-collection> element. The <auth-constraint> element applies to  all <web-resource-collection> element in the <security-constraint>

If an <auth-constraint> element exists with no<role-name> element, then no users are allowed.

<role-name>*</role-name> specification allows all users. Role names are case sensitive.

<security- constraint> element is optional.

If an <auth-constraint> exists, the container must perform authentication for the associated URLs.

If an <auth-constraints> does not exist, the container must allow unauthenticated access to URLs.

Three HTTP request methods that are associated with programmatic security are

  • getUserPrincipal().
  • getRemoteUser().
  • isUserInRole().

To Link role in the programmatic security request function isUserRole(roleName) to what is specified in the  <role-name> see the following declaration in deployment descriptor

In Code:






In Deployment Descriptor (web.xml)

<web-app …>











Implementing data confidentiality and Integrity

  • use <security-constraint> to define data confidentiality and integrity.

Add the following in the deployment descriptor <security-constraint> element




The following are the valid values for <transport-guarantee>

  1. NONE (default): No data protection.
  2. INTEGRAL: Data must not be changed along the way.
  3. CONFIDENTIAL:  Data must not be seen by any bone along the transmission.

Every container virtually uses SSL for transport. So, Integral or confidential does the same thing.

Source: Head First Servlets and JSP


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s