Security Cache Flush on Http Session Expiration

[anil.saldhana]

(10:09:25 AM) anil_msn: hello Remy. When the session expires, the session listener basically gets a tomcat session facade (that implements httpsession). I was interested in the principal being stored as a note in catalina session. I doubt we will be able to get to the actual catalina session from the facade
(10:10:31 AM) Remy Maucherat: the facade strictly implements the javax API, and thus does not add any custom call to internal structures; the principal can be accessed through other objects (the request, I think)
(10:11:26 AM) Remy Maucherat: so can you use the request instead ?
(10:11:34 AM) anil_msn: for a regular session.invalidation, we are in a path of request. But when the container expires sessions after an hour or so, there is no request
(10:11:46 AM) anil_msn: we are using the request approach for active sessions getting invalidated
(10:12:20 AM) anil_msn: only the case of container expiring sessions
(10:12:51 AM) anil_msn: I think any approach we take will be like a hack
(10:13:13 AM) anil_msn: better ignore the use case (some customer asked for it)
(10:16:32 AM) Remy Maucherat: hum, right, that's interesting stuff, but it's not going to work
(10:17:16 AM) anil_msn: I was thinking about placing the principal after authentication into the http session. But are u saying that the facade will lose it?
(10:17:25 AM) anil_msn: anyway we are not doing the hack
(10:19:33 AM) Remy Maucherat: no, you can put an object in the session as an attribute
(10:20:10 AM) anil_msn: I cannot justify placing the principal in the session attribute map, just to solve one rare use case.
(10:20:22 AM) anil_msn: we recommend session invalidation anyway as a best practice.
(10:23:05 AM) Remy Maucherat: of course, but most likely they can use a filter or listener to do it
(10:24:53 AM) anil_msn: That is a good suggestion. We can provide an ondemand valve to place the principal on the session (only if the customer wants it) and then update our session listener to also look for this principal
(10:25:14 AM) anil_msn: if the customer is so bent on this use case, he can configure this valve that we will provide
(10:27:22 AM) Remy Maucherat: it would be better to use a filter: his application will always need the attribute to run

We can solve it this way (based on a suggestion from Remy):
a) We will provide a servlet filter in "org.jboss.web.tomcat.security" called as PrincipalSessionAttributeFilter. This filter has one objective - place the principal from request.getUserPrincipal in the session attribute (if not already present) under a key like JBOSS_PRINCIPAL. This filter should be configured by the user on an on-demand basis. We will not enable this filter by default. (If the customer wants this to be applied to all web apps, he can configure this in web.xml of the jboss tomcat service).
b) Update our session binding listener to also look for this JBOSS_PRINCIPAL in the session attribute to flush.

Issue:
When sessions expire on their own, we do not have any principal handy for the session because we do not have any requests coming in (to be able to pick it up from SecurityAssociation). Hence we need a way to pick the principal off of the session maybe. The Tomcat session does retain the principal in its session.

The JIRA issue is:
http://jira.jboss.com/jira/browse/JBAS-4752

[clevelam]

What is the reason for this update. I want my login module's logout method to be called on session expiration. Is this what I need to set or will it be done by default ?

[clevelam]

when i enable the filter for : PrincipalSessionAttributeFilter

I never get forwarded to my actual page and a black screen gets displayed on the browser. Is this correct behavior????

I'm using a spring MVC application.

[anil.saldhana]

Two things:

1) When your user logs out, call session.invalidate() and

2)

<security-domain flushOnSessionInvalidation="true">

in the jboss-web.xml

That should take care of things. Internally a JAAS logout() is called which should call the logout of your custom LM.

[clevelam]

Thanks for the reply Anil.

Should this be the same case for when a user closes the browser and a session-timeout occurs. I will try again, but I am not noticing the LoginModule's logout method being called.

[anil.saldhana]

"clevelam" wrote:
Thanks for the reply Anil.

Should this be the same case for when a user closes the browser and a session-timeout occurs. I will try again, but I am not noticing the LoginModule's logout method being called.

http://anonsvn.jboss.org/repos/jbossas/trunk/tomcat/src/main/org/jboss/web/tomcat/security/SecurityFlushSessionListener.java

Next time do a google search before you press the panic button on the forums. This listener should be enabled by default in the conf/web.xml of the tomcat deployer in your AS.

Have you added some system out messages in your custom LM logout? Is it even being called?

If you have more problems, take it to the user forums. This is design forum. Ok?

Good luck!

[clevelam]

I did do a google. That is how I found this forum. I'm new to jboss forums and did not know this was restricted. If you can point me to a specific google query string that will give me details on how this all works please provide.

I responded to this specific forum because it suggested enabling the PrincipalSessionAttributeFilter servlet filter. when this filter is enabled (jboss 4.2.3) you are no longer directed to the resource you request.
Tell me if I am wrong, but I couldnt understand why that servlet filter doesnt call chain.doFilter(request, response) to go to the next filter or resource.??? I believe the lack of the call is preventing me from viewing my resource.

Additionally, after many queries on google. I could not find anything that directly states that flushing the cache actually calles a JAAS timeout. In my case I actually have the cache turned off. Reason being... when it was turned on and the user tried to do a second login ... without first logging out The cache credentials would automatically approve the login without executing the database commands I have in the login module.

Again, if you can point me to the appropriate forum to continue getting help on this matter. Or a single sight that explains logout on session expiration, that would be more than helpful.

Thanks again and sorry for the confusion.

[clevelam]

Additionally, I enable the listener you pointed me to. No luck. The JAAS logout is not being called. I have Log4J debug statements in my module. Additionally, I have configured my jboss to do debug logging using a category tied to my package structure.