8 Replies Latest reply on Aug 16, 2005 12:57 PM by adrian.brock

    JMS Security permissions clarification

    timfox

      'm currently implementing (partially porting) security for the JMS facade of JBM.

      In JBossMQ it seems that, for each destination, a triplet of read-write-create can be granted for a particular role.

      E.g. role = 'observers' might have read=true, write=false, create=false for queue="order_queue"

      Initially I interpreted the permissions to mean the following:

      read permission for a destination is required so the user can:
      a) you can browse it (if it's a queue)
      b) you can create a consumer for it

      write permission for a destination is required so the user can:
      a) you can create a producer for it

      create permission for a destination is required so the user can:
      (what does it mean - you can't create a destination via the JMS API??)

      When I look into the code in the ServerSecurityInterceptor, the actual meanings are as follows:

      read permission for a destination is required so the user can:
      a) you can browse it (if it's a queue)
      b) you can create a consumer for it
      c) you can receive a message from it - (isn't this redundant - you can't receive a message if you haven't create the consumer first??)

      write permission for a destination is required so the user can:
      a) you can send a message to it
      (creation of message producer is not currently restricted)

      create permission for a destination is required so the user can:
      a) Create a durable subscription on the destination
      b) Delete a durable subscription.

      Can I clarify that these are the required semantics of read-write-create on a destination?

      In particular that create on a destination doesn't refer to the creation of a destination but to the creation/destruction of durable subscriptions on that destination.

      If so, do you think we should consider renaming the permissions from read-write-create to, say, receive-send-administer_durable, (or similar) so that we are more explicit about this?

      Or perhaps we could be more fine grained with our permissions?

      wdyt?



        • 1. Re: JMS Security permissions clarification

          Yes, the JBossMQ roles take the set of all operations and groups them
          according to the read/write/create permissions.
          It leaves the user to map roles to these permissions.

          You could make the permissions more configurable at the cost of more
          complexity and potentially security problems if somebody does it wrong.
          e.g. allowing readers to create durable subscriptions by mistake.

          It is not necessarily per destination. If the destination has no roles, it uses the
          default security from the security manager.

          http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQSecurity
          http://wiki.jboss.org/wiki/Wiki.jsp?page=SecurityConf

          • 2. Re: JMS Security permissions clarification
            ovidiu.feodorov

             

            In particular that create on a destination doesn't refer to the creation of a destination but to the creation/destruction of durable subscriptions on that destination.


            Yes this is correct. Creation of destination means deployment of the destination. This is DestinationManager's responsibility. It is an "administrative" operation, which is either performed by a deployer or explicitely via a JMX operation. Securing it is equivalent with securing the JMX operation.

            If so, do you think we should consider renaming the permissions from read-write-create to, say, receive-send-administer_durable, (or similar) so that we are more explicit about this?


            I don't know. Adrian, do you know of any complaints about the current convention?

            • 3. Re: JMS Security permissions clarification

               

              "ovidiu.feodorov@jboss.com" wrote:

              I don't know. Adrian, do you know of any complaints about the current convention?


              You mean other than people don't read the documentation? :-)

              • 4. Re: JMS Security permissions clarification
                ovidiu.feodorov

                No, I mean that people who read documetation say: "This is confusing, it shouldn't be called 'create' but 'create_durable_subscription', because I shouldn't be required to read documentation to understand a configuration file"

                • 5. Re: JMS Security permissions clarification

                  Like I said on the other thread, there should be as little code in
                  JBoss Messaging as possible. It should reuse what JBoss already has.

                  If somebody wants to go beyond simple role based security this should be possible
                  and hopefully relatively easy...
                  e.g.
                  * authority based on message size
                  * authority based on number of message sends/throughput
                  * augmenting the "message selector" with an authorization
                  e.g. is the user allowed to receive this message?
                  * your usecase here

                  But we don't have to provide these implementations (at least in the initial release).
                  Just make it possible.

                  • 6. Re: JMS Security permissions clarification

                     

                    "ovidiu.feodorov@jboss.com" wrote:
                    because I shouldn't be required to read documentation to understand a configuration file"


                    That approach just leads to people making random configurations
                    based on what they think it means. You'll never get a name that truly describes
                    what it does unless it is ridicously long. And people never read comments
                    attached to the xml.

                    You'll be surprised how many questions in the forums are based on people
                    "feeling the need" to play with configuration they don't understand.

                    whether-users-in-this-role-can-create-durable-subscriptions-they-must-also-have-read-permission=true
                    


                    • 7. Re: JMS Security permissions clarification
                      ovidiu.feodorov

                      :)

                      Fair enough. Let's call them r/w/c then :)

                      • 8. Re: JMS Security permissions clarification

                        Obviously it is a balance.

                        I remember an old piece of research that said variable names you should ideally be
                        13 characters long. (Probably by some IBM consultant :-)

                        Anything less is not meaningful
                        Anything longer is too hard to type. Or too easy to mistype.

                        Of course, if you actually apply that rule, you find it doesn't work.
                        It depends on the usecase.