1. Do not know. Look in the source.
But what prevents you to subclass JaasSecurityManager
and add some method to expire cache?
It's an mlet...
2. No, security ocntext is not lost. Cache is there to prevent unnecessary calls to your login modules.
Principal and credential are usually stored on client side and passed with every invocation -> so flushing cache would yeld a lot of calls to your login modules
( but as far credentials/principals are still valid,
no client would notice )
I did some digging and found the answers. If you have the same questions, here is my finding:
> I've some questions about JaasSecurityManager's cache
> 1. Is it possible to setup JaasSecurityManager's
> cache policy so that it will update cache based on
> time interval, or some other cues like JMS messages?
> If so, how?
JaasSecurityManager accepts an attribute that gives the JNDI name of a cache policy. That's how you can setup a custom cache policy. However, the attribute is a JNDI name that is used to look up the actual CachePolicy instance. How do you set it up? You'll have to create a MBean and initialize it in jboss.jcml.
> 2. What exactly happen when the cache is flushed?
> Are the existing logged-in users' security context
> lost? Do users have to re-login or
> JaasSecurityManager is smart enough to tell the
> cached domain info is missing and it goes update it
My experience is that flushing the cache actually removes current DomainInfo's. So any logged in session from web clients will lose its security context and web clients cannot perform the next secured operation. I found out also that, JBoss update its security cache every time a user logs in. In other words, if user's roles are changed, a user will get his new set of roles next time when he logs in again.