I recently upgraded from JBoss 5.1.0 to 5.2.0. I noticed that JBossSX is utilized for the initial login for a given user/password. If the same user logs in again (with the same password), JBossSX is bypassed. If a different user logs in, or if the same user logs in again with a different password, JBossSX is utilized.
So, if j_username and j_password are the same as a previous login, JBossSX is bypassed. If j_role is different, JBossSX is not bypassed. (I assume this is because j_role is not a standard security/login parameter.) If either j_username or j_password change, JBossSX is utilized. (When I say that JBossSX is "utilized", I mean that I get hits on breakpoints that I have peppered throughout my JBossSX implementation.)
In login-config.xml, I am using an application-policy with a custom login-module (AbstractServerLoginModule implementation). In this application-policy, two module-options are defined:
1.) debug: false
2.) serverLogin.url: the URL of my authentication action
It almost seems as if JBoss is caching the authenticated session or implementing a sneaky (and in my case undesired) single sign on. I'm wondering if there's a new setting in JBoss 5.2.0 which enables this caching/SSO type behavior.
Closing the browser between logins does not change the behavior.
(If you're wondering why this is a problem, it is because I need the application to take into consideration which role was selected at login. This role is set in my identity (i.e., UserPrincipal) and is used throughout my application. When I get the HttpServletRequest from ServletActionContext, and I get the UserPrincipal from that request, it is the UserPrincipal from the initial login, and thus the old/incorrect role.)
The fix to this was to set the default cache timeout to 0 in jboss-service.xml:
<mbean code="org.jboss.security.plugins.JaasSecurityManagerService" name = "jboss.security:service=JaasSecurityManager">
<!-- Other attributes were omitted from my list here....-->