[This worked nicely on 3.0.4 but my solution seems broken on 3.2.6]
I have a WebApp which calls on some EJBs. The WebApp and EJBs are configured to use the same security-domain.
When the EJB code revokes a user's role it then (subsequently, within the same method) calls flushAuthenticationCache on the JAAS Security Manager. All fine and dandy.
In 3.0.4 the Web App would immediately refuse any further access to restricted resources, redirecting the user to the login page.
In 3.2.6 the WebApp fails to detect that the principal has lost the role - it continues to serve pages which the user no longer has rights to access. The user can't actually achieve anything because the EJBs do correctly deny access but the failure mode is ugly with security exceptions down at the EJB level propogating up stack traces.
Does the WebApp have some sort of secondary cache? Or is it making authorisation decisions based on session perhaps? Or have I missed out a newly-necessary WebApp configuration element perhaps?
tomcat in 3.2.6 caches the auth info based on the session so the session must be invalidated as well.