The <security-constraint> rules for <web-resource-collection> elements

Remember; the purpose of the <web-resource-collection> sub-element is to tell the container which resources and HTTP Method combinations should be constrained in such a way that they can be accessed only by the roles in the corresponding <auth-constraint> tag. We wish we could tell you to relax here, but you really do need to know the details of these elements. If you make one little mistake in the security part of your DD, you could leave the most sensitive parts of your app open to... everyone.

Key points about <web-resource-collection>

  • The <web-resource-collection> element has two primary sub-elements: <url-pattern> (one or more) <http-method> (optional, zero or more).

  • The URL patterns and HTTP Methods together define resource requests that are constrained to be accessible by only those roles defined in <auth-constraint>.

  • A <web-resource-name> element is MANDATORY (even though you probably won’t use it for anything yourself). (Assume it’s for IDE or future use.)

  • A <description> element is OPTIONAL.

  • The <url-pattern> element uses servlet standard naming and mapping rules (refer back to the deployment chapter for details on URL patterns).

  • You must specify at least one <url-pattern>, but you can have many.

  • Valid Methods for the <http-method> element are: GET, POST, PUT, TRACE, DELETE, HEAD, and OPTIONS.

  • If no HTTP Methods are specified then

    ALL Methods will be constrained (which means they can be accessed only by the roles in <auth-constraint>)!!

  • If you DO specify an <http-method>, then only those methods specified will be constrained. In other words, once you specify even a single <http-method>, you automatically enable any HTTP Methods which you have not specified.

  • You can have more than one <web-resource-collection> element in the same <security-constraint>.

  • The <auth-constraint> element applies to ALL <web-resource-collection> elements in the <security-constraint>.

The <web-resource-collection> sub-element of <security-constraint>

image with no caption

Note

Constraints are not at the RESOURCE level. Constraints are at the HTTP REQUEST level.

It’s tempting to think that resources themselves are constrained. But it’s really the combination of resource + HTTP Method. When you say, “This is a constrained resource”, what you’re really saying is, “This is a constrained resource with respect to HTTP GET.” A resource is always constrained on an HTTP method by HTTP Method basis, although you CAN configure the <web-resource-collection> in such a way that ALL Methods are constrained, simply by not putting in ANY <http-method> elements.

The <auth-constraint> element does NOT define which roles are allowed to access the resources from the <web-resource-collection>. Instead, it defines which roles are allowed to make the constrained request. Don’t think of it as “Bob is a Member, so Bob can access the AddRecipe servlet”. Instead, say “Bob is a Member, so Bob can make a GET or POST request on the AddRecipe servlet.”

Note

If you specify an <http-method> element, all the HTTP methods you do NOT specify are UNconstrained!

The web server’s job is to SERVE, so the default assumption is that you want the HTTP Methods to be UNconstrained unless you explicitly say (using <http-method>) that you want a method to be constrained (for the resources that match the <url-pattern> ). If you put in ONLY an <http-method>GET</http-method> in the security constraint, then POST, TRACE, PUT, etc. are not constrained! That means anybody, regardless of security role (or even regardless of whether the client is authenticated), can invoke those HTTP Methods.

BUT... this is true ONLY if you have specified at least one <http-method> element. If you do NOT specify any <http-method>, then you’re constraining ALL HTTP Methods. (You’ll probably never do that, because the whole point of a security constraint is to constrain specific HTTP requests on a particular set of resources.)

Of course, HTTP Methods won’t work in a servlet unless you’ve overridden the doXXX() method, so if you have only a doGet() in your servlet, and you specify an <http-method> element for only GET, nobody can do a POST anyway, because the server knows you don’t support POST.

So we can modify the rule a little to say: any HTTP Methods supported by your servlet (because you overrode the matching service method) will be allowed UNLESS you do one of two things:

1) Do not specify ANY <http-method> elements in the <security-constraint>, which means that ALL Methods are constrained to the roles in <auth-constraint>.

2) Explicitly list the Method using the <http-method> element.

Remember, once you have even a single <http-method> in the security constraint, then all other supported HTTP Methods will be UNconstrained.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset