Permissioning Concepts

A product is an entity on which users may be assigned permissions. You define products when you write the Permissioning Adapter. Examples of products are:

An action defines the interaction that a user can have with a product. You define product actions when you write the Permissioning Adapter. Examples of product actions are:

A permission determines whether an action on a product will be allowed or denied. When you define a permission you can also define a namespace. A namespace allows client applications to query related permissions, such as all permissions in the "tenor" namespace. If you do not define a namespace, then the permission will reside in the default namespace. Permissions are assigned to Users and Groups when you write the Permissioning Adapter. Examples of product permissions (each row in the table defines a permission):

A user represents an end-user of a client application. A user can only log in to a client application if permissioning data to authenticate the user has been supplied to Liberator. Users can also be assigned permissions for the products streamed by Liberator. Users are defined when you write the Permissioning Adapter. Data for constructing each user would typically be read from a configuration file or persistent permissioning system.

Users can be arranged in groups, where every member of a group has the same permissions. A user can be a member of more than one group, and groups can be members of other groups. This allows an inheritance tree of permissions to be created. In the example below, user X is a member of two groups:

As user X is a member of "FI Traders" and "FX Traders", they will be able to trade both FX and FI instruments. You will find another example of an inheritance tree in Example permissioning hierarchy. When permissions in an inheritance tree are in conflict, conventions are used to determine the permission that is assigned to the user. These conventions are described in Permissioning hierarchy conventions. Groups are defined when you write the Permissioning Adapter. Data for constructing each group would typically be read from a configuration file or persistent permissioning system.

In addition to defining permissions, you must also define permissioning rules. Rules link permissions to user interactions, and are used by Liberator to decide which of the many permissions that have been defined will apply when a user attempts to interact with a product.

When a client application requests data from Liberator, or tries to publish data to Liberator, the Permissioning Auth Module inspects the content of the associated RTTP message and tries to match it with one or more of the defined rules. If a match is found then the rule will identify the permission that must be checked to determine whether this interaction with Liberator is to be allowed or denied.

If more than one rule matches an RTTP message, then every one of the identified permissions will be checked. If any one of these permissions denies access, then access to the product will be denied.

Rules must be defined for every interaction that involves a client application publishing data to Liberator, such as when a user attempts to trade a product. If a rule has not been defined for such an interaction, then the default permission is to deny the interaction.

Rules cannot be defined for interactions that involve a client application requesting data, such as when a user attempts to view a product. With this type of interaction a default rule is implemented, and the permission that has been defined for the "VIEW" action in the default namespace will be checked to see if the interaction is to be allowed or denied.

Roles determine whether a Permissioning Adapter has been designated as the master or slave.

Multiple Permissioning Adapters connected to Liberator (showing one master and one slave)

Liberator can be configured to accept permissioning data from multiple Permissioning Adapters. This allows permissions from different permissioning systems to be provided by different Permissioning Adapters. For example, one Permissioning Adapter could provide permissions for FX products and another permissions for FI products, with each Permissioning Adapter being administered by a different department.

When permissioning data is sent to Liberator from more than one Permissioning Adapter, one Permissioning Adapter is designated the master and each of the other Permissioning Adapters are designated as slaves. A slave Permissioning Adapter can only send a limited a set of permissioning data to Liberator and there can only be one master. The tutorial here describes how to set the master and slave roles, and defines the limited set of permissioning data that a slave can send to Liberator.

The diagram below shows a permissioning hierarchy that uses the permissioning concepts introduced in this section. In this example, all permissions reside in the default namespace.

From this diagram you will see that users have been assigned permissions through inheritance.

User 1 is a view only user

User 2 is an experienced trader

User 3 and User 4 are novice traders with the same product permissions

See also: