On 17/09/2022 14:46, Kerry wrote:
<snip/>
I deployed a stand-alone instance of Tomcat with the following web.xml:
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd";
version="4.0"
metadata-complete="true">
<display-name>Security Test Deployment</display-name>
<description>
Testing of Security constraints.
</description>
<security-role>
<role-name>privileged</role-name>
</security-role>>
<security-constraint>
<web-resource-collection>
<web-resource-name>protected pages</web-resource-name>
<url-pattern>/protected/*</url-pattern>
</web-resource-collection>
</security-constraint>
</web-app>
I then placed two jsp files in the root folder for the application:
1. index.jsp - in the root folder for the application
2. protected.jsp in a sub-folder 'protected' to match the above url-pattern
I found that with this configuration I was able to access
/protected/protected.jsp without any authorisation.
This behaviour is correct. As per section 13.8 of the Servlet specification:
"If no authorization constraint applies to a request, the container must
accept the request without requiring user authentication."
Note: An "authorization constraint" is the "<auth-constraint>" element
that may be nested under a "<security-constraint>" element.
> However I found that if I placed an empty 'auth-constraint' element in
the web.xml then I could NOT access /protected/protected.jsp without
authorisation. e.g include the following in web.xml:
<auth-constraint>
</auth-constraint>
This behaviour is correct. As per section 13.8 of the Servlet specification:
"An authorization constraint that names no roles indicates that
access to the constrained requests must not be permitted under any
circumstances."
As you have found "No authorization constraint" != "Authorization
constraint without any roles".
In some respects this does comply with the servlet spec. because no
roles were given however I would have expected if the 'auth-constraint'
were missing it would be the same as it existing but with no roles
specified.
Your expectation is not correct. It is an understandable expectation,
but it is not correct.
Further, I also found that attempting to limit the type of http method
used did not appear to work. e.g. having:
<display-name>Security Test Deployment</display-name>
<description>
Testing of Security constraints.
</description>
<security-role>
<role-name>privileged</role-name>
</security-role>>
<security-constraint>
<web-resource-collection>
<web-resource-name>protected pages</web-resource-name>
<url-pattern>/protected/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>privileged</role-name>
</auth-constraint>
<http-method>PUT</http-method>
</security-constraint>
I anticipated an unauthorised GET on the /protected/* url to fail but
completes successfully.
This is also correct. If you specify HTTP methods as part of a
constraint then the constraint applies ONLY to those methods.
See section 13.8.4 for more details of constraints and uncovered HTTP
methods.
I have tried the above steps on an instance of Jetty and it exhibits the
same behaviour as Tomcat. I have little direct experience of working
with either Tomcat or Jetty and with Spring Boot and the Keycloak Spring
Boot starter I am one step removed from the Tomcat configuration.
My concern here is that it appears quite easy to misconfigure Tomcat via
the Keycloak application.properties and not be aware of unsecured end
points. If this is an issue then it appears to lie within Tomcat as I
can reproduce my original issue seen with a Spring Boot application in a
stand-alone instance of Tomcat and a simple hand-craft application
deployed to it.
There is no Tomcat issue here. Tomcat is behaving as required by the
Servlet specification.
I strongly recommend reading the relevant sections of the Servlet
specification.
Is what I am seeing expected behaviour?
Yes.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
