Permissions

Administrators can secure the messaging infrastructure by setting permissions at the cluster and store level to grant access to objects for a given user/role.

 
Administrators enable permissions by setting the realm property enable_permissions to true.
The requirements to use permissions follow:

  • All persistence transports must be marked secure.

  • Clients must be using FTL 6.8.0 or later.

  • TLS communication must be enabled (via the tls.secure parameter in the ftlserver configuration file).

  • Authentication must be enabled (via the auth.url parameter in the ftlserver configuration file).

  • Once the FTL server with TLS and authentication are enabled:

  • When enable_permissions is true, endpoint store inboxes are always enabled. See Endpoint Store Inboxes.

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

Enable Permissions

To enable permissions, set the enable_permissions flag in the realm properties to true.

When the enable_permissions flag is set to true, 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, Assign 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.

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. The value is not changed.

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

Assign Permissions

The administrator assigns permissions at the store or persistence cluster level.

Each store and persistence cluster in the realm configuration has a permission map (the acl field) that associates permissions with user names and/or roles.

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

Persistence cluster and persistence store permissions do not overlap. Persistence stores do not inherit permissions defined at the persistence cluster level.

The following permissions may be defined at a persistence cluster:

  • lock

The following permissions may be defined at a persistence store:

  • publish

  • subscribe

  • map

See Required Permissions for API Calls.

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

Revoke Permissions

Permissions associated with a user name or role at any persistence cluster or persistence store 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.

See Required Permissions for API Calls.

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

Monitoring Gateway Service

TIBCO® Messaging Monitor for TIBCO FTL® runs as an ordinary FTL client. The subscribe permission needs to be granted to the appropriate user and/or role on the built-in monitoring and logging stores (ftl.system.mon.store and ftl.system.log.store). The same is true of any application that subscribes on the monitoring or logging endpoints. It is not possible to grant the publish or map permissions on the monitoring and logging stores.