HttpServletRequest - RequestDispatcher - Forward - is not using Constraint

[Jeff Bradford]

We have a Servlet that is being called via a standard POST (http).

The Servlet is doing a RequestDispatch FORWARD to a JSP. We would like that JSP to be called via HTTPS (SSL).

We have the Constraint in web.xml below in place, but it still uses http://localhost::8080 when routing to the JSP

<security-constraint>
<web-resource-collection>
<web-resource-name>Restricted URLs</web-resource-name>
<url-pattern>/sso.jsp</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>


However, if you hit the JSP directly from the Browser it does switch the URL over to SSL.

Any ideas?


Thanks,
Jeff

[Abimaran Kugathasan]

I think, the web.xml security constraint is for direct access from client.

[Jeff Bradford]

That appears to be true. I found this.

Security constraints work only on the original request URI and not on calls made through a RequestDispatcher (which include <jsp:include> and <jsp:forward>). Inside the application, it is assumed that the application itself has complete access to all resources and would not forward a user request unless it had decided that the requesting user also had access.

[Bear Bibeault]

You cannot change the protocol midstream. The HTTP request has already been made, it can't be changed after-the-fact.

[Jeff Bradford]

We ended up turning on SSL for the entire site instead.

<security-constraint>
  <web-resource-collection>
    <web-resource-name>Restricted URLs</web-resource-name>
    <url-pattern>/*</url-pattern>
    <http-method>GET</http-method>
    <http-method>POST</http-method>
  </web-resource-collection>
  <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
  </user-data-constraint>
</security-constraint>

[Hebert Coelho]

Haha, simple solution! ^^

gratz, Jeff Bradford

[Abimaran Kugathasan]

Bear Bibeault wrote:You cannot change the protocol midstream. The HTTP request has already been made, it can't be changed after-the-fact.

Correct! Can't it redirect the client to request over SSL, if the request contains access to restricted resources implicitly?