Specifying Separate Security Constraints
Specifying Separate Security Constraints
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
<security-constraint>
<web-resource-collection>
<web-resource-name>wholesale</web-resource-name>
<url-pattern>/acme/wholesale/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>PARTNER</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
// SECURITY CONSTRAINT #2
<security-constraint>
<web-resource-collection>
<web-resource-name>retail</web-resource-name>
<url-pattern>/acme/retail/*</url-pattern>
Defining Security Requirements for Web Applications
The Java EE 5 Tutorial · September 2007
856
