My opinion is that it's a feature. If you don't like it, you should cause the creation of a session before authentication. Will leave it open for further comments before closing, though.

Hello Remy,

as far as I understand, session fixation prevention is there to change the session ID when a session becomes authenticated. That's good.

But without a session to begin with, then being authenticated right away, why change the session ID on the next response? There is no need for this - what does this protect against? This is appears unneccessary.

Furthermore, turning principal caching off (cache=false and changeSessionIdOnAuthentication=true) causes ANY response to set a new session ID cookie. Is that really intended?

Thanks,
Jan

If you don't cache authentication occurs on every request.

I see. I need to run this by my colleagues, hope it is okay to keep open until tomorrow.

I would argue that in the case where authentication and session creation occur in the same request it would not be right to change the session ID on the second request (where no authentication occurs).

So, we discussed this and still think that in the particular scenario described (authentication and session creation in the same request), a subsequent request should not get a new session ID, as authentication already happened in the previous request. Maybe a "second opinion" can be collected.

Your example does not show it; are you using cache="false" in your basic authenticator valve? You'd have to go through some hoops to effect that change.

I am using org.apache.catalina.authenticator.BasicAuthenticator directly with default settings (cache="true" and changeSessionIdOnAuthentication="true").

com.example.SessionBehaviorIT.testDemonstrateProtectedServlet() shows the issue.

Running "mvn verify" is enough. You could also start Tomcat via "mvn tomcat7:run" and then execute testDemonstrateProtectedServlet() in some IDE.

https://github.com/smurf667/test-tomcat-session/blob/master/src/test/java/com/example/SessionBehaviorIT.java#L52-L55

https://github.com/smurf667/test-tomcat-session/blob/master/src/test/tomcat7/server.xml#L23-L24


I have understood that cache="false" will cause each request to get a new session ID cookie, this case can be safely ignored.

It is worth keeping in mind the change in session ID is relatively cheap. The session object remains the same, it is just the ID field that is updated.

Using alwaysUseSession="true" on the Authenticator appears, on the face of it, to be a simple solution to this problem.

I haven't tried coding it, but it looks like a fix triggered by session creation would be possible. It would require some refactoring of AuthenticatorBase.register to avoid duplication of code.

Overall, I do wonder if the additional complexity of the session creation triggered fix is truly necessary.

Hi Mark,

I can confirm that alwaysUseSession="true" does make all tests of the test project pass. In our real life setup we do have a custom authenticator and can implement the workaround as described.

I leave it up to you guys to decide if you change anything. As I said, I find the current behviour "unexpected" and think that if it did not happen like that there would be less confusion with other parties in the future.

Thanks, and kind regards,
Jan

I think, given the options available, I am going to resolve this as WONTFIX.

If a use case was presented where alwaysUseSession="true" could not be used then that might justify the additional complexity required to handle session creation after authentication but, at the moment, such a use case seems pretty unlikely.