Is there any way to share a httpsession between the confidential and the non confidential parts of a web-app, without resorting to url rewriting ?
The question relates to the fact that whenever I do sendRedirect to an http servlet from inside an https servlet (one having a url with the CONFIDENTIAL transport-guarantee) , any session that I created inside the https servlet is not propagated, since the browser does not send any jsessionid generated by the https servlet (with request.getSession) to the http servlet in the same app, either due to the fact that the cookie is set with the Secure attribute in the first place or due to the http and https running in different ports not being recognized as the same app by the browser, or both.
More generically, what is the standard way to make a user access non-confidential content only as a securely (confidentialy) authenticated user ?
Joined: Mar 18, 2010
Just to share, the solution i came up with was to manage my own authentication information in a hashmap stored as a servlet context attribute.
1. https servlet trigers the container login prompt,
2. login ok => https servlet creates a UUID and stores it in that hashmap as the key to an UserInfo instance containing : the username (getUserPrincipal), role (isUserInRole(...)) and the uuid itself.
3. https redirects to http frontcontroller, having the uuid attached as parameter.
4. http frontcontroller reads the uuid parameter, retrieves the respective Userinfo from the global hashmap (stored in servletcontext) and if it finds it, creates a new session (request.getSession()) and stores this Userinfo as an attribute "uuid" of that session, to enable programatic authorization further on.
5. front controller forwards to pages inside WEB-INF, hence not directly accessible by the client.
the lifecycle of the userinfo in the hashmap is connected with that of the http session because I created a HttpSessionListener that overrides the sessionDestroyed method to remove the entry in the hashmap having the same uuid stored in the session to destroy.
there is also a ServletContextListener to create the UserInfo hashmap and insert it as an attribute of the servlet context.
So, that was my first solution. Anyway, I ended up concluding that the info I was planning to provide via http, is actually sensitive enough to justify the ssl overhead... :)