tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "CASALINO, Matteo Maria" <matteo.maria.casal...@sap.com>
Subject Nondeterministic behaviour of security constraints in Tomcat 7
Date Wed, 29 Aug 2012 15:24:54 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message