Open topic with navigation

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

- Authentication must be enabled (via the `auth.providers` parameter in the ftlserver configuration file).

- Once authentication is enabled:

  - Assign permissions via the Users Grid and Roles Grid. See Configuring Permissions.

  - On the Realm Properties Details Panel, Permissions is set as Disabled by default and must be set as Enabled. See Realm Properties Details Panel.

- 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 usernames and/or roles.

In the permissions map, 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 persistence store or persistence cluster. If an FTL client matches multiple entries in the permissions map (a username 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 username or role does not require a restart of any FTL components.

## Revoke Permissions

Permissions associated with a username 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.

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO FTL® - Enterprise Edition

Copyright © 2009-2024. Cloud Software Group, Inc. All Rights Reserved.