8 Replies Latest reply on Aug 16, 2005 12:57 PM by Adrian Brock

    JMS Security permissions clarification

    Tim Fox Master

      '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?