2 Replies Latest reply on Aug 16, 2005 10:54 AM by adrian.brock

    Caching of subjects in the security manager

    timfox

      The JBossMQ security manager (org.jboss.mq.security.SecurityManager) currently authenticates via the SubjectSecurityManager, but authorizes (does the realm-mapping) internally via a cached set of roles that it stores after authentication.

      Authentication in JBossMQ is only done at connection create time.

      There's a comment in the code as to why it's been done this way, rather than authorize directly to the RealmMapping.

      public boolean authorize(ConnectionToken token, Set rolePrincipals) throws JMSException
       {
       //Unfortunately we can not reliably use the securityManager and its
       // subject, since can not guarantee that every connection is
       // connected to a unique thread.
       // For now we implement the RealmMapping our self
      


      Looking in the JaasSecurityManager code it seems that it looks up the "active subject" for the thread at authorize, so this comment seems fair enough.

      (One side-effect of caching the roles is that if a long running connection is started by a user with a set of roles, then if the roles are changed or revoked then this wouldn't be picked up until the connection is closed and new connection create is attempted - e.g. if you had a connection listening on 2 topics and you wanted to give rights to access a third topic then the user would have to restart the connection.)

      However, I think we can avoid these problems by both authentication and authorizing for each restricted operation.

      I don't think this should be a performance problem since the authorizations are already cached in the JaasSecurityManager anyway.

      Looking at the EJB security interceptor this seems to be the way it does it too. (authenticate (via cache) and authorize each time)

      Doing it this way for the JMS security interceptor could also simplify the code considerably.

      Does this sound sensible or am I missing something?

        • 1. Re: Caching of subjects in the security manager

          One of the reasons for using the interceptor/aspect stack is to allow the security
          to be configurable/pluggable.

          e.g. rather than requiring a

          createConnection(user, password)

          it could use an interceptor/aspect to pickup the jaas login during the normal
          createConnection()
          just like ejb.

          e.g. I don't see a problem with forcing an authentication on every request (like ejb or web),
          as long as it is the same user on every request over the connection.

          Ideally, the JBoss Messaging security should be a minimal integration with
          a reuse of as much as possible from JBoss Security or the role based aspect
          as the default implementation.

          • 2. Re: Caching of subjects in the security manager

            One of the reasons for doing JBoss Messaging is to move away from JBossMQ's
            "I have to implement everything myself" philosophy and reuse JBoss technology.