Web Resource Collection
Web Resource Collection
<url-pattern>/example</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>exampleRole</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
As shown in the example, a security constraint (<security-constraint> in deployment
descriptor) consists of the following elements:
Web resource collection (web-resource-collection)
A web resource collection is a list of URL patterns (the part of a URL after the host name and
port which you want to constrain) and HTTP operations (the methods within the files that
match the URL pattern which you want to constrain (for example, POST, GET)) that describe
a set of resources to be protected.
Authorization constraint (auth-constraint)
An authorization constraint establishes a requirement for authentication and names the
roles authorized to access the URL patterns and HTTP methods declared by this security
constraint. If there is no authorization constraint, the container must accept the request
without requiring user authentication. If there is an authorization constraint, but no roles
are specified within it, the container will not allow access to constrained requests under any
circumstances. The wildcard character * can be used to specify all role names defined in the
deployment descriptor. Security roles are discussed in
User data constraint (user-data-constraint)
A user data constraint establishes a requirement that the constrained requests be received
over a protected transport layer connection. This guarantees how the data will be
transported between client and server. The choices for type of transport guarantee include
NONE
, INTEGRAL, and CONFIDENTIAL. If no user data constraint applies to a request, the
container must accept the request when received over any connection, including an
unprotected one. These options are discussed in
Security constraints work only on the original request URI and not on calls made throug a
RequestDispatcher
(which include <jsp:include> and <jsp:forward>). Inside the
application, it is assumed that the application itself has complete access to all resources and
would not forward a user request unless it had decided that the requesting user also had access.
Many applications feature unprotected web content, which any caller can access without
authentication. In the web tier, you provide unrestricted access simply by not configuring a
Defining Security Requirements for Web Applications
Chapter 30 · Securing Web Applications
855
