Permissions

Use permissions items to send changes in user permissions between DataSource applications, and between Liberator and client applications via StreamLink.

The meaning of a permissions object and the actions that are taken on it aren’t preset; they’re programmed according to business requirements. For example, a financial trading system might use custom permissions objects that allow end-users to trade on objects using particular trading models, such as ESP (Executable Streaming Protocol) or RFS (Request for Stream).

Permissions objects have the same structure as Type 2 data.

After defining the permissions objects you require, and the format and meaning of their content, you use the Caplin Integration Suite or other DataSource API to implement a new DataSource application (or modify an existing one) that generates the permission objects. The DataSource application would often be an Integration Adapter that obtains the permissioning information from an existing permissioning system.

Liberator can receive updates to permissions objects and process them in its Permissioning Auth authorisation module, which interprets the updates and modifies access permissions accordingly.

A client application can receive updates from Liberator about changes to access permissions, and can then use the updated permission information to modify the way the application behaves.

Caplin also supplies a higher level Permissioning API within the Caplin Integration Suite that simplifies the process of implementing permissioning within the Caplin Platform, but still enables you to implement sophisticated permissioning models.

There’s also an equivalent permissioning API within Caplin Trader that allows the client application to behave in accordance with the permissions of the logged in user. For example, once the client has used the API to obtain the user’s permissions, it can display information that the user’s allowed to view, and to hide information that the user isn’t allowed to view.

See also: