BASIC Authentication and SSL configuration failed in Tomcat 6.0

Question

The application is a simple JSP/Servlet application.I want to perform a user authentication (using BASIC Authentication) and if the user is authenticated, then I will redirect them to the home screen using SSL (i.e. https). The BASIC Authentication has to be performed on clicking a button.

For achieveing this; initially I configured the BASIC Authentication in my web.xml like this:

<security-role>
  <role-name>Admin</role-name>      
</security-role>
<security-role>
  <role-name>Guest</role-name>
</security-role>
<security-constraint>      
  <web-resource-collection>
      <web-resource-name>BasicDemo</web-resource-name>
      <url-pattern>/*</url-pattern>
      <http-method>POST</http-method>
  </web-resource-collection>
  <auth-constraint>
      <role-name>Admin</role-name>
  </auth-constraint>
</security-constraint>
<login-config>
  <auth-method>BASIC</auth-method>      
</login-config>

The user BASIC Authentcation part of the code works perfectly (the popup dialog appears asking for the username and password and it works fine)

Then I configured SSL by following the following steps:

1) Generated a Keystore using keytool

2) Added the below entry in the server.xml:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
           maxThreads="150" scheme="https" secure="true"
           clientAuth="false" sslProtocol="TLS" 
       keystoreFile="${user.home}/.keystore"
       keystorePass="password" />

3) Added this in web.xml inside the

<user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
  </user-data-constraint> 

On running the application, below are the issues I have with it:

1) On clicking the button (for which the BASIC authentication has to be performed), the dialog for authentication did not appeared (which appears for BASIC Authentication asking for username and password)

2) I was redirected to a link with https (yes the https appeared in the url) with GET and the doGet() method of the servlet gets executed which is incorrect since the submit button form is like this, henc the doPost method should be executed rather than the doGet:

<form action="CentralController" method="post">

One mistake from my side may be using the POST rather than GET for authentication but still I feel this should work, I might be missing something and hence it does not work. Please let me know where are the issues and how to resolve it achieve what I am expecting.

EDIT

Servlet definition in web.xml

 <servlet>
  <servlet-name>CentralController</servlet-name>
  <servlet-class>com.controller.CentralController</servlet-class>
  </servlet>
  <servlet-mapping>
  <servlet-name>CentralController</servlet-name>
  <url-pattern>/CentralController</url-pattern>
  </servlet-mapping>

This is the form:

<form action="CentralController" method="post">
    <input type="submit" value="Submit" name="submit">
</form>

Answer 1

On the get/post conversion, if I understand your scenario correctly, you are experiencing a classic HTTP redirection "issue".

When hitting the SSL security constraint with an non-SSL request, the server sends the client a HTTP 302 response, also known as a redirect, to an https URL. The implementation of this redirect is not exactly the same on all client HTTP stacks, but basically most of the time, the redirection is handled by issuing a GET whatever the original HTTP verb was (POST or other).

You can find many discussions about this on wikipedia and its links http://en.wikipedia.org/wiki/HTTP_302 See also Response.Redirect with POST instead of Get? and HTTP: POST request receives a 302, should the redirect-request be a GET? for a discussion. Or generally on google, "HTTP 302 POST".

The sad conclusion is that you can not count on the POST nature of your original request to be preserved when a (HTTP to HTTPS in your case) redirection is sent, it will depend on the browser, and there are many browsers that will issue a GET whatever the redirection status code (302, 307 and the likes).

You might still want to try workarounds as described in the first link above.