Application Server 3  4  5 and 6
  1. Application Server 3 4 5 and 6
  2. JBAS-6449

InvokerAdaptorService overwrites existing SecurityContext and clears it after invocation

    Details

    • Similar Issues:
      Show 10 results 

      Description

      The InvokerAdaptorService always creates a new SecurityContext even if there is already one created by components called earlier in invocation stack. After invoking the desired MBean method the SecurityContext will be cleared with a call to: SecurityActions.clearSecurityContext();
      This leads to several problems:
      In our project we have a secured EJB (annotated with @SecurityDomain) which is calling an MBean Service and a local (secured) EJB. After the invocation of the mbean there is no security context anymore which leads to an IllegalStateException "Security Context has not been set" thrown by RoleBasedAuthorizationInterceptorv2) when we try to call the local EJB.
      Following steps are possible to fix the problem:
      1. call to SecurityActions.getSecurityContext();
      2. if there is currently no SecurityContext create a new one and set it.
      3. if there already is a SecurityContext set, do nothing.
      4. call the mbean method.
      5. only if we created the SecurityContext, we should clear it with SecurityActions.clearSecurityContext(), otherwise, do nothing.

        Issue Links

          Activity

          Hide
          Richard Kennard
          added a comment -

          Confirming this bug still in 5.1.0.GA. It's very bad, as it makes it next to impossible to, say, check the depth of a queue...

          RMIAdaptor server = (RMIAdaptor) new InitialContext().lookup( EjbUtils.lookupEnv( "core/jmx-connection" ) );
          ObjectName objectName = new ObjectName( "jboss.messaging.destination:service=Queue,name=" + queue );
          int queueDepth = 0;(Integer) server.getAttribute( objectName, "MessageCount" );

          ...this code works, but subsequent calls to EJBs all fail because the last line (server.getAttribute) clears the security context.

          Is there a workaround?

          Show
          Richard Kennard
          added a comment - Confirming this bug still in 5.1.0.GA. It's very bad, as it makes it next to impossible to, say, check the depth of a queue... RMIAdaptor server = (RMIAdaptor) new InitialContext().lookup( EjbUtils.lookupEnv( "core/jmx-connection" ) ); ObjectName objectName = new ObjectName( "jboss.messaging.destination:service=Queue,name=" + queue ); int queueDepth = 0;(Integer) server.getAttribute( objectName, "MessageCount" ); ...this code works, but subsequent calls to EJBs all fail because the last line (server.getAttribute) clears the security context. Is there a workaround?
          Hide
          Richard Kennard
          added a comment -

          I should further mention this problem was not present in JBoss 4.2.3.GA. The above code worked without problem (albeit using 'jboss.mq.destination.service' and 'QueueDepth')

          Show
          Richard Kennard
          added a comment - I should further mention this problem was not present in JBoss 4.2.3.GA. The above code worked without problem (albeit using 'jboss.mq.destination.service' and 'QueueDepth')
          Hide
          Anil Saldhana
          added a comment -

          Please replace the attached jboss-jmx-adaptor-plugin.jar in your JBAS instance.

          Show
          Anil Saldhana
          added a comment - Please replace the attached jboss-jmx-adaptor-plugin.jar in your JBAS instance.
          Hide
          Anil Saldhana
          added a comment -

          This has been fixed for JBAS 5.2 For earlier versions, please replace the attached jar in your JBAS instance.

          Show
          Anil Saldhana
          added a comment - This has been fixed for JBAS 5.2 For earlier versions, please replace the attached jar in your JBAS instance.

            People

            • Assignee:
              Anil Saldhana
              Reporter:
              Michael Gronau
            • Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: