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)
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?
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.
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!