3 Replies Latest reply on Oct 25, 2006 10:38 PM by jaikiran pai

    SecurityContext after JMS call

    Thomas Porocnik Newbie

      Hi,

      we have a (secured) SessionBean which uses JMS queues to do asynchronous work in parallel.
      On the other side of the queue (in the same security domain) other (secured) SessionBeans are called. Unfortunately over the queue the SecurityContext is lost.
      Is there a smart way to somehow "reestablish" the SecurityContext?

      Regards

      Thomas


        • 1. Re: SecurityContext after JMS call
          jaikiran pai Master

          Specify a <run-as> in the ejb-jar.xml for the Message Driven Bean. Check the ejb-jar.xml's dtd, for more details:

          http://java.sun.com/dtd/ejb-jar_2_0.dtd

          <!--
          The run-as element specifies the run-as identity to be used for the
          execution of the enterprise bean. It contains an optional description, and
          the name of a security role.
          
          Used in: security-identity
          -->
          <!ELEMENT run-as (description?, role-name)>







          • 2. Re: SecurityContext after JMS call
            Thomas Porocnik Newbie

             

            "jaikiran" wrote:
            Specify a <run-as> in the ejb-jar.xml for the Message Driven Bean.

            Thanks for your reply.
            Sure I could do it this way, but this would execute the beans method always with the same fixed identity.
            What I want to do is to keep track of the user originally called the first bean and execute it with his identity.

            Maybe I'm wrong and this is the wrong approach.
            I'm open for every hint ;-)

            Regards


            • 3. Re: SecurityContext after JMS call
              jaikiran pai Master

               

              What I want to do is to keep track of the user originally called the first bean and execute it with his identity.


              AFAIK, that's not possible(someone can correct me if i am wrong). The reason behind this being the MDB is invoked by the server and not by the user who puts in the message in the queue. The job the user who has logged in has ended the moment he has successfully put in the message into the queue. When the MDB gets invoked *asynchronously* its a totally new flow and hence you wont be able to get the security info of the user who had put in the message to the queue.