Name

<security-constraint>

Synopsis

The <security-constraint> element contains a <web-resource-collection> subelement that defines the resources to be protected and an <auth-constraint> subelement that defines who has access to the protected resources. It can also contain a <user-data-constraint> subelement that describes security requirements for the connection used to access the resource:

<security-constraint>
  <web-resource-collection>
    <web-resource-name>admin</web-resource-name>
    <url-pattern>/admin/*</url-pattern>
    <http-method>GET</http-method>
  </web-resource-collection>
  <auth-constraint>
    <role-name>admin</role-name>
  </auth-constraint>
  <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</ transport-guarantee>
  </user-data-constraint>
</security-constraint>

Within the <web-resource-collection> element, the resource is given a name with the <web-resource-name> subelement, and the URI patterns for the protected resources are specified with <url-pattern> elements. <http-method> sub-elements can also restrict the types of accepted requests. This example protects all resources accessed with URIs that start with /admin and says that only the GET method can access these resources.

The <role-name> subelements within the <auth-constraint> element specify the roles the current user must have to get access to the resource. The value should be a role name defined by a <security-role> element, but some containers (such as Tomcat) accept role names that aren’t defined by <security-role> ...

Get JavaServer Pages, Second Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.