Permissions

Background

Administrators can secure the messaging infrastructure by setting fine-grained permissions on destinations, persistence clusters, or persistence stores. For example, on a destination, you may indicate that a particular user or role is allowed to subscribe or publish on the destination.

If you are using the destinations messaging model, you should set permissions on destinations. If you are using the content matching model, you should set permissions on persistence stores. You should not set permissions on both unless you are transitioning from one model to the other. For background information, see FTL Configuration Overview.

In rare cases, you may also want to set permissions on the persistence cluster. The only reason to do this is to allow certain applications to create locks on the persistence cluster. Locks are used in the map API.

These are the requirements to use permissions:

• All persistence transports must be marked secure.

• Clients must be using FTL 6.8.0 or later.

• Authentication must be enabled (through the auth.providers parameter in the FTL server configuration file).

For details on the preferred method to upgrade to FTL 6.8.0, see Migrating to FTL 6.8.0 when Using Permissions.

Enabling Permissions

To enable permissions, on the Realm Properties Details Panel, set the permissions toggle to enabled. This enables permission checks for all persistence clusters. See Realm Properties Details Panel. Or, for the web API, see Realm Definition and Properties.

When permissions are enabled, permissions are enforced at every persistence cluster defined in the realm. By default, a user has no permissions; permissions must be explicitly granted to users or roles as described in the next section, Assigning Permissions. There is one exception: users with the predefined ftl-internal role always have all permissions. For this reason the ftl-internal role should not be assigned to ordinary users. See FTL Server Authorization Groups for information on predefined roles.

The following information is for users of the content matching messaging model. It does not apply to users of the destinations model.

Endpoint store inboxes are enabled when either of the following are true. See Endpoint Store Inboxes.

• use_endpoint_store_for_inbox is true

• enable_permissions is true

Setting enable_permissions to true does not change the value of use_endpoint_store_for_inbox, but endpoint store inboxes are enabled. If enable_permissions is set back to false, then endpoint store inbox behavior depends on the existing value of use_endpoint_store_for_inbox.

When using permissions with the request-reply API, the requestor has an implicit inbox subscriber on the reply endpoint's store. (By default the reply endpoint is the same as the publisher's endpoint.) Because endpoint store inboxes are automatically enabled, this subscription is created in the reply endpoint's store. Therefore:

• Requests (using tibPublisher_Request) require publish permissions on the endpoint's store and subscribe permissions on the reply endpoint's store (which could be a different endpoint).

• Replies (using tibPublisher_Reply) require publish permissions on the reply endpoint’s store.

Assigning Permissions

The administrator configures permissions for destinations, persistence stores, or persistence clusters.

Each destination, persistence store, and persistence cluster in the realm configuration has an access control list (in the web API, the acl field). The access control list associates permissions with usernames and/or roles.

In the access control list, a username or role can be associated with a list of string values representing permissions. Any FTL client with the specified username or role will have the associated permissions when interacting with the given destination, persistence store, or persistence cluster. If an FTL client matches multiple entries in the access control list (a username and/or any number of roles), the FTL client has the union of all matched permissions.

See Enforcing Permissions for information on how FTL server enforces permissions.

Adding permissions to a username or role does not require a restart of any FTL components.

Refer to the following table for supported permissions. You grant permissions to a user or role (group).

Resource	Permission	Effect
Topic (Destination)	subscribe	The user may create or destroy durable subscriptions on this topic. The user may receive, acknowledge, or browse messages on this topic. The user may rewind durable subscriptions on this topic, if message retention is enabled.
Topic (Destination)	publish	The user may send messages to this topic.
Queue (Destination)	subscribe	The user may create subscriptions on the queue. As a side-effect, the queue may be created. The user may receive, acknowledge, or browse messages from the queue. The user may rewind the queue, if message retention is enabled.
Queue (Destination)	publish	The user may send messages to this queue. As a side-effect, the queue may be created.
Map (Destination)	map	The user may get, put, or delete key-value pairs from this map. As a side-effect, the map may be created. The user may destroy this map, including all key-value pairs stored in the map.
Persistence Store	subscribe	In general, do not configure this permission if using the destinations messaging model. Configure permissions on destinations instead. The user may create or destroy durable subscriptions in the persistence store. The user may receive, acknowledge, or browse messages from any durable in the persistence store. The user may rewind any durable in the persistence store, if message retention is enabled. The user is granted the subscribe permission on all topic and queue destinations in the persistence store.
Persistence Store	publish	In general, do not configure this permission if using the destinations messaging model. Configure permissions on destinations instead. The user may send messages to the persistence store. The message will be delivered to any matching subscription in the persistence store. The user is granted the publish permission on all topic and queue destinations in the persistence store.
Persistence Store	map	In general, do not configure this permission if using the destinations messaging model. Configure permissions on destinations instead. The user may get, put, or delete key-value pairs on any map in the persistence store. As a side-effect, the map may be created. The user is granted the map permission on all map destinations in the persistence store.
Persistence Cluster	lock	The user may create locks in the persistence cluster. (A lock is created when a map API requiring a lock is called, and the map resides in any persistence store managed by the persistence cluster.)

Revoking Permissions

Permissions associated with a username or role may be removed at any time. Removing permissions does not require a restart of any FTL components.

Permission revocation is not enforced synchronously. At some later time FTL will enforce the new restrictions.

Even when the new restrictions are applied, a subscriber whose subscribe permission was revoked may receive a number of messages up to the subscriber’s prefetch value.

Permissions for Logging and Monitoring

New users of FTL should consider consuming monitoring metrics from FTL server’s prometheus endpoint. This is a web API endpoint. See FTL Prometheus Metric Naming.

Consumers of the prometheus endpoint must have the ftl-admin role, regardless of whether fine-grained permissions are enabled. See FTL Server Authorization Groups.

Use of the prometheus endpoint is encouraged. However, for older installations, FTL clients may continue to consume monitoring metrics and logs from FTL server via the built-in logging and monitoring stores. To do so, FTL clients may subscribe on the built-in monitoring or logging endpoints. Alternatively, FTL clients may subscribe on the built-in monitoring or logging destinations. The tibmongateway executable from older releases of “TIBCO® Messaging Monitor for TIBCO FTL®” is one such FTL client.

To consume monitoring metrics, the subscribe permission must be granted to the FTL client on the built-in monitoring store (ftl.system.mon.store). To consume logs, the subscribe permission must be granted to the FTL client on the built-in logging store (ftl.system.log.store).

It is not possible to grant publish or map permissions on the built-in monitoring and logging stores.

It is not possible to grant permissions on the built-in monitoring and logging destinations. Grant the subscribe permission on the built-in monitoring and logging stores instead.