Open Source Software Technical Articles

Want the Best of the Wazi Blogs Delivered Directly to your Inbox?

Subscribe to Wazi by Email

Your email:

Connect with Us!

Current Articles | RSS Feed RSS Feed

Container-managed security for Java web applications

  
  
  

Web applications often need to provide security on application access (authentication) and on page access control rules (authorization). It can take a lot of time to implement these requirements from scratch to produce a secure application, but thanks to the Java Servlet specification, such common security requirements can be handled at the container level. This article explains how to apply container-managed security in Apache Tomcat in a Java web application for authentication and authorization.

Web application security encompasses three main areas:

  • Authentication is the act of confirming to the system users' identities.
  • Authorization defines which parts of the system users are allowed to access after authentication.
  • Data protection is about ensuring that data passing between users and the system cannot be modified or fabricated by unauthorized parties.

In the Java web applications world, web developers can rely on the security features provided by the Servlet container to implement security requirements in web applications – in other words, container-managed security. Alternatively, instead of managing the security on the container level, developers can manage security on the application level. Application-managed security does not mean implementing all of the application security features from scratch, however; application-managed security usually utilizes the security features provided by the Servlet container to implement any custom security features that customers require. If you have no reason to implement custom security for customer requirements, you should use container-managed security for Java web applications.

Container-managed security includes container-managed authentication, authorization, and data protection.

Authentication

Servlet containers can provide different types of authentication mechanisms, such as HTTP basic, form-based, and digest. Let's look at each in detail.

HTTP basic authentication

In HTTP basic authentication, the server requests a user name and password from the web client, then verifies that the user name and password are valid by comparing them against a database of authorized users in a specified or default realm. (A realm is a store for the users and the groups of the system.) Basic authentication is the default when you do not specify an authentication mechanism in the web configuration file. With basic authentication:

  • A client requests access to a protected resource.
  • The web server returns a dialog box that requests the user name and password.
  • The client submits the user name and password to the server.
  • The server authenticates the user in the specified realm and, if successful, returns the requested resource.

Form-based authentication

In form-based authentication, you can develop and customize login and error pages in your application. If form-based authentication is declared in the web configuration file (web.xml), the following scenario occurs:

  • A client requests access to a protected resource.
  • If the client is unauthenticated, the server redirects the client to a login page.
  • The client submits the login form to the server.
  • The server attempts to authenticate the user.
  • If authentication succeeds, the authenticated user's principal is checked to ensure that it is in a role that is authorized to access the resource. If the user is authorized, the server redirects the client to the resource by using the stored URL path.
  • If authentication fails, the client is forwarded or redirected to an error page.

It is important to note that HTTP basic authentication sends user names and passwords as Base64-encoded text, while form-based authentication sends them as plain text, which means they are not secure, so you should use form-based authentication only with a secure transport mechanism such as SSL.

Digest

Digest authentication authenticates a user based on a user name and a password, like basic HTTP authentication, but instead of sending passwords over the network, digest authentication sends a one-way cryptographic hash of each password.

Configuring the authentication method

To configure the authentication method in your Java web application, use the <login-config> element, as shown below in the web configuration file (web.xml):

<login-config>
   <auth-method>FORM</auth-method>
   <realm-name>some realm</realm-name>
   <form-login-config>
       <form-login-page>/index.html</form-login-page>
       <form-error-page>/error.html</form-error-page>
   </form-login-config>
</login-config>

As you can see, the <login-config> element has the following subelements:

  • <auth-method> specifies the authentication mechanism for the web application. It can be DIGEST, BASIC, FORM, or NONE.
  • <realm-name> specifies the realm name.
  • <form-login-config> specifies the login and the error pages when form-based login is used. It is mandatory for form-based login and optional for other login methods.

Authorization

Authorization defines the role-based access control that determines what the parts of the system users may access. In Java web application, to achieve this, you can use the <security-constraint> element in the web.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<web-app ...>
   ...
  <security-constraint>
       <display-name>securityConstraint</display-name>
       <web-resource-collection>
           <web-resource-name>resources</web-resource-name>
           <url-pattern>/pages/*</url-pattern>
           <http-method>PUT</http-method>
           <http-method>DELETE</http-method>
           <http-method>GET</http-method>
           <http-method>POST</http-method>           
       </web-resource-collection>
       <auth-constraint> 
           <role-name>appUser</role-name>
       </auth-constraint>
   </security-constraint>
   <login-config>
       <auth-method>FORM</auth-method>
       <realm-name>some realm</realm-name>
       <form-login-config>
           <form-login-page>/index.html</form-login-page>
           <form-error-page>/error.html</form-error-page>
       </form-login-config>
   </login-config>
   ...
</web-app>

<security-constraint> defines the access privileges for a collection of resources using their URL mapping. It can contain the following elements:

  • Web resource collection (<web-resource-collection>) is a list of URL patterns and HTTP operations that describe a set of resources to be protected.
  • Authorization constraint (<auth-constraint>) specifies whether authentication is to be used, and names the roles authorized to perform the constrained requests.
  • User data constraint (<user-data-constraint>) specifies how data is protected when transported between a client and a server, as we will see below.

A web resource collection (<web-resource-collection>) in turn contains the following elements:

  • <web-resource-name> (optional) is the name you use for the web resource.
  • <url-pattern> is the request URI to be protected.
  • <http-method> specifies which methods should be protected.

An authorization constraint (<auth-constraint>) contains the <role-name> element. You can use as many <role-name> elements as you need inside the <auth-constraint> element. The roles defined for the application must be mapped to users and groups defined in the Servlet container. Every container has its own way of declaring the mapping of roles to users and groups; we'll see how to do this with Tomcat 7 in a moment.

Data protection refers to securing data that is transferred between client and server. For data protection in Java web applications, you can use the <user-data-constraint> element of <security-constraint> in web.xml as shown below:

<security-constraint>
   <display-name>securityConstraint</display-name>
   <web-resource-collection>
	   <web-resource-name>resources</web-resource-name>
	   <url-pattern>/pages/*</url-pattern>
	   <http-method>PUT</http-method>
	   <http-method>DELETE</http-method>
	   <http-method>GET</http-method>
	   <http-method>POST</http-method>           
   </web-resource-collection>
   <auth-constraint> 
	   <role-name>appUser</role-name>
   </auth-constraint>
   <user-data-constraint>
	   <transport-guarantee>CONFIDENTIAL</transport-guarantee>
   </user-data-constraint>       
</security-constraint>

The <user-data-constraint> element contains a <transport-guarantee> element that specifies the communication between client and server. Its possible values are NONE, INTEGRAL, or CONFIDENTIAL. INTEGRAL means that the application requires the data to be sent between the client and the server to be in such a way that it cannot be changed by a malicious third party, while CONFIDENTIAL means that the application requires preventing third parties from observing the contents of the transmission. Both INTEGRAL and CONFIDENTIAL imply SSL, and in practice, Java web containers treat the two transport guarantee values identically.

Applying managed security in Tomcat

Now that we know about all the elements, let's see how to apply container-managed security with form-based authentication in a sample Java web application that has the following structure:

  • index.html represents the home page.
  • error.html represents the error page that is displayed when user credentials are invalid.
  • The pages folder contains all of the protected application pages that can be accessed by users.

First, let's create the form-based authentication's login form in index.html:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<title>Login Page</title>
</head>
<body>
   <!-- Form authentication -->
   <form action="j_security_check" method="POST">
      Username:<input type="text" name="j_username"></input><br/>
      Password:<input type="password" name="j_password"></input><br/>
      <input type="submit" value="Login"></input>
   </form> 
</body>
</html>

As shown here, to use form-based authentication you should use the HTML <form> tag. Set the form action to "j_security_check" and the form method "POST." Set the names of the username and password fields to "j_username" and "j_password." Finally, add a submit button to submit the form.

The next code snippet shows the form-based authentication configuration in web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app ...>
  ...
  <security-constraint>
       <display-name>securityConstraint</display-name>
       <web-resource-collection>
           <web-resource-name>resources</web-resource-name>
           <url-pattern>/pages/*</url-pattern>
           <http-method>PUT</http-method>
           <http-method>DELETE</http-method>
           <http-method>GET</http-method>
           <http-method>POST</http-method>           
       </web-resource-collection>
       <auth-constraint> 
           <role-name>appUser</role-name>
       </auth-constraint>      
  </security-constraint>
  <login-config>
       <auth-method>FORM</auth-method>
       <realm-name>UserDatabase</realm-name>
       <form-login-config>
           <form-login-page>/index.html</form-login-page>
           <form-error-page>/error.html</form-error-page>
       </form-login-config>
  </login-config>
  <welcome-file-list>
    <welcome-file>pages/welcome.jsp</welcome-file>
  </welcome-file-list>  
  ...
</web-app>

In the security constraint part, only the appUser role is able to access the resources under the pages folder (/pages/*). In the login configuration part, the authentication method is set to FORM and the realm name is set to "UserDatabase," and in the form login configuration, the login page is set to be index.html and the error page is set to be error.html. When user login succeeds, the user is forwarded to the welcome.jsp page under pages folder.

The appUser role defined for the application must be defined in tomcat-users.xml file under the <TOMCAT-HOME>/conf folder:

<?xml version="1.0" encoding="UTF-8"?>
<tomcat-users>	
    <role rolename="appUser"/>
    <user username="john" password="password" roles="appUser"/>
    <user username="testuser" password="password1" roles="appUser"/>
  	  	
    <!-- add more users here -->
</tomcat-users>

Here we see a defined role (appUser) and two defined users, john and testuser, that belong to it. You can add roles and users to this file using <role> and <user> tags.

When the application runs, if a user enters valid credentials for a user that belongs to the appUser role, the user will be forwarded to the welcome.jsp page. The following code snippet shows the welcome.jsp page code:

<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
  <title>Welcome</title>
</head>
<body>
  <h1>Welcome, <%= request.getUserPrincipal().getName() %></h1>
</body>
</html>

The getUserPrincipal().getName() API of HttpServletRequest class retrieves the login name of the logged-in user. (To log a user out, you can call the logout() method of the HttpServletRequest class.) If a user enters invalid credentials, the user will be forwarded to the error.html page:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<title>Error Page</title>
</head>
<body>
  <h1>Forbidden access</h1>
</body>
</html>

By adding information to the default realm, using Tomcat, you can also configure different data sources, including LDAP directory servers and relational databases, as Tomcat realms.

Conclusion

I hope this article has helped illustrate the differences between authentication, authorization, and data protection. You should now be able to use the authentication mechanisms offered by Java web containers and apply form-based authentication and authorization in a Java web application powered by the Apache Tomcat Servlet container.




This work is licensed under a Creative Commons Attribution 3.0 Unported License
Creative Commons License.

Comments

A number of popular stores selling the wholesale Replica Purses are now available. The appearance houses are aggravating their best to stop the auction of Replica Gucci Handbags. However, their efforts acquire failed. On the added side, those affairs Replica Handbags are blooming and growing in numbers. In actuality the antagonism a allotment of the rolex replica makers is flourishing. The added aggressive they become the bigger superior Louis Vuitton Handbags the barter get. Do not be bamboozled by the name of the Replica Watches. Even admitting it is not the aboriginal, the attending, feel and adroitness of the Replica Rolex watches are altered and are apprenticed to fool even the adept who apperceives all to able-bodied about the aboriginal.
Posted @ Tuesday, December 31, 2013 2:35 AM by angel
Tag heuer watches as a global luxury sales wrist watch brands in the top five, demonstrating, tag heuer watches have been loved by the people.No matter men or women should have a tag heuer watches.Expensive price tag heuer watch, of course, the <strong>tag heuer replica watches</strong> appeared in the watch market, with a tag heuer watch is no longer a difficult task.Don't need $200 you can get a high quality tag heuer replica watches http://www.tagheuerwatch.net/, go to the choose and buy one.
Posted @ Wednesday, February 19, 2014 12:38 AM by jasonwongoo
In picking out a fantastic leather circumstance, it's essential to 1st take into account 3 issues, the functionality correct, the quality of craftsmanship, lastly the case's aesthetic value.Functionality planned, it's very best to pick out a new casing that grants accessibility to pretty much all in the iPad minis ports. You wouldn't wish to retain stripping the circumstance time and again just to dock the tool for charging or syncing uses. Ease of interaction also plays a role. Normally, you would want a casing that capabilities a go over that easily gets dealt with when you should gain access to your iPad mini.Next, will be the standard of craftsmanship? Though Italian leather-based sets the gold standard in relation to leather, you don't have to have to break the bank since you'll find numerous of high quality alternatives that suit your spending budget.  
 
gucci iPhone 5 Cases 
Chanel iPhone 5s Cases 
hermes iPhone 5s Cases
Posted @ Tuesday, April 29, 2014 2:22 AM by iphone4scase
the vary of protection straight away will increase.For starters, dust and air pollution is saved away.Could can assess this mom in regulation gmail code Firstly, A singular inadequate and improper at the same time running illegally. And a true breach together with your loved one's volume of solitude, Can you want a person and all to determine your site? Or just private Paypal membership or yoru credit-based card own bank loan company private identification number, I dount seek to are direct to believe pretty! Appropriately even if out and together with make sure you don't spy! Additionally. 
iPhone 5 Cases 
iPhone 5S Cases 
iPhone 5S Cases 
iPhone 5S Cases
Posted @ Wednesday, April 30, 2014 2:24 AM by iPhone 5 Cases
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics