Custom HttpSession implementations

[maward]

Is it possible to use your own HttpSession implementation with Spring and Tomcat?

I would really like to use some features of Spring that require the use of HttpSession - but on my project we have a strict policy of no state being held in the web-tier. All authentication and user-related services (eg. allowing a user to update their contact details) are performed through middleware. Each time a request is made to the web-tier, an authentication token is extracted (currently with cookies) and the middleware validates the user and is also used to perform any other business logic for the request.

My questions are:

* Can I create an HttpSession implementation and have Spring/Tomcat use this instead of Tomcat's usual mechanism?

* Would Tomcat then use this with its URL-rewriting mechanism?

* Is there a way to do all this with spring that I have missed? I am not aware of any authentication mechanisms being built in to Spring and have not seen any way of plugging in a new session mechanism.

Thanks for any help in advance!

[Ben Alex]

See http://acegisecurity.sourceforge.net for Spring-specific security.

My first instinct is needing to use a middle tier for what is normally performed by HttpSession is probably not going to scale particularly well. It's usually useful to store steps of a web workflow in HttpSession and only pass to the services layer for an atomic unit of work or use case (eg create new order).

[maward]

See http://acegisecurity.sourceforge.net for Spring-specific security.

My first instinct is needing to use a middle tier for what is normally performed by HttpSession is probably not going to scale particularly well. It's usually useful to store steps of a web workflow in HttpSession and only pass to the services layer for an atomic unit of work or use case (eg create new order).

That's interesting and helpful. I agree that hitting the database is going to be a much heavier operation than storing POJOs in the front-end webtier. However I can't help but be nervous of storing insecured information in the webtier - the middleware provides secure access to all data. If the Spring wizards were to store information such as a 'new order' object, that would allow for potential security holes to be abused more easily - a user wouldn't have to be logged on necessarily to trick the web server into giving out those details stored in the new order object.

However, I would dearly like to use Spring's wizards - I tried one out yesterday as an experiment and it was simplicity itself. In the real application, I have had to jump through hoops passing around great numbers of parameters between pages to mimick this functionality whilst avoiding storage of state in the webtier.

I am having a look at ACEGI (I was unaware of its existence until now) to see what it does and if it could be useful to us. But I suspect it too uses standard HttpSessions for storing auth-tokens etc. Is that right?

Thanks again for your help
Matt

[Ben Alex]

However I can't help but be nervous of storing insecured information in the webtier - the middleware provides secure access to all data. If the Spring wizards were to store information such as a 'new order' object, that would allow for potential security holes to be abused more easily - a user wouldn't have to be logged on necessarily to trick the web server into giving out those details stored in the new order object.

Matt, I'm not sure this this concern will be played out in reality. Let's take "new order" for example. If your new order is initially being created, it really has no business value. Only when it is saved in the middle tier does it become valuable. Something like Acegi Security can then happily restrict the web tier (or any other object that calls the services layer) from retrieving that order again unless suitable permissions are held.

Acegi Security uses a ContextHolder, which is a ThreadLocal object, for storing the user identity. This makes an Authentication object available at any time code is executing, to any interested object, without needing to pass the Authentication object around in method arguments. Acegi Security uses pluggable strategies for storing the Authentication between web requests. Whilst HttpSessionIntegrationFilter is most commonly used, you could write your own alternative implementation. If using BASIC authentication you can even switch that off, as every web request is re-authenticated.

Despite the discussion about ContextHolder and HttpSessionIntegrationFilter, if you don't trust your web server is secure you really have a major problem. It's not insurmountable, but writing an enterprise application with an expectation the web server is hostile means hardening the services layer to a very significant extent. It's certainly achievable, but very unusual for this to be a real requirement.

Why not download Acegi Security and try the Contacts Sample application? It's built with Spring MVC and demonstrates the mainsteam way to build secure applications with Spring + Acegi Security. I think you'll find the patterns it employs meets your needs.

[maward]

Why not download Acegi Security and try the Contacts Sample application? It's built with Spring MVC and demonstrates the mainsteam way to build secure applications with Spring + Acegi Security. I think you'll find the patterns it employs meets your needs.

I will indeed! However, as we have already developed our middleware security I may need something that fits in with that rather than a new solution. Can anyone tell me if it is possible to tell Tomcat to use a custom implementation of HttpSession? I can't find any suggestion of this anywhere. Right, time to download your framework. Thanks again for your time.

[croco]

I don't quite understand what wories you about the webtier being insecure. Could you detail a little?

a user wouldn't have to be logged on necessarily to trick the web server into giving out those details stored in the new order object.

A user's order object would be held in the http session of that user. How could another user trick the web server so that it can access info from another server ?

[maward]

I don't quite understand what wories you about the webtier being insecure. Could you detail a little?

a user wouldn't have to be logged on necessarily to trick the web server into giving out those details stored in the new order object.

A user's order object would be held in the http session of that user. How could another user trick the web server so that it can access info from another server ?

For example, imagine if there was a security hole in the Tomcat Manager application that made it possible to install a new web application that could sniff out session information and send it back to a particular email address. Any credit card details or name and address information being held in a 'payment wizard' would have been hijacked.

[Ben Alex]

[quote="maward"]

For example, imagine if there was a security hole in the Tomcat Manager application that made it possible to install a new web application that could sniff out session information and send it back to a particular email address. Any credit card details or name and address information being held in a 'payment wizard' would have been hijacked.

If something so fundamentally insecure happened, you'd have such profound security problems sending an order would be the least of your problems.

A system is only secure as its weakest link. If your web server is a weak link, you need to define your "system" so it doesn't include a web server.

[rob_from_ca]

imagine if there was a security hole in the Tomcat Manager application that made it possible to install a new web application that could sniff out session information and send it back to a particular email address. Any credit card details or name and address information being held in a 'payment wizard' would have been hijacked.

In the same hypothetical instance couldn't the attacker also just install a filter that would save the post parameters and responses (as well as the middleware session ID for possible misuse) that capture those as well?

On the surface, it doesn't seem possible to me to secure something when you're assuming an active man-in-the-middle on an unsecure protocol...

As for your question, I've had it pointed out to me in the past that even if it's possible, it might not be the best solution. I don't think there's a real guarantee from the Servlet API that there's any particular object you'll get as a session, or even that it will be the same type of object from request to request. There may or may not be hooks to support some app server functionality in the session object, without with things wouldn't work right. With Tomcat you could look at the source and figure it out, but all of those details would be implementation dependent and could change from release to release.

I would try at all costs to find a more "normal" way of doing what you're looking for. What about a filter that takes what you need from the cookie and puts the necessary objects into the request object?

[maward]

In the same hypothetical instance couldn't the attacker also just install a filter that would save the post parameters and responses (as well as the middleware session ID for possible misuse) that capture those as well?

That is true. I did neglect to mention that security is only one issue - another reason is that by having no state in the web tier, it will scale horizontally with no bottlenecks, whereas I believe you would loose some of the possible gains of scaling that way if you have clustered session information. I will however try to clarify whether the penalties would be significant - afterall, there's no point in jumping through hoops to work around a problem if it is an acceptable performance hit.