Securing Struts Applications - Using Container-Managed Security

(Page 2 of 8 )

To explain how to use container-managed security, this section describes how you would apply container-managed security to the Mini HR application, introduced in Chapter 2, to fulfill a particular security requirement. Assume that Mini HR resides on ABC, Inc.’s corporate intranet. The application allows anyone to access the employee search. However, only administrators can add or remove employees from the database. If someone attempts to perform an administrator function, that user is prompted to input a username and password. If the password is valid, and the user is an administrator, the application will display the requested page.

Although this security requirement can be completely fulfilled without making any modifications to Java code or JSP pages, as you will see, it is often better to group URLs under role-specific path prefixes. Therefore, you must change the location of add.jsp and add.do to /admin/add.jsp and /admin/add.do, respectively. This also means that you need to change the index.jsp page and struts-config.xml. Making these changes may seem burdensome, but it will make implementing security easier. Following are the additions needed to web.xml to implement container-managed security:

<web-pp>
    [… snipped …]
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>AdminPages</web-resource-name>
            <description>Administrator-only pages</description>
            <url-pattern>/admin/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>administrator</role-name>
        </auth-constraint>
    </security-constraint>
    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>MiniHRRealm</realm-name>
    </login-config>
    <security-role>
        <description>HR Administrator</description> 
        <role-name>administrator</role-name>
    </security-role>
</web-app>

The three XML elements (security-constraint, login-config, and security-role) that were added define the security requirements. The security-constraint element associates a collection of pages with a role. The pages are identified using URL patterns. If a user attempts to access a page that matches one of the patterns and the user has the associated role, then the user is allowed access. If the user has not yet been authenticated, the user is prompted to log in according to the settings of the login-config element. If the user authenticates and has the administrator role, then the user is redirected to the requested page.

Before discussing the login configurations, a quick detour is necessary to describe URL patterns. These patterns, also known as URL mappings, are dictated by the Java servlet specification. Four types of patterns are searched, in the following order:

• Explicit mapping  No wildcards are used (e.g., /add.jsp or /admin/remove.do).
• Path prefix mapping  Contains a/, then a path prefix, then a/*. This mapping can be used to specify an entire subbranch of your Web application (e.g.,/admin/* or /search/company/*).
• Extension mapping  Contains *. followed by a prefix. This mapping can be used to specify all files of a certain type (e.g., *.jsp). It is also often used to map Struts actions (e.g., *.do).
• Default mapping /  Matches all URLs for the Web application. This mapping matches any URL of the Web application. Any URL beginning with the context path of the Web application will match this pattern.

As you can see, these patterns are not very flexible. You cannot, for example, specify a pattern of /add.*. If you did not place the administrative URLs under a specific path prefix, you would have to explicitly list each constrained URL. From a security perspective, partitioning your application using role-based paths makes securing the application much easier. Even if you are not using container-managed security, this approach has benefits, as you will discover later, in the section “Using Servlet Filters for Security.”

If you decide to use Struts modules, then you have already established some partitioning for your application. Each module will be in its own path off the context root. Organizing modules by role is a reasonable approach—therefore, the use of Struts modules generally will make implementing your security policy easier.

Login Configurations

The login-config element indicates the type of authentication to be performed and where the user information can be found. A Web application can have only one login configuration. The auth-method nested element indicates the type of authentication and accepts the values listed and described in the following table.

 

Authentication	Description
BASIC	The browser pops up a dialog box that allows the user to enter a username and password. The username and password are encoded using the Base-64 algorithm and sent to the server. The Base-64 algorithm is a common Web encoding scheme that is often used to encode e-mail attachments and so on.
FORM	Allows for a custom form to be specified. The form must contain a j_username field for the username and a j_password field for the password. The form must submit to j_security_check. The username and password are Base-64 encoded.
DIGEST	Similar to BASIC authentication except that the username and password are encrypted into a message digest value. This configuration may not be supported by all browsers.
CLIENT-CERT	The client is required to provide a digital certificate for authentication. This is the most secure configuration. However, it also is the most costly. Certificates for production use must be purchased from a certificate authority.

In addition to specifying the type of login, the login configuration may also specify a security realm. A security realmis essentially the store from which a Web application retrieves and verifies user credentials. In addition, a realm provides a mechanism for specifying the roles that users may have. For the login configuration, no details of the realm can be provided other than the realm name. That name refers, either directly or indirectly, to a container-specific security realm implementation.

DIGEST authentication provides the same basic user experience as BASIC. However, because DIGEST authentication may not be supported by all browsers, it is not discussed further here. There are ways of encrypting the user credentials without requiring DIGEST. CLIENT-CERT requires the user to have a digital certificate. This chapter discusses only BASIC and FORM-based login because these are the authentication methods that are encountered in most situations.

Next: BASIC Login >>
 

More Java Articles
More By McGraw-Hill/Osborne

Comments On: Securing Struts Applications

· Very good article. Concepts are explained in very detail.    · i found this article very helpful ...........what should i write in the User class...    · The concepts described in the article all act on the assumption to declare the...   >>> Post your comment now!

Buy this book...

This article is excerpted from chapter 19 of the book The Complete Reference: Struts, written by James Holmes (McGraw-Hill/Osborne, 2004; ISBN: 0072231319 ). Check it out at your favorite bookstore. Buy this book now.