Web app security using Struts, servlet filters, and custom taglibs

Ready-made components easily add security to your Web projects


Enterprise-level business applications need rigorous security regulations with varying roles; each role also requires its own set of access control lists. These roles become more important in Web-based applications, which are accessible to a wider audience. In most cases, application security must control access to each attribute that's visible on the screen.

In this article, you will develop a generic security solution that can be used by most enterprise-level Web applications. You will address the problem of Web application security by breaking it into two smaller, manageable units:

  • Page-level security, which involves access control at a page level
  • Attribute-level security, which involves access control at an attribute level

Why split the problem along these lines? You can solve these two problems using different technologies in the J2EE space. As you may have guessed by now, page-level security is coarse-grained security, in which the user either is allowed or denied access to a particular page. On the other hand, attribute-level security is enforced at a very granular level, with security checks performed on each attribute that's displayed on the screen.

In a typical organization, many users play multiple roles, and a good security architecture recognizes this. Thus, you can assume that your users are allowed to play multiple roles within the application. With this scenario as the project, and already split into manageable units, you're ready to delve right into the solution.

The Intercepting Filter pattern

The servlet filters introduced with version 2.3 of the Java Servlet specification lend themselves towards a solution for the page-level security problem. I will detail the workings of Servlet filters here; you can download the Servlet 2.3 specs (see Related topics) and learn more about them. You will write a security filter that performs the necessary checks to ensure that the user accessing a page is allowed to view that page. Because the security check must be performed for each user, you will encapsulate this logic into a helper Java class and store it in the user's session. For the sake of performance, you will cache the user's security profile into this class so you do not have to make a database call every time a request is made to the application. In this application, security role information is stored in a database, but you could easily rewrite you code to store it somewhere else, like in an XML file. I will not get into the details of the security schema either, as this can be specific to each application. The security class is an implementation of the SecurityHelper interface, which is illustrated in Listing 1.

Listing 1. The SecurityHelper interface
   public interface SecurityHelper {
     //method to check page level access 
     public boolean isAccessAllowed(String uri);

     //method to check if the attribute can be viewed by the user
     public boolean isViewableField(String page, String attribute);

     //method to check if the attribute can be edited by the user
     public boolean isEditableField(String page, String attribute);

     //method to refresh the cached user roles if there is some change
     public void refreshCache();

The SecurityFilter class uses the SecurityHelper class, illustrated in Listing 2, to perform the page-level checks. The method isAccessAllowed(uri) is used to see if a user has permission to view or modify the page specified by uri. The actual page that is displayed can vary depending on the result of processing. However, I assume here that each individual URI will, when passed to isAccessAllowed(), result in one of a related set of pages; if it does not, then you can modularize the application to achieve this effect. To perform the security checks, override the Java Servlet specification's doFilter() method, as shown in Listing 2.

Listing 2. The SecurityFilter class
  public class SecurityFilter implements Filter {
    public void doFilter(ServletRequest req, ServletResponse res,
                    FilterChain chain) throws IOException, ServletException {
        //Get the user's security profile of the user from the session 
        //If the session is invalid, redirect to some login/invalid page.
        SecurityHelper userSecObj = session.getAttribute(SECURITY_PROFILE);
        //Compare the current URI with the access associated with the access 
        //to that URI for the role using the userSecObj. 
        accessAllowed = userSecObj.isAccessAllowed(requestUri);
        if(accessAllowed) {
          //If the user is allowed access to the URI, let the flow proceed as normal
          chain.doFilter(request, response);
          //if the user is not allowed access, you can redirect him to an error page.

Listing 2 is the core of the page-level filter. This code assumes that the user's profile (or role) is already in the session when the request comes to the filter. Since you are not assuming any single form of authentication, you can use this model in conjunction with tools like SiteMinder (see Related topics), which can do the authentication for you. You get the URI from the request object. You then compare the access permissions that the user's current roles have for the requested URI and proceed according to those permissions. Note that you can make this comparison with a list of user roles, if the application mandates that each user play multiple roles; the logic for that would be embedded in the implementation for the SecurityHelper class.

Now that you have taken care of the page-level security, I'll move on to the second part of the challenge, which is to ensure that the user does not view or modify any attribute that he or she should not have access to.

JSP custom tags and Struts

You will develop custom JSP tags to achieve field-level security checks. (If you're unfamiliar with custom JSP tags, check out the tutorials on the subject listed in Related topics.) You will use custom security tags for each type of component that you plan to display, such as a combo box or a text field. You will use the SecurityHelper class outlined in Listing 1 for the access rights checks. You will also leverage the tags developed in Struts to build custom security tags. Struts has implementations for most HTML tags and supports most attributes that are required for these tags. The SecurityHelper class methods isEditableField() and isViewableField() hase the logic for ensuring that the displayed field has the required permission for the roles that the user plays, and makes the component visible or disabled, accordingly.

Listing 3. The SecurityCombo class
    public class SecurityComboTag extends org.apache.struts.taglib.html.SelectTag {
        //this attribute stores the attribute that's being shown on the screen.
        private String attribute;
        //this attribute stores the page that's being shown
        private String page;
        public int doStartTag() throws JspException{
            //check the access using the SecurityHelper class
            //Helper instance is obtained from the session
            isViewable = securityHelper.isViewableField(page, attribute);
            if(!isViewable) {
                return SKIP_BODY;
	    isModifiable = securityHelper.isViewableField(page, attribute);
            if(!isModifiable) {

Listing 3 shows a sample implementation for a drop-down box. The class has two attributes: one for storing the name of the attribute that's currently being rendered using the select tag, and one for the page on which the tag is present. You then pass on the page and the attribute to the SecurityHelper class's methods to see if the user is allowed to view and/or modify the particular attribute, and change the display accordingly. Since this piggybacks onto the Struts implementation, you do not have to render the tag, but can just concentrate on the security aspect of it. Also, all the security logic is embedded in the implementation of the SecurityHelper class, thus keeping the security check code in a central place.

Running the code

To try out the security framework outlined here, you need a Web container that supports Servlets 2.3 or higher. Apache Tomcat works for this purpose; get the download info for it from Related topics. The latest version of Tomcat has the required support for this security implementation. The framework also relies on the taglibs that are defined in Apache Struts; you can download this from Related topics as well. Finally, if you want to look at the skeleton of the code samples given above, click the Code button at the top or bottom of this article. The sample zip file,, contains,, and

In conclusion

In this article, you have developed a powerful Web-based security architecture that is flexible enough to cater to a wide range of Web-based applications. You have also leveraged existing technologies such as Struts, which have helped maintain a clean separation of security and presentation code. You can also plug the security model into any existing application; it works well with third-party authentication providers.

Attribute-level security, although a useful feature in most applications, is often ignored because of the effort involved in its implementation and the degrading effect it has on application performance. The architecture defined in this article makes it easy to implement this useful feature without compromising on performance. The architecture also helps you maintain a clean separation between the security requirements and the functional requirements of the application. You, as the application developer, can concentrate on developing the business functionality without worrying about the security aspects, and your application is easier to maintain.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=Web development
ArticleTitle=Web app security using Struts, servlet filters, and custom taglibs