Permissioning Service
When a client application such as a Caplin FX Professional application interacts with Liberator, for example when an end-user logs in or attempts to view or trade financial information, Liberator uses the services of an auth module to determine if the interaction is permitted.
Liberator includes example auth modules for use in development, but for production you should either write your own module or use Caplin’s Permissioning Auth Module (PAM), packaged in the Permissioning Service blade available as a separate download from Liberator.
This page provides an architectural overview of an example deployment that uses Caplin’s Permissioning service to integrate with a backend permissioning system.
Permissioning Service architecture
The diagram below shows how Caplin’s Permissioning Service integrates with a backend permissioning system via a permissioning adapter.
The backend permissioning system
The backend permissioning system is the system that you want to integrate with the Caplin Platform. Permissioning data identifies the end-users who are authorised to interact with Liberator, and the financial products that these end-users are permitted to view and trade.
The permissioning adapter
The permissioning adapter is an integration adapter that acts as the interface between the Caplin Platform and your permissioning system. Its purpose is to provide Liberator’s Permissioning Auth Module with permissioning data.
To create a permissioning adapter, you write and compile a Java application that uses the Permissioning Integration API. This simple API is part of the Caplin Integration Suite and is layered on top of the Caplin Java DataSource API. It allows your application to send permissioning data to Liberator using the DataSource protocol, but without the need for your code to explicitly use the Java DataSource API. Liberator can be configured to connect to one or more permissioning adapters.
With the Caplin Integration Suite for Java, you can create an integration adapter that uses both the Permissioning Integration Java API and the Trading Integration Java API. This allows the same application to act both as a permissioning adapter and a trading adapter. For details of how to include trading functionality in your integration adapter, see the document Caplin Trading: Integrating The Caplin Platform With A Trading System. |
For more information on writing a permissioning integration adapter, see the Permissioning integration adapter tutorial.
Do not deploy permissioning adapters in a failover configuration with source affinity enabled. For the correct configuration to use, see Load-balancing configuration with two adapters — source affinity enabled. |
The Permissioning Auth Module
The Permissioning Auth Module (PAM) is an Liberator auth module packaged separately from Liberator in the Permissioning Service blade. The PAM subscribes to live permissioning data served by one or more permissioning adapters.
The client application
The components of the Graphical User Interface (GUI) at the client application can be tailored to match the permissions of the end-user who is currently logged in. An example would be to display information that the user is allowed to view, and to hide information that the user is not allowed to view. This information could be anything from pricing data for currency-pairs, to menu items, data grids, trade tiles, and tenors.
To add permissioning to a client application that is based on Caplin Trader, you must modify the client application by adding JavaScript code that uses the Permissioning API of Caplin Trader. This simple API can retrieve permissioning data from Liberator and is built on top of the StreamLink JS library. StreamLink JS provides communication between Caplin Trader and the Liberator server using the RTTP protocol.
See also: