Session Mangement design

Discussions

EJB design: Session Mangement design

  1. Session Mangement design (8 messages)

    Hi everybody,

    Is there anyway to get my session without using the HttpServletRequest.getSession method ?

    Is it a good design to store a reference to my session in an HashMap so as to be able to get and manage it later using the session ID?

    Thanks,

    Threaded Messages (8)

  2. Session Mangement design[ Go to top ]

    I'm not sure what you are trying to achieve here. If you stored a reference to the session in a HashMap, where would you store it? In the servlet context? How would you know when to dispose of it?

    Sometimes values are copied out of the session and into a Map (or a Map wrapper is put around a session) so that the session can be passed in a more portable fashion. Is this perhaps what you are referring to?

    I'm afraid I'm going to need more details.


    -Tim.
  3. Session Mangement design[ Go to top ]

    I'm not sure what you are trying to achieve here. If you stored a reference to the session in a HashMap, where would you store it? In the servlet context? How would you know when to dispose of it?

    >
    > Sometimes values are copied out of the session and into a Map (or a Map wrapper is put around a session) so that the session can be passed in a more portable fashion. Is this perhaps what you are referring to?
    >
    > I'm afraid I'm going to need more details.
    >
    >
    > -Tim.
    OK, there is my problem.

    I have a portal application with several back-end applications.
    Portal and back-end applications can be load from Internet:
    Http://myportal/... and http://myapp1/...

    The portal is responsable of de Single Sign On. I must be authenticated by the portal server before accessing my back-end server. When I am authenticated, I have a session created in the portal server and in the back-end server.

    When I logoff my portal server, I would like my portal server to send a request to my back-ends server so as to kill my session in the back-end server.

    The first solution, I think of, is to use cookie SSO. Disconecting from the portal application would delete the cookie. This solution seems nice but the SSO cookie can not be sent in secure mode because the portal server don't accept HTTPS. So any hacker could steal the cookie. I think about security problem.

    The second solution is to sore my back-end session in the ServletContext in a HashMap so that my portal server could delete it using HTTPS request.

    The reference would be delte on:

    I would use HttpSessionBindingListener object
  4. Session Mangement design[ Go to top ]

    I'm not sure what you are trying to achieve here. If you stored a reference to the session in a HashMap, where would you store it? In the servlet context? How would you know when to dispose of it?

    > >
    > > Sometimes values are copied out of the session and into a Map (or a Map wrapper is put around a session) so that the session can be passed in a more portable fashion. Is this perhaps what you are referring to?
    > >
    > > I'm afraid I'm going to need more details.
    > >
    > >
    > > -Tim.
    > OK, there is my problem.
    >
    > I have a portal application with several back-end applications.
    > Portal and back-end applications can be load from Internet:
    > Http://myportal/... and http://myapp1/...
    >
    > The portal is responsable of de Single Sign On. I must be authenticated by the portal server before accessing my back-end server. When I am authenticated, I have a session created in the portal server and in the back-end server.
    >
    > When I logoff my portal server, I would like my portal server to send a request to my back-ends server so as to kill my session in the back-end server.
    >
    > The first solution, I think of, is to use cookie SSO. Disconecting from the portal application would delete the cookie. This solution seems nice but the SSO cookie can not be sent in secure mode because the portal server don't accept HTTPS. So any hacker could steal the cookie. I think about security problem.
    >

    The second solution is to sore my back-end session a Singleton using a HashMap so that my portal server could delete it using HTTPS request.

    The reference would be delte on:
      timeout: I would use HttpSessionBindingListener to delete the entry from my HashMap
      logoff from the portal application: the portal application would send a HTTP request to a servlet (controller) who delete the entry from the HahsMap.

    Hope my english is not too bad.

    Thanks again.
  5. Session Mangement design[ Go to top ]

    I'm not sure I fully understand how you want to store the sessions, but it seem like a bad idea on many levels... rather than going into that, though, let's talk about your cookie proposal.

    As you may or may not know, cookies need not be written to disk. Some cookies reside in memory, and only last until you close your browser. Now, you may want a more concrete timeout... such as 30 minutes or whatever. Well, you could encode in the cookie value the expiration time of the cookie, and when you validate the cookie, you'll make sure the cookie has not gone stale. I'd encrypt the cookie, too... just to make sure someone doesn't try to spoof a request.

    Actually, this would be an ideal place to slip in a servlet filter. The servlet filter could intercept all requests. If the request has passed along a valid cookie with the appropriate credentials (whatever that may be, including this timing issue), then it passes through the filter gracefully (sending a new cookie with the response, of course). If no cookie is presented, or the cookie does not match the appropriate credentials, then they are redirected to your SSO login page.

    Hope that helps.

    -Tim.
  6. Session Mangement design[ Go to top ]

    Hi Tim,

    Thanks for your response.

    > I'm not sure I fully understand how you want to store the sessions, but it seem like a bad idea on many levels... rather than going into that, though, let's talk about your cookie proposal.
    >
    I agree with you. I don't really like the second solution because it does not seems to be a good design and may be dangerous as we don't know how the application server manage the session.


    > As you may or may not know, cookies need not be written to disk. Some cookies reside in memory, and only last until you close your browser. Now, you may want a more concrete timeout... such as 30 minutes or whatever. Well, you could encode in the cookie value the expiration time of the cookie, and when you validate the cookie, you'll make sure the cookie has not gone stale. I'd encrypt the cookie, too... just to make sure someone doesn't try to spoof a request.
    >
    I 'm not sure to understand your proposition because encrypting a cookie does not seems to be secure enought.
    The encrypt/decrypt operation is only done in the server side. So, if no one can read the encrypted cookie, anybody who manage to sniff and steal the cookie can use it and spoof a request. The only way I know to avoid this is to send the cookie in secure mode but this suppose that every server who want to recieve the cookie must be in HTTPS. This is not my case.

    Do I misunderstand something ?

    > Actually, this would be an ideal place to slip in a servlet filter. The servlet filter could intercept all requests. If the request has passed along a valid cookie with the appropriate credentials (whatever that may be, including this timing issue), then it passes through the filter gracefully (sending a new cookie with the response, of course). If no cookie is presented, or the cookie does not match the appropriate credentials, then they are redirected to your SSO login page.
    >
    > Hope that helps.
    >
    > -Tim.

    Thierry
  7. Session Mangement design[ Go to top ]

    I 'm not sure to understand your proposition because encrypting a cookie

    > does not seems to be secure enought.
    > The encrypt/decrypt operation is only done in the server side. So, if no one
    > can read the encrypted cookie, anybody who manage to sniff and steal the
    > cookie can use it and spoof a request. The only way I know to avoid this is
    > to send the cookie in secure mode but this suppose that every server who
    > want to recieve the cookie must be in HTTPS. This is not my case.
    >
    > Do I misunderstand something ?

    Nope, you're absolutely right. I wasn't thinking of someone actually packet sniffing the request...

    I'm not sure you *can* prevent that, given your restrictions. At least, I don't see how using the HttpSession of the application server would be any more secure. If you send a cookie (or encoded URL) with a valid session ID, its not gonna care whether that's *really* your session or not.

    Let me know what you come up with. I'm very curious.

    -Tim.
  8. Session Mangement design[ Go to top ]

    I don't know of any way to get the session other than request.getSession().

    Storing data in a HashMap in the session might be useful, but I take a different approach. I put a single custom object (the Registry) in the session, and store data in it using type-safe methods. For example:

    public class Registry {
      private User user;

      public void setUser(User user) {
        this.user = user;
      }

      public User getUser() {
        return this.user;
      }

      // More data, getters and setters
    }

    This way I don't need to worry about name collisions in the session, because I only have one object, and ClassCastExceptions largely go away.

    The only downside to this approach is in clustered applications. Most J2EE servers the Session.setAttribute() method as a mechanism for tracking when session data needs to be replicated across the cluster. I mostly deal with small, non-clustered apps, so this is a non-issue for me.
  9. Session Mangement design[ Go to top ]

    Oops! I just realized I forgot something important:

    public class Registry implements java.io.Serializable ...