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:

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 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.

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.*.

Example of Permission Checking

This example walks through a scenario for granting and revoking permissions to a user, and describes what happens as various operations are performed.

  1. User bob is working with a TIBCO Enterprise Message Service application that subscribes to topics and displays any messages sent to those topics.
  2. User bob creates a subscription to user.*. This topic is the parent topic of each user. Messages are periodically sent to each user (for example, messages are sent to the topic user.bob). Because the same application is used by many users, the application creates a subscription to the parent topic.
  3. User bob creates a subscription to topic corp.news. This operation fails because bob has not been granted access to that topic yet.
  4. A message is sent to the topic user.bob, but the application does not receive the message because bob has not been granted access to the topic yet.
  5. The administrator, as part of the daily maintenance for the application, grants access to topics for new users. The administrator grants the subscribe permission to topic user.bob and corp.* to user bob. These grants occur dynamically, and user bob is now able to receive messages sent to topic user.bob and can subscribe to topic corp.news.
  6. The administrator sends a message on the topic user.bob to notify bob that access has been granted to all corp.* topics.
  7. The application receives the new message on topic user.bob and displays the message.
  8. User bob attempts to create a subscription for topic corp.news and succeeds.
  9. A message is sent to topic corp.news. User bob’s application receives this message and displays it.
  10. The administrator notices that bob is a contractor and not an employee, so the administrator revokes the subscribe permission on topic corp.* to user bob.
  11. The subscription to corp.news still exists for user bob’s application, but bob cannot create any new subscriptions to children of the corp.* topic.


TIBCO Enterprise Message Service™ User’s Guide
Software Release 4.3, February 2006
Copyright © TIBCO Software Inc. All rights reserved
www.tibco.com