I ran into this issue about 2 years ago and posted the same question.
Had an application which had 3 different types of users:
One group should be authenticated using https only to protect password, then switch to http, but sometimes switch back to https again.
Other group should be authenticated over https and stay secure (to prevent possibility of hijacking)
Last group should only connect over http, no switching.
In the end I had to do code around it by doing session-migration. Basically, a simple container where the httpsession attributes were saved in a "migrating session object".
Resources was configured as "secure" and "unsecure" and if the current connection did not match the requested resources' security level, the session would "migrate".
The sequence was something like this:
Httpsessions attributed was saved, a one time unique key was assigned, session was invalidated, user was redirected to opposite protocol with unique key as request parameter. New HttpSession created, session attributes restored, "migrating session object" destroyed. forwarded to original requested resource.
This could work both ways (http to https) but there is no reason since tomcat keeps non-secure cookies in secure domain. And this migration only has to be done once, since the cookie is valid in both domains from now on. It did create a tiny bit of overhead, but with an app. where users log in once and stay connected for long periods of time this turned out to be insignificant.
Not the best solution, but with deadline looming it did the job.
Later, when switching with Struts, this ported nicely(if you can call it that) by extending sslext.
In the end I wish this was covered by the servlet spec. Does anybody know how other containers behave(Jetty, Resin, etc)?
-Henrik Bentel
"Adam Hardy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 11/17/2003 05:15 PM Andrew Mottaz wrote: > >>Also, as far as I can see, the java community has decided that once you > >>start a secure session, you should stay in a secure session, for various > >>security reasons. Are you doing a secure login and then redirecting back > >>to http afterwards? > > > > Imagine the following scenario -- A web site has different levels of user > > access. The difference between the users is what products they can see. > > The data is not terribly sensitive. However, the log-in should be secure > > for several reasons -- 1) For the users perception -- people do not like the > > "This form is not secure" message when logging in. 2) Capturing a user id > > and password is worse than hijacking one session. > > > [snipped] > > Also -- this is the standard for Tomcat -- not Java --( it may be in the > > servlet/jsp spec -- but if so, it is a new addition). Other Java based app > > servers treat this differently. > > > [snipped] > > Again -- Just my 2 cents -- Is there a security issue I'm missing? If the > > argument is that you should NEVER go from secure to non-secure, the Tomcat > > solution does not assure that. It only means that you have to go non-secure, > > secure, and then non-secure. That seems quite arbitrary to me. > > I'm not sure I would put the argument in those terms - obviously you can > go from secure to non-secure via redirects, but tomcat is not going to > be nice about it, i.e. wave your cookies goodbye. > > There is new stuff in the spec related to secure sessions, but I'm not > sure if it involves cookies. The issue is about encrypting the > form-based CMS login form and in bugzilla it didn't get much sympathy: > > http://issues.apache.org/bugzilla/show_bug.cgi?id=23970 > > I assume the issue was discussed in depth but I couldn't find it on the > tomcat-dev list. Perhaps it was discussed by JCP somewhere else while > writing the spec. If anyone who is on the dev list knows, I'd love to > read the discussion.
You'll have to go back at least two years to get the tomcat-dev discussion ;-). At the moment, the Tomcat-Developer's don't believe that there is anything to discuss :). Also, the Servert-2.4 spec has already gone 'final' (not that I get a chance to see it :(), so all you can do now is to lobby for the whenever Servlet-2.5 Spec. > > The spec is about to go final after which any change of the issue is > doomed, unfortunately IMHO. I'd gladly lend my voice to any last-ditch > attempt to get it changed. > > > Adam > -- > struts 1.1 + tomcat 5.0.12 + java 1.4.2 > Linux 2.4.20 RH9
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
