7 Replies Latest reply on Jun 12, 2010 4:14 AM by timfox

    JMS Permission problem

      Hi there,


      I have a problem using HornetQ and its permissions in the standalone setup.


      I have created a simple topic in hornetq-jms.xml:


          <topic name="Test">
              <entry name="topic/Test"/>


      Also a very simple user in hornetq-user.xml:


          <user name="1234" password="1234">
              <role name="examplerole" />


      And the security settings in hornetq-conifguration.xml


            <security-setting match="#">
               <permission type="consume" roles="examplerole"/>
               <permission type="send" roles="examplerole"/>


      I'm connecting to the server from a client as described in the examples providing the appropriate credentials:


      connection = cf.createConnection("1234", "1234");


      (doing more session setup here...)


      and then trying to access the topic:


                  Topic topic = (Topic) ProntoConnectionUtils.getContext().lookup("/topic/Test");
                  MessageConsumer consumer = session.createConsumer(topic);


      The topic will be found in JNDI, but I will get an javax.jms.JMSSecurityException: Unable to validate user: 1234 for check type CREATE_NON_DURABLE_QUEUE for address jms.topic.Test when creating the Consumer for the topic (in line: MessageConsumer consumer = session.createConsumer(topic);)


      I have assumed, that setting the permission type 'consume' will be enough to receive messages. Nevertheless, the above mentioned approach only works, if I add the 'createTempQueue' permission type to the security settings for the examplerole.


      Can anybody help me out, what I do wrong? Why do I need to add the 'createTempQueue' permission? From my understanding I do not create any temp queues programatically. Any help will be very much appreciated.





        • 1. Re: JMS Permission problem
          That is correct, if you look at the examples they all have this security permission and it is also mentioned in the user manual iirc.
          1 of 1 people found this helpful
          • 2. Re: JMS Permission problem

            As andy said, this permission is also required.


            Please note that the permissions are for HornetQ Core queues (not JMS queues).

            When you create a JMS Topic Consumer, underneath HornetQ will create a Core queue for this consumer.
            This is why you need to add the permission in order to create  a JMS Topic Consumer.

            • 3. Re: JMS Permission problem

              Dear Andy,

              Dear Jeff,


              thank you very much for your quick response.


              As I understand now, (additional) core queues will be generated internally when I create an JMS Topic Consumer.



              • 4. Re: JMS Permission problem

                I'm getting the same error message (HornetQException[errorCode=105 message=Unable to validate user: soccerclient for check type CREATE_NON_DURABLE_QUEUE for address jms.topic.soccer.events.livecenter]) when trying to authenticate a stomp client with user exampleuser, using the following configuration:


                <configuration xmlns="urn:hornetq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                            xsi:schemaLocation="urn:hornetq /schema/hornetq-users.xsd">
                   <!-- the default user.  this is used where username is null-->
                    <defaultuser name="guest" password="guest">
                        <role name="guest"/>
                    <user name="admin" password="testtest">
                        <role name="admin"/>
                    <user name="exampleuser" password="example">
                        <role name="generic-client"/>
                        <role name="guest"/>


                    <security-setting match="#">
                        <permission type="createDurableQueue" roles="admin, generic-client"/>
                        <permission type="deleteDurableQueue" roles="admin"/>
                        <permission type="createNonDurableQueue" roles="admin, generic-client, guest"/>
                        <permission type="deleteNonDurableQueue" roles="admin"/>
                        <permission type="createTempQueue" roles="admin, generic-client, guest"/>
                        <permission type="send" roles="admin"/>
                        <permission type="consume" roles="admin, generic-client, guest"/>       




                When authenticating as admin, things work nicely, but I am not able to make it work with any other user. I suspect that the reason is partly the same as the original post in this thread, but I can't find the necessary information in the manual or any of the examples.

                • 5. Re: JMS Permission problem

                  Unable to validate user: *****soccerclient**** for check type CREATE_NON_DURABLE_QUEUE for address jms.topic.soccer.events.livecenter])


                  The user you are using is "soccerclient" not "exampleuser", and you haven't given that user any permissions in the config.


                  You'd need to add something like:


                  <user name="sockerclient" password="example">
                          <role name="generic-client"/>
                          <role name="guest"/>


                  Read the security chapter in the user manual for more info on security config

                  • 6. Re: JMS Permission problem

                    Hi Tim, I changed the name and password in the config when I posted the example, because I didn't want to expose it (and forgot to rename it in the errror message as well).


                    I can assure you that I don't have a mismatch between the users-config file and the client user name, so this is not the cause of the problem. I've read the security chapter in the manual but haven't gotten any wiser on the reasons for this particular problem.

                    • 7. Re: JMS Permission problem

                      If you post a working test program and full config that demonstrates the issue, someone can take a look.