4 Replies Latest reply on Nov 9, 2011 9:20 AM by Marko Strukelj

    How to perform security cache eviction

    Marko Strukelj Master

      On JBoss AS6 security cache eviction is performed via JMX:

       

      {code}

      MBeanServer server = ...;

      String jaasMgrName = "jboss.security:service=JaasSecurityManager";

      ObjectName jaasMgr = new ObjectName(jaasMgrName);

      Object[] params = {domainName};

      String[] signature = {"java.lang.String"};

      server.invoke(jaasMgr, "flushAuthenticationCache", params, signature);

      {code}

       

       

      The question is - is triggering cache eviction still required or does cache eviction happen automatically?

       

      One scenario is session timeout, another is explicit logout ...

       

       

      I found an analog security subsystem operation:

      https://github.com/jbossas/jboss-as/blob/master/security/src/main/java/org/jboss/as/security/SecurityDomainOperations.java

       

      I guess the way to go is to invoke a management operation:

       

      /subsystem=security/security-domain=mycustomsecuritydomain:flush-cache(principal=someusername)

       

      BTW: Trying that using jboss-admin CLI produces the following error:

       

      Operation 'flush-cache' does not expect any property.

       

      Try for example: /subsystem=security/security-domain=other:flush-cache(principal=guest)

       

      Dropping the brackets works, but flushes all credentials - not exactly what I want.

       

      Or maybe an even better approach is to just directly use SecurityDomainService.SERVICE_NAME.append(securityDomain) ?

        • 1. Re: How to perform security cache eviction
          Anil Saldanha Master

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

          1 of 1 people found this helpful
          • 2. Re: How to perform security cache eviction
            Marko Strukelj Master

            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 Saldanha Master

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

              1 of 1 people found this helpful
              • 4. Re: How to perform security cache eviction
                Marko Strukelj Master

                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?