2 Replies Latest reply on Jun 26, 2012 12:02 AM by robmv

    JBossCachedAuthenticationManager caching and JAAS modules returning different Principal

    robmv

      I have been trying to run two applications with EJB remoting on JBoss 7.1.x. My main problem is that currently JBoss only allows one authentication method by remoting port (one realm per port) and the EJB3 subsystem only allows one remoting port. To overcome this limitation, after a few chats on IRC, I decided to implement a realm plugin to do the remoting authentication, overriding the concept of the remote client user name to contain the application name (application name + real user name).

       

      I managed to make this work, with a subclass of RemotingLoginModule I remove the application name in order to not expose the application name when EJBs call ctx.getCallerPrincipal().getName() (changing the CallerPrincipal to be my new principal and not the one from the remoting subsystem)

       

      Now about picketbox, JBossCachedAuthenticationManager caches the authentication information using as a key the CallerPrincipal that the JAAS module returns, but uses another principal that exists before the authentication to check if the cache is valid. The problem is that when the JAAS module returns a different principal, the cache always misses. let me explain with a little pseudo code

       

      --- 1st call

       

      cached = domainCache.get(<Principal app + userName>)

      if (cached == null) {

           authenticate();

           info.callerPrincipal = <Principal userName>;

           domainCache.put(info.callerPrincipal, info);

      }

       

      --- 2nd call

       

      cached = domainCache.get(<Principal app + userName>)

      ... cache misses ... cached is null

       

      The domainCache keys are the caller principal from the JAAS module, but when checking if the cache contains an entry, it uses the original principal. There is an assumption that the caller principal is the same or equals to the original principal, and I think that is wrong. I patched it in order to test my hipotessis so it stores as key the original principal, disabling tests because it fails because it is testing that the caller principal is what is stored, and this way caching works.

       

      I know my test patch is not the right solution, because it break JBossCachedAuthenticationManager API (containsKey, getCachedKeys, flushCache...), Am I right this is a problem or is there a better way to do this?

       

      The patch is simple, instead of calling

       

           domainCache.put(info.callerPrincipal, info);

       

      use

       

           domainCache.put(principal, info);

       

      Message was edited by: Robert Marcano, small pseudo code fix