The Java EE 5 Tutorial (PDF) - Oracle Software Downloads

Defining Security Requirements forWeb Applications
852
security constraint for that particular request URI. It is common to have some unprotected
resources and some protected resources. In this case, you will define security constraints and a
login method, but they will not be used to control access to the unprotected resources. Users
won’t be asked to log in until the first time they enter a protected request URI.
The Java Servlet specification defines the request URI as the part of a URL after the host name
and port. For example, let’s say you have an e-commerce site with a browsable catalog that you
would want anyone to be able to access, and a shopping cart area for customers only. You could
set up the paths for your web application so that the pattern /cart/* is protected but nothing
else is protected. Assuming that the application is installed at context path /myapp, the following
are true:
■ http://localhost:8080/myapp/index.jsp is not protected.
■ http://localhost:8080/myapp/cart/index.jsp is protected.
A user will not be prompted to log in until the first time that user accesses a resource in the
cart/ subdirectory.
Specifying Separate Security Constraints for Different Resources
You can create a separate security constraint for different resources within your application. For
example, you could allow users with the role of PARTNER access to the POST method of all
resources with the URL pattern /acme/wholesale/*, and allow users with the role of CLIENT
access to the POST method of all resources with the URL pattern /acme/retail/*. An example
of a deployment descriptor that would demonstrate this functionality is the following:
// SECURITY CONSTRAINT #1
wholesale
/acme/wholesale/*
GET
POST
PARTNER
CONFIDENTIAL
// SECURITY CONSTRAINT #2
retail
/acme/retail/*
The Java EE 5Tutorial • June 2010