1 Reply Latest reply on Apr 24, 2015 1:23 PM by drakemj

    In 5.2.0, JBossSX bypassed for subsequent logins


      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.


      Login form:

      - j_username

      - j_password

      - j_role


      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.)

        • 1. Re: In 5.2.0, JBossSX bypassed for subsequent logins

          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....-->

               <attribute name="DefaultCacheTimeout">0</attribute>