Introduction

Security is one of those aspects of development that often gets relegated to the end of the programming process. It seems like customers expect security features can be bolted on to an application. What makes things worse is you can implement security in many ways. When it comes to building security into an application, determine the requirements before you start coding. Additionally, it can be tempting to let technology drive requirements. Some technologies are flexible and let you get away with this, but when it comes to security, this is not the case. Choosing one security approach or technology over another without understanding what the user wants and needs can leave you scrambling at the end of the development cycle. You don't want to be recoding your entire security layer before your application goes into production.

Security features center around two basic concepts: authentication and authorization. Users authenticate to the system to prove they are who they say they are. Authorization allows or disallows access to certain application features. Authentication requirements are usually specific and concrete:

Anybody can access the welcome page of the application. But if a users attempt to access any other page they will have to log in with a username and password.

Authorization needs tend to be broad and vague. In many cases, authorization rules can be complex, particularly if the authorization requirements are based on hierarchical or matrix-style organizations:

Users can only look at the data they own. The user's manager can look at any information for users that work for him. Administrators can look at anybody's data but can only modify the data if approved by a manager.

Before you start coding to meet these requirements, ensure you understand what the various approaches to security can and cannot do. Security mechanisms for J2EE and Java-based applications fall into two broad categories: container-managed security and application-managed security. Container-managed security is specified as part of the J2EE and Servlet specifications. Any spec-compliant application serversuch as Tomcat, JBoss, Weblogic, or Webspheresupports container-managed security. Since Tomcat isn't an EJB container, it supports container-managed security as specified in the Servlet specification. Full-blown J2EE containers will support container-managed security for EJB applications and web applications.

Many think container-managed security is too restrictive. It's somewhat ironic that using container-managed security can lead to portability issues. The reason is that each container implements container-managed security in different ways. For example, each container has its own way of configuring security realms. A security realm provides data to the container used to authenticate and authorize users. This data could come from a database, an LDAP server, a flat file, or some other storage repository. If you use container-managed security, you'll have to make changes to your application's configuration if you want to deploy the application on a different application server. Several recipes related to setting up container-managed security are presented in this chapter.

With application-managed security, you're responsible for developing the security features of your specifications. You'll have to write more code; however, you won't have to compromise on the requirements. Many applications manage their own security requirements for this reason alone. Servlet filters, available on containers that support the Servlet 2.3 specification, provide a great vehicle for implementing application-managed security. This chapter provides many recipes focused on application-managed security. These recipes range from the use of base Actions to full-blown custom filters for authentication and authorization.

SecurityFilter is an open source servlet filter that provides the convenience and features of container-managed security yet allows the flexibility of application-managed security. This chapter includes a recipe that shows you how to use this powerful tool.

The Solutions and code samples in this chapter provide examples that demonstrate various approaches to security. As you look at the Recipes in this chapter, keep in mind that Security is rarely something a single solution can cover. Instead, you may want to employ a combination of solutions to fulfill your requirements.