Hello everyone,
I'm experiencing a weird behaviour with certain combinations of security
constraints having the following pattern:
(i) one security constraint applies to (at least) two overlapping URL patterns
ending in /*, where one is more specific than the other (e.g., /a/* and /a/b/*)
(ii) a second security constraint applies only to the less specific URL pattern
(e.g. /a/*), and
(iii) the two security constraints apply to different (possibly overlapping)
sets of methods.
One such example is as follows:
<servlet-mapping>
<servlet-name>test</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>test</realm-name>
</login-config>
<security-constraint>
<web-resource-collection>
<web-resource-name/>
<url-pattern>/a/*</url-pattern>
<url-pattern>/a/b/*</url-pattern>
<http-method>POST</http-method>
</web-resource-collection>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name/>
<url-pattern>/a/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint/>
</security-constraint>
The problem occurs for HTTP requests matching to the most specific URL pattern
(in the above example, /a/b, /a/b/c, etc.), but on methods other than the ones
mentioned in the first security constraint (in the above example, GET).
For instance, each time I deploy a web application with the above-mentioned
deployment descriptor in Tomcat, or each time I redeploy it or restart the
server in case it is already deployed, I get randomly either of the two
following behaviours:
1) "GET /a/b" requests are allowed, i.e. no authentication is required
2) "GET /a/b" requests are denied, i.e. the response requires authentication
(HTTP 401)
Notice that the behaviour remains then constant until I restart the server or
re-deploy the application. Also, adding arbitrary roles in either of the two
auth-constraints, does not seem to change the result.
According to the Java Servlet Specification, 1) is the correct behaviour. In
fact, such requests shall be allowed to any (possibly unauthenticated) users,
because the constraint with the most specific pattern (the first one) matches
to the request, but it does not mention the method of the request (GET).
I tested several different combinations of security constraints, but this issue
seems to occur only with those of this kind.
Tests were done on Tomcat 7.0.29 running on both a Debian and a Windows machine.
Have anyone experienced a similar problem or is aware of possible explanations?
Best regards,
Matteo Casalino
Research Associate
Security & Trust
SAP Research, SAP Labs France SAS
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
