Architectural overview

A general overview of Caplin’s Permissioning API, explaining its basic structure and principles.

The display components of your trading application can be tailored to match the permissions of the user who is currently logged in. In the simplest terms, you can make your application display the information that particular users are allowed to view, and to hide anything that they’re not meant to see, from particular data streams to entire components. Actions too, can be restricted in this way.

Permissions are sent to Liberator by the Permissioning Integration API. User permissions and authentication are enforced by the Permissioning Service Blade on the Liberator server. The Permissioning API enables you to query the permissions that a user has, and enforce them on the client. However, the classes in this API only allow you to query the permissions that have been assigned to the currently logged in user, in order to display the interface appropriately; they do not allow you to change these permissions on the server.

Each user permission defines whether or not a user can perform a particular action on a particular product or set of products (for example: viewing streaming prices on FX products; or performing SPOT trades on the GBPUSD product). The value of the permission is either to "allow" or "deny" the action. You can collect permissions under a specific namespace, in order to group related actions, or place them under the global (default) namespace.

For example: you could group tenor permissions, by defining these permissions in a "tenor" namespace. Your client application could then query that namespace to determine which tenors are allowed, and which are not.

The table below shows four such permissions, with one product permission defined on each row. Note that the final column of the table ("Significance") is not part of the permission, and is only included here to for descriptive purposes.

As you can see, JavaScript regular expressions have been used to define the product, so that the same permission can be applied to a range of products. When a user attempts to view or trade a product, Liberator consults pre-defined permissioning rules that specify the permissions that the user needs in order to complete the task.

The permissions in the first two rows of the table above allow the user to view all products, and to trade any FX product. In this case, the namespace is "null", meaning that the permission is in the global (default) namespace. This type of permission would typically be used at the client, to enable or disable the display of products or product grids.

The permissions in the last two rows are defined in the "tenor" namespace. They allow the user to trade any FX product with a 1-week tenor, but not to trade any FX product with a 2-week tenor. These permissions would typically be used at the client, to enable the 1-week tenor option and to disable (or hide) the 2-week tenor option.

User permissions are queried via the Permissioning API, using a PermissionService which you must register on the ServiceRegistry.