Uploaded image for project: 'HornetQ'
  1. HornetQ
  2. HORNETQ-340

Sending a Message Clears The SecurityContext

    Details

    • Type: Quality Risk
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Done
    • Affects Version/s: 2.0.0.GA
    • Fix Version/s: 2.1.0.CR1
    • Component/s: None
    • Environment:

      Found on Windows XP, HornetQ 2.0.0 GA within Red Hat JBoss Application Platform 5.0.0.

      Description

      We have written a test to reproduce the problem (an EAR file and a client-side JAR file including a JUnit-based test file), but it does need a queue (queue/TestHornetQueue) to be set up to send the messages into.

      From a servlet we do a Successful JAAS login, and then call a Session bean. In the session bean we can access the SecurityContext and the associated principle. But if we create and send a message to a HornetQ queue, the associated SecurityContext seems to be reset, as is apparent from any further call to a Session bean.

      Servlet
      1. --> JAAS Login --> creates a LoginContext (user = xyz , pwd = test)
      2. --> call a session bean --> can access the JAAS principle as "xyz"
      3. --> create and send message to a hornet-queue
      4. --> call the same session bean again --> principle is set to anonymous... means that the associated SecurityContext is resetted by the 3rd step.

      The problem happens when sending messages into a queue from a Servlet.

      It seems that the callerPrincipal is cleared (set to the un-authenticated "anonymous" user defined in standardjboss.xml) when sending the message. This seems to happen in a separate thread, so sometimes it clears immediately and sometimes it takes slightly longer (hence the call to sleep() in the test case).

      There is a similar bug reported against the default JMS provider (JBoss Messaging; Jira ID JBPAPP-3636), could this be related?

      This problem only occurs when using SecurityClient; it seems that using LoginContext works as expected. Both work under JBoss 5 with the default JMS provider (JBossMessaging). It may be that the SecurityClient is not intended for use inside a JBoss container, but if so, should there not be an error message in this case?

      Test case is on the forum thread.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                ataylor Andy Taylor
                Reporter:
                robertjlee Robert Lee
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: