-
1. Re: How to perform security cache eviction
anil.saldhana Nov 8, 2011 10:43 AM (in response to mstruk)1 of 1 people found this helpfulEach cache entry has a time to live. When that expires, it is evicted. Overall the cache itself has a default timeout.
You only care about cache eviction in situations where in the web application has logged the user out but he is not yet evicted in the authenticaiton cache. It is a border condition where in the user password has changed or you need to get newer roles for the user.
-
2. Re: How to perform security cache eviction
mstruk Nov 8, 2011 5:43 PM (in response to anil.saldhana)So, IIUC - in order to be 100%, making sure there is no chance of occasional weird behavior, the cache needs to be flushed only when user changes a password, or his security profile (roles) is edited - logging out isn't really a kind of event that requires flushing the cache?
Are HTTP session TTL and authentication cache TTL two completely unrelated things, or can misalignment of the two impact application behaviour?
For example - if HTTP session times out user is redirected to login page to enter username password, and authentication cache is updated.
But what happens if authentication cache times out - does that automatically invalidate the session so that user is redirected to login page again?
-
3. Re: How to perform security cache eviction
anil.saldhana Nov 8, 2011 5:51 PM (in response to mstruk)1 of 1 people found this helpfulThe authentication cache in question is a cache from PicketBox (JBoss Security). We use the cache so that the login modules are not invoked, for performance purposes. For the authentication cache, it does not know who the calling subsystem is - whether web, ejb, jms etc. All it cares is that it has a cache entry (username,cred,subject). So when PBox does authentication, it checks username/password against the cache entry, if it matches, returns the cached subject. This avoids the login module roundtrip which when successful, inserts/replaces/adds a cache entry.
In the case of web applications, there is a tomcat cache happening at the session level for the user. So unless the session times out or you invalidate the session, the cached principal(which contains username/cred/roles) stays alive even if you close the browser tab.
At the AS level, when the session is invalidated, we try to have hooks in tomcat to call in to evict the PBox cache entry for the principal.
-
4. Re: How to perform security cache eviction
mstruk Nov 9, 2011 9:20 AM (in response to anil.saldhana)I guess having PBox cache TTL smaller than HTTP session TTL isn't an issue then. PBox cache entry timesout but that doesn't affect the web app in any way. But your last statement is the crucial one IMO:
At the AS level, when the session is invalidated, we try to have hooks in tomcat to call in to evict the PBox cache entry for the principal.
If this mechanism works properly, then there is no need for explicit flush-cache in order to make sure that most recent password,roles are used the next time user logs back in. Are there any unit tests for this integration in jboss.as.web?
Actually, another way to achieve the same would be to not use caching at all. I guess PBox is only reached as part of JAAS when web user uses login page for authentication. For this type of usage caching seems redundant. Is there a way to just turn it off?