HSTS headers for /proxyui does not seem to be working after updating web.xml.
<filter>
<filter-name>httpHeaderSecurity</filter-name>
<filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
<async-supported>true</async-supported>
</filter>
<filter-mapping>
<filter-name>httpHeaderSecurity</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
The curl request does not return the headers:
# curl -k -I https://<servername>.example.com:<port no>/proxyui/
HTTP/1.1 302
Location: /<proxyui>/siteminderagent/forms/login.fcc?TYPE=33554433&REALMOID=<value>&GUID=&SMAUTHREASON=0&METHOD=HEAD&SMAGENTNAME=-SM-<value>&TARGET=-SM-<value>%2fproxyui%2f
Transfer-Encoding: chunked
Date: Tue, 20 Jun 2023 13:54:10 GMT
Server: Apache-Coyote/1.1
Release : 12.8.x
The ProxyValve is the first request interpreter on Tomcat.
The ProxyValve checks if the resource is protected from Policy Server.
If protected, it checks for the session, and if the session is present, it validates it with the Policy Server.
If everything is good, the ProxyValve allows the request to flow down to hit next filters, otherwise the request will return from ProxyValve itself.
In this case, the user hits /proxyui on Tomcat port.
The ProxyValve received the request, and it checks if the /proxyui is protected from the Policy Server.
The resource is protected, and as there's no session presenters, it redirects the browser to login.fcc page.
Though login.fcc being served by Tomcat, it hasn't yet hit the HSTS filter configured in web.xml, as the ProxyValve did not allow the request to flow down. It did not have a valid session, but the resource is protected.
Once there's a valid SMSESSION cookie, then the ProxyValve allows the request to hit next filters. When the request flows down the next filters, it hits the configured HSTS filter on web.xml. Then the response headers will be set.
The /proxyui/test.jpg, where the browser gets a 404 not found and headers set, isn't it supposed to redirect to the protected page here, since /proxyui is protected?
It looks like the rule is not matched, and the ProxyValve is getting not protected and allowing requests to flow down.
No issues with accessing /proxyui/test.jpg as .jpg will be in ignore extension, the resource will be let to be executed by Tomcat so headers will be set.
About the / access, is it because Tomcat doesn't all root access?
Yes