Announcement Announcement Module
Collapse
No announcement yet.
Custom HttpSession implementations Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Custom HttpSession implementations

    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!

  • #2
    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).

    Comment


    • #3
      Originally posted by 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).
      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

      Comment


      • #4
        Originally posted by maward
        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.

        Comment


        • #5
          Originally posted by Ben Alex
          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.

          Comment


          • #6
            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 ?

            Comment


            • #7
              Originally posted by 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 ?
              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.

              Comment


              • #8
                [quote="maward"]
                Originally posted by croco
                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.

                Comment


                • #9
                  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?

                  Comment


                  • #10
                    Originally posted by rob_from_ca
                    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.

                    Comment


                    • #11
                      ... 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 think that replication of the HTTP session actually brings you failover capabilities. As you said, for scalability, the session replicatication adds a drawback in performance (smaller for memory based replication, greater for DB based replication). If you are woried that some sensitive info might be lost in case of web server failure you should probably save it in the database anyway.
                      If you want just scalability you should use sticky HTTP sessions where all requets in a session are served by just one server instance. In this case, maintainng some state on the HTTP session it might actually help from a performance point of view, because avoids web server - (ejb server (- db server)) roundtrips.

                      Comment


                      • #12
                        Originally posted by croco
                        In this case, maintainng some state on the HTTP session it might actually help from a performance point of view, because avoids web server - (ejb server (- db server)) roundtrips.
                        I guess you are saying that if, for example, a user is working their way through a six page wizard, then by storing the information being populated by the wizard in the web tier you will not need to keep going back to the middleware server for each wizard page. That's an interesting point. I think I am now convinced that if we can use Tomcat-based sessions in conjunction with our middleware security then life would be much easier and would give a boost in certain areas such as automatic URL rewriting and Spring wizard usage.

                        Thanks for all your contributions!
                        Matt

                        Comment


                        • #13
                          Hi,

                          I know this is an old thread, but I looking for a solution to a very similar problem and I've just found this. I've been looking for this kind of issue for ages but I've never find anyone asking something like this.

                          I'm starting to use Spring 2.5 in a new project, and now prepared to full coding after a hard, fast, fulltime and self-taughting course (reading a lot of documentation about spring, and testing some example stuff).

                          I was really happy when I saw the title of this thread, because I thought that Spring even bring me a solution to that, but I've seen it doesn't

                          The problem:
                          My applications are full based in HTTPSession, just because it's easy to base the conversation state, authorization info, etc in HTTPSession. And also about additional Session support in Web Servers, like session replication, persistence session, in files, databases, session expiration, etc.

                          But this is my real problem: HTTPSession is based either in a well defined cookie, like JSessionID or in URL codification of the same ID.

                          And?

                          My clients ask me for a simple HTTP API (similar to REST APIs). But there is a very strict requirement: not to use neither cookies nor url coding. They don't use Web Browser clients.

                          And I have to authenticate users, then I reply with an auth-token in an XML response. And they have to send me this auth-token as a well defined HTTP Param or HTTP Header. Yes, I know, this is like an invented cookie mechanism.

                          But they don't want another thing.

                          Now, I'd like not to change anything in my application, just using a filter that check for this token and associate it with the HTTPSession mechanism.

                          But.... Is it impossible to do it?. Remember that HTTPSesion is a full mechanism that I don't want to reinvent, like session expiration based in web.xml time configuration, etc...

                          I think the only solution it is to use internal Web Application Server library and override parts of its HTTPSession implementation, or to implement my own HTTPSession and then doing all that HTTPSession does.

                          But I'm surprised not to find any with a similar issue. Is it a too weird requirement? Am I looking for a very weird solution? Is it the solution so simple than I don't see it? Am I too silly?

                          Thanks
                          Pedro

                          Comment

                          Working...
                          X