By nitkal on Dec 24, 2009
The http-method-omission element
Now that Java EE 6 has been officially released and Glassfish v3 (the first application server that supports Java EE 6) is shipped along with it, it might be beneficial to see what are the new features (in security) that are added to Java EE 6 and are implemented in Glassfish v3. The servlet 3.0 specification brings in many new features of security. This post illustrates one feature - the new http-method-omission element.
As many developers working in web security would know, currently, to protect a set of resources with an auth-constraint, the security-constraint element is added to the portable deployment descriptor (the web.xml).
For instance in Java EE 5,
the above element indicates that the resource referenced by the url pattern /test.jsp, when accessed by all the http-methods except GET , should be constrained to be viewed only by authenticated users belonging to the role dev. Please note that the security constraint does not apply for the http-method GET, but only for the other methods (POST, HEAD, PUT, etc).
In Java EE 6, there is an additional facility - http-method-omission, by which one could specify the methods that are omitted from the constraint.
For instance, the above security-constraint element could be re-written as :
which means that the auth-constraint for the resource accessible by the url-pattern /test.jsp is applicable for all methods except GET. This is a simpler alternative of providing the constraint methods.
Here is another example web-application that uses the http-method-omission element. As can be observed in the web.xml, there are two security-constraint elements. In the first one, all the methods except POST are precluded from accessing the resource. In the second constraint, only GET and POST are allowed conditional access to the same resource. The combined effect of the constraints is that, only POST is allowed conditional access to the resource.
A single web-resource-collection element cannot have both http-method and http-method-omission elements. In those cases, distinct web-resource-collection elements under distinct security-constraint elements must be provided. Whether or not a given http-method is applicable for an auth-constraint is obtained as per the algorithm defined in the spec:
"...an HTTP method is said to occur within a web- resource-collection when no HTTP methods are named in the collection, or the collection specifically names the HTTP method in a contained http-method element, or the collection contains one or more http-method-omission elements, none of which names the HTTP method...."
Please refer to Chapter 13, Sec 8.1 of the Servlet 3.0 spec for more details on the rules for combined security-constraints.