2 Replies Latest reply on Aug 24, 2006 5:25 AM by poetry

    session timeout does not invalidate the SSO

    mtolbert

      I am using JBoss SSO on an application that consists of multiple WAR's and the application needs to track when a users session (SSO) is created and destroyed. I have implemented an HttpListener and defined it in web.xml. Unfortunately, when one webapp (WAR) session invalidates/times out it doesn't necessarily mean that all sessions in all webapps have been invalidated for that user. Therefore, this approach doesn't accomplish what I need, which is track when a users SSO gets created and destroyed.

      It would be nice if there was some sort of SSOListener that could be implemented. This SSOListener might be invoked when the SSO is created and destroyed, and have methods like ssoCreated() and ssoDestroyed().

      Is there a hook to tell when a SSO gets created and destroyed?

      FYI- This is my SSO configuration for JBoss

      -- server.xml --
      turned on valve: org.apache.catalina.authenticator.SingleSignOn

      -- jboss-service.xml --
      Disabled SSO caching by setting DefaultCacheTimeout and DefaultCacheResolution to 0.


      Any assistance would be appreciated.
      -Mike

        • 1. Re: session timeout does not invalidate the SSO
          brian.stansberry

          The SingleSignOn valve doesn't have any simple hooks for tracking this. There may be a couple of hackish ways to get what you want:

          1) Subclass SingleSignOn and override register() and deregister() to add the notifications you want (haven't looked closely; there may be other methods you need to monitor as well.)

          2) Use ClusteredSingleSignOn, get hold of the JBoss Cache instance it's using, implement TreeCacheListener and monitor the SSO portion of the cache for node additions and removals. (Yuck)

          • 2. Re: session timeout does not invalidate the SSO
            poetry

            Hello!

            I`m working on a project with similar setup and ran into a problem with session timeouts.
            My question is: Is it wanted that not all PortletSessions time out, when the
            portal session is timed out?
            Where can I find information how sessions states are handled in JBoss Portal?

            "mtolbert" wrote:
            I am using JBoss SSO on an application that consists of multiple WAR's and the application needs to track when a users session (SSO) is created and destroyed. I have implemented an HttpListener and defined it in web.xml. Unfortunately, when one webapp (WAR) session invalidates/times out it doesn't necessarily mean that all sessions in all webapps have been invalidated for that user. Therefore, this approach doesn't accomplish what I need, which is track when a users SSO gets created and destroyed.
            ...
            -Mike


            In my case it looks like not all portlets have thier session invalidated, when a timeout occurs.
            It may depend on the war that the portlets lie in.
            What actually happens is that the FacesContext (we use myfaces 1.1.4)
            still refrences backing beans with session scope.
            When a user session runs into a timeout, and another user logs in
            with the same browser (ie with the same cookie containing the same session id),
            the session id will be reused and the user will see the data of the timed out session
            if he navigates to the same VIEW!

            We use JBoss 4.0.4.CR2, myfaces 1.1.4, jboss-portal-2.2.1, jaas, spring, hibernate.
            Error occurs locally on Win 2000 and on Solaris 2.8 as well.
            We have the same session timeouts configured in the web.xml's
            of jbossweb-tomcat55.sar and jboss-portal.sar/jboss-server.war .
            We don`t use clustering.

            I do have a workaround actually, but I do not know if the is way to do it (?):
            I override MyFacesGenericPortlet.facesRender and check for a timed out PortletSession myself.
            If timed out, I just call invalidate on the session.
            I could also try to find a workaround with the session id not being reused.
            But I`d rather understand what`s going on!

            Arnulf