To protect a web resource typically we add a security constraint CONFIDENTIAL in the web.xml in the case of Java Technology. That means that this resource is protected and can only be accessed via HTTPS. How this works is this way. Browser sends the request to the resource . Container intercepts and sends a redirect url which is the https URL. Browser again sends the request via HTTPS. The advantage is this mechanism will do automatic switch over of protocols. Hence by simply changing the configuration we can make which part is http and which should be https.
But the issue is when the application is accessed via a reverse proxy. In this scenario the automatic protocol switch over will contain the IP or domain name of the internal server and not of the proxy. Hence we may have to do the http to https switch over using java script from the browser. So this defeats the whole purpose of CONFIDENTIAL element. I haven't seen any where in the web.xml spec an element to specify the address or domain of the front end host . In this case reverse proxy. I think this is a serious limitation. In my view this element should be added to the JSP / Servlet spec and the web.xml should be updated.
But the issue is when the application is accessed via a reverse proxy. In this scenario the automatic protocol switch over will contain the IP or domain name of the internal server and not of the proxy. Hence we may have to do the http to https switch over using java script from the browser. So this defeats the whole purpose of CONFIDENTIAL element. I haven't seen any where in the web.xml spec an element to specify the address or domain of the front end host . In this case reverse proxy. I think this is a serious limitation. In my view this element should be added to the JSP / Servlet spec and the web.xml should be updated.
Comments