Hello Everyone,
I believe I found a problem in the Glassfish interpretation of some combinations of security constraints in the deployment descriptor of web applications.
In particular, the problem seems to occur whenever one or more security constraints apply to the context root of a web application (/) and other constraints apply instead to every path under the context root (/*). One such example is given by the following configuration:
<!-- Security Constraint SC1 -->
<security-constraint>
<web-resource-collection>
<web-resource-name/>
<url-pattern>/*</url-pattern>
</web-resource-collection>
</security-constraint>
<!-- Security Constraint SC2 -->
<security-constraint>
<web-resource-collection>
<web-resource-name/>
<url-pattern>/</url-pattern>
</web-resource-collection>
<auth-constraint/>
</security-constraint>
According to Servlet spefication [1, 13.8.3] a HTTP request directed to the context root (such as "GET /") shall be denied in this case, since SC2 has the "best matching" URL pattern. In contrast, Glassfish allows any (even unauthenticated) requests to the context root. Notice that Tomcat behaves instead as prescribed by the Servlet specification and denies all the requests directed to the context root.
Does anyone know if there is any explanation to this behaviour?
[1]
http://jcp.org/aboutJava/communityprocess/final/jsr315/index.html
Matteo Casalino
Research Associate
Security & Trust
SAP Research, SAP Labs France SAS
805, avenue du Dr. Maurice Donat
06254 Mougins Cedex
T +334 92 28 - 63 42
E matteo.maria.casalino_at_sap.com
W
http://www.sap.com/research