When Permissions Are Checked

If permissions are enforced (that is, the authorization configuration property is set, and the secure property is set for the destination), the server checks them when a user attempts to perform an operation on a destination. For example, create a subscription to a topic, send a message to a queue, and so on. Since permissions can be granted or revoked dynamically, the server checks them each time an operation is performed on a destination (and each time a consumer or producer is created).

For specific (non-wildcard) destination names, permissions are checked when a user performs one of the following actions:

  • creates a subscription to a topic
  • attempts to become a consumer for a queue
  • publishes or sends a message to a topic or queue
  • attempts to create queue browser

A user cannot create or send a message to a destination for which he or she has not explicitly been granted the appropriate permission. So, before creating or sending messages to the destination, a user must be granted permissions on the destination.

However, for wildcard topic names (queue consumers cannot specify wildcards), permissions are not checked when users create non-durable subscriptions. Therefore, a user can create a subscription to topic foo.* without having explicit permission to create subscriptions to foo.* or any child topics. This allows administrators to grant users the desired permissions after the user’s application creates the subscriptions. You may wish to allow users to subscribe to unspecific wildcard topics, then grant permission to specific topics at a later time. Users are not able to receive messages based on their wildcard subscriptions until permissions for the wildcard topic or one or more child topics are granted.

Attempts to perform an operation by a user who does not have the permission to perform it are traced in the server log file.

Note: When creating a durable subscriber, users must have the durable permission explicitly set for the topic they are subscribing to. For example, to create a durable subscriber to topic foo.*, the user must have been granted the durable permission to create durable subscriptions for topic foo.*. To subscribe an existing durable subscriber to a topic, you must have either durable or use_durable permission set on that topic.