Enforcing Permissions

Permissions are granted to the FTL client's user name and/or roles. To set user and role permissions from the FTL user interface, see Configuring Permissions.

When an application interacts with a persistence cluster (for example by subscribing or publishing on a destination), FTL server determines if that interaction is allowed, based on the permissions granted to the FTL client's username and/or roles. Most commonly this interaction results from an API call, but all interactions are regulated regardless of the source.

Where possible, if an FTL client is not authorized to take a certain action, the API call will fail immediately regardless of any retry duration.

FTL server logs all authorization failures at the loglevel “acl:verbose”.

FTL server’s permission check varies based on whether you are using the destinations messaging model or the content matching model. For background see FTL Configuration Overview.

Destinations Model

If using the destinations model, then interactions with topic, queue, or map destinations are checked against the permissions for that destination.

FTL server first matches the destination specified by the client program with a destination configured in the FTL realm. See Destination Matching and Wildcards. In the case of overlapping configured destinations, it is possible for the client’s destination to match multiple configured destinations; see Inheritance.

FTL server then reads the access control list(s) from the configured destination(s) to determine the client’s permissions. If the FTL client matches multiple entries (a username and/or any number of roles in any of the access control lists), the FTL client has the union of all matched permissions.

In general, when using the destinations model, you should not grant permissions on the persistence store. However, for scenarios where you are transitioning from the content matching model to the destinations model, FTL server will also read the access control list for the persistence store in which the client’s destination resides. If the FTL client matches any entries in the persistence store’s access control list (a username and/or any number of roles), the matched permissions are added to the client’s permissions.

Finally, FTL server determines if the client has permission to perform the requested operation, and rejects the operation if the client does not have proper permission. Refer to the following table for permissions required by various client API calls.

If the client is performing a lock operation via the map API, then FTL server reads the access control list from the persistence cluster instead.

Permissions for API Calls

Operation	FTL API	FTL Permission	Resource
Acquire lock	Implicit via map calls WithLock	lock	Persistence cluster
Return lock	tibLock_Return tibLock_Destroy	lock	Persistence cluster
Close map	tibMap_Close	map	Map (destination)
Create map	tibRealm_CreateMapOnDest	map	Map (destination)
Delete map	tibRealm_RemoveMapOnDest	map	Map (destination)
Map get	tibMap_Get tibMap_GetMultiple	map	Map (destination)
Map get size	tibMap_GetSize	map	Map (destination)
Map iterate	tibMap_CreateIterator tibMapIterator_Next	map	Map (destination)
Map remove	tibMap_Remove tibMap_RemoveMultiple	map	Map (destination)
Map remove all	tibMap_RemoveAll	map	Map (destination)
Map set	tibMap_Set tibMap_SetMultiple	map	Map (destination)
Close publisher	tibDestPublisher_Close Note: For unbound publishers, where the destination is NULL when creating the publisher, there is no permission to check.	publish	Topic (destination) Queue (destination)
Create publisher	tibRealm_CreateDestPublisher Note: For unbound publishers, where the destination is NULL, there is no permission to check.	publish	Topic (destination) Queue (destination)
Publish	tibDestPublisher_Send tibDestPublisher_SendMessages	publish	Topic (destination) Queue (destination)
Send request	tibDestPublisher_SendRequest	publish	Topic (destination) Queue (destination)
Send reply	tibDestPublisher_SendReply Note: You do not need to grant publish permissions for the purpose of sending replies. Ensure the publisher is unbound, where the destination is NULL when creating the publisher. The reply is sent only to the internal reply destination created by the requestor; the client program may not choose where to send the reply.	(none)	NA
Close subscriber	tibDestSubscriber_Close	subscribe	Topic (destination) Queue (destination)
Create subscriber	tibRealm_CreateDestSubscriber	subscribe	Topic (destination) Queue (destination)
Destroy topic durable	tibRealm_UnsubscribeDest	subscribe	Topic (destination)
Start subscriber	tibEventQueue_AddDestSubscriber	subscribe	Topic (destination) Queue (destination)
Stop subscriber	tibEventQueue_RemoveDestSubscriber	subscribe	Topic (destination) Queue (destination)
Ack message	tibEventQueue_Dispatch (auto ack) tibMessage_Acknowledge (explicit ack) tibDestSubscriber_Acknowledge (explicit ack) tibDestSubscriber_AcknowledgeMessages (explicit ack)	subscribe	Topic (destination) Queue (destination)
Rewind	tibRealm_RewindDest	subscribe	Topic (destination) Queue (destination)
Create browser	tibRealm_CreateDestBrowser	subscribe	Topic (destination) Queue (destination)
Browse message	tibBrowser_Next	subscribe	Topic (destination) Queue (destination)
Delete browsed message	tibBrowser_DeleteMessage	subscribe	Topic (destination) Queue (destination)
Close browser	tibBrowser_Close	subscribe	Topic (destination) Queue (destination)

Content Matching Model

If using the content matching model, then interactions with a persistence store are checked against the permissions for that store. When an FTL client makes an API call, the persistence store is determined by the endpoint on which a publisher, subscriber, or map was created.

FTL server reads the access control list from the persistence store to determine the client’s permissions. If the 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.

Finally, FTL server determines if the client has permission to perform the requested operation, and rejects the operation if the client does not have proper permission. Refer to the following table for permissions required by various client API calls.

If the client is performing a lock operation via the map API, then FTL server reads the access control list from the persistence cluster instead.

Permissions for API Calls

Operation	FTL API	FTL Permission
acquire lock	Implicit via map calls WithLock	lock
return lock	tibLock_Return tibLock_Destroy	lock
close map	tibMap_Close	map
create map	tibRealm_CreateMap	map
delete map	tibRealm_RemoveMap	map
map get	tibMap_Get tibMap_GetMultiple	map
map get size	tibMap_GetSize	map
map iterate	tibMap_CreateIterator tibMapIterator_Next	map
map remove	tibMap_Remove	map
map remove all	tibMap_RemoveAll	map
map set	tibMap_Set tibMap_SetMultiple	map
close publisher	tibPublisher_Close	publish
create publisher	tibPublisher_Create	publish
publish	tibPublisher_Send tibPublisher_SendToInbox tibPublisher_SendMessages	publish
send reply	tibPublisher_SendReply	publish
send request	tibPublisher_SendRequest Note: Sending the request requires the publish permission on the endpoint's store. Receiving the reply requires the subscribe permission on the reply endpoint's store (which could be a different store).	publish AND subscribe
acknowledge	tibEventQueue_Dispatch (auto) tibMessage_Acknowledge (explicit) tibSubscriber_AcknowledgeMessages (explicit)	subscribe
close subscriber	tibSubscriber_Close	subscribe
durable create	Implicit via tibSubscriber_Create	subscribe
dynamic durable destroy	tibRealm_Unsubscribe tibRealm_UnsubscribeEx	subscribe
start subscriber	tibEventQueue_AddSubscriber	subscribe
stop subscriber	tibEventQueue_RemoveSubscriber	subscribe
subscribe	tibSubscriber_Create tibSubscriber_CreateOnInbox	subscribe
rewind	tibRealm_RewindSubscription().	subscribe
create browser	tibBrowser_Create()	subscribe
browse message	tibBrowser_Next()	subscribe
delete browsed message	tibBrowser_DeleteMessage()	subscribe
close browser	tibBrowser_Close()	subscribe